-
架構面試題 #1, 線上交易的正確性
最近一直在思考，團隊裡的後端工程師能力是否到位，是微服務架構能否成功的關鍵之一。我該怎麼鑑別出面試者有沒有這樣的能力? 最有用的就是出幾個實際的應用題，讓面試者在白板上面說明。最近這一輪面試，談了不下幾十位吧，索性就把我幾個常問的白板考題整理起來，歸在微服務系列的文章裡的開發團隊篇，改善團隊成員的問題，也算是朝向微服務化的目標跨出一大步。
這書應該是惡搞的吧? 竟然還有恰恰 XD
-
微服務基礎建設 - Service Discovery
要動筆寫這個主題 (service discovery) 之前，我想了很久該怎麼講這個主題… 如果講他怎麼做，那是很乏味的 process 而已。介紹產品或 step by step 的操作，那又不是我的 style. 想了半天，還是從架構的角度，切入 service discovery 想要解決什麼問題，搭配幾種常見的處理模式，再介紹一下有哪些成熟的服務是用這種模式設計的，正好一次把這幾個目的解決掉…
Microservices 先天就是個分散式系統，在開發領域上的門檻，主要就是各種呼叫遠端服務 RPC - remote procedure call 的相關技術了。然而在架構上最重要的一環，就屬 “服務發現” service discovery 這技術了。說他是微服務架構的靈魂也當之無愧，試想一下就不難理解: 當一個應用系統被拆分成多個服務，且被大量部署時，還有什麼比 “找到” 我想要呼叫的服務在哪裡，以及是否能正常提供服務還重要? 同樣的有新服務被啟動時，如何讓其他服務知道我在哪? 人家說微服務考驗的就是你治理大量服務的能力，包含多種服務, 也包含多個 instances。要做到這件事，service discovery 就是你要挑戰的第一關。
說到治理大量服務的能力，Nginx 官網有篇 文章 講得不錯，我就借他的圖用一用。裡面提到 Modern Apps 演進過程，從 1980 的 client / server, 到 2000+ 的 3-tiers, 到現在的 microservices …
從這張圖可以理解到, 走向微服務架構，有沒有能力管理好這麼多數量的 instance, 是你的 apps 能否成功的上線運作的關鍵因素之一。如果以 container 來看，服務的數量從小規模 (100+) 到中大規模 (1000+)，到你在書上看到的各種微服務大型成功案例 (10000+) 就知道，這種數量不大可能靠 IT 人員逐一設置固定 IP + PORT, 然後由 developer 逐一設置 configuration file, 這時善用 service discovery 就是解決這個問題的方法。
-
LCOW Labs: Linux Container On Windows
繼上次颱風天介紹的 Mixed-OS Docker Swarm 之後，適逢中秋節，那就再來一篇吧!
Microsoft 的 LCOW (Linux Container On Windows, 以下簡稱 LCOW) 推出後，Windows + Linux 的整合程度就更進一步了。Microsoft 願意這樣破釜沉舟的整合 Linux + Windows, 看來是下了很大的決心啊! 又進一步的讓 Windows 跟 Linux 的界線越來越模糊了。這是是在 Windows Container 的架構下，用原本就支援的 Hyper-V Container (簡單的說，為特定的 Container 準備一個獨立的 VM + 一套精簡的 OS，只為了執行 Container 使用的 OS 環境，來運行 Container), 進一步把裡面的 OS 從 NanoServer 換成 Linux Kit (或是 Ubuntu 也行), 讓 Windows Container 得到原生執行 Linux Container 的能力。
-
架構師觀點: 你需要什麼樣的 CI / CD ?
圖片出處: https://blog.infostretch.com/39-tools-for-building-your-cicd-stack/
這篇沒有要分享太多太硬的東西，或是太燒腦的架構文章，單純分享一下最近我協助團隊導入版控，以及 CI/CD 的想法而已。我一直覺得台灣 (還是世界各地都一樣?) 的軟體開發團隊存在這種 “工具控”、”框架控”、或是 “技術控” 的想法；選用跟得上潮流的技術，比什麼都重要。重要到這些技術或是框架本身到底是想解決什麼問題都不重要了，只要我用了最新的框架就是潮…
CI/CD, DevOps, SCRUM, Microservices, Containers 等等也是現在熱門的關鍵字，看過我前面文章的朋友大概都知道，我是很反對不知道這些技術是在幹嘛之前就一窩蜂的投入。最近在協助團隊從無到有建立起版控機制與 CI/CD 的過程有感，於是就寫了這一篇…
不過在開始進入正題之前，先讓我發發牢騷 XDD
-
Azure Labs: Mixed-OS Docker Swarm
接下來就玩大一點，前一篇都講到，既然將來 container 會是 software 統一的發行途徑了, 那麼只有 windows 怎麼夠用? 延續前面的 labs environment, 我們就接著把 linux 加進來吧~
其實，去年在寫這篇 架構師觀點: .NET 開發人員該如何看待 Open Source Solutions? 的文章時，我就有這個想法了。文內提到 stackoverflow.com 的架構, 採用個別 domain 最好的 solution, 而不是先被某個 os 或是 framework 限制住選擇。因此 stackoverflow.com 選擇了一個混搭 windows + linux 的架構。
這類架構，在過去的開發環境內，真的是來折磨開發人員的。開發不外乎要建立測試環境，想想看你有辦法很容易地在你的 PC 建立一個同樣的 架構嗎? Sure.. 弄個 VM 當然沒問題，只是要讓每個人都能很快地架起來，他的門檻實在不低啊，再加上裡面的服務都要 update to date, 就更 吃團隊的開發流程與 CI/CD 是否確實了。如果你的環境都已經容器化, 那剩下的就是找個能同時丟 linux 及 windows container 進去執行的環境了。
這願景已經可以實現一半了 :D，較正式的部署 (例如開發團隊共用的 DEV environment, 或是 Production environment), 可以建立一個 Mixed-OS docker swarm, 也就是本篇 labs 要介紹的。另一個就是等 Microsoft 在今年 dockercon 2017 宣布的下一個年度更新 Microsoft to allow Linux containers to run on Windows Server 釋出之後，你就 可以在自己的開發機，用 docker-compose 一次就把整個開發環境建立起來，不論背後是跑 windows or linux。
不論如何，這一切都是以 container 為核心架構的，現在投資這技術永遠不嫌晚，看下去就對了!
