微服務(Microservices)最佳實務
近些年微服務很流行，各種大企業也都有導入微服務的做法，其核心概念是：
「 藉由區分業務權責，將應用(application)成一塊塊的服務元件（簡單來說就是運行不同功能的伺服器們），這些元件之間透過 API 溝通進行合作，對內/外提供服務。 」
這是一種 SRP(Single Responsibility Principle) 概念的應用，譬如電商可能會將 payment 切成獨立的 payment service, 商品頁切成獨立的 product listing service, 訂單則有 order service, 客服則有 customer service, 這些服務之間彼此獨立，又彼此合作，對買家/賣家提供電子商務的服務。
微服務架構帶來的好處是服務元件之間可以獨立開發、部署、易於測試、易於擴展，如果是以往全部功能都塞在同一個伺服器的情況，舉 payment service 更新為例，僅是一個小小的更新，就需要對所有的伺服器進行更新部署，但如果是採用微服務，就只需要針對 payment service 的伺服器做更新部署即可，幾乎不影響其他服務。
然而，理想很豐滿，現實很骨感。
微服務架構也會帶來一定程度的複雜度(complexity)，舉 2 個親身經歷當例子：
- 微服務互連帶來的複雜度
某服務元件想更改 API 回應格式，譬如想拿掉一個欄位，或者改變一個欄位的型別，開發團隊得詢問所有有用到該元件的團隊，詢問/確認這次更新會不會對他們造成影響，當然也可以選擇直接新增一個全新欄位，於是下架舊的欄位變成遙遙無期的一件事，這種事情多重複個幾次，就會發現 API 裡面好幾個重複資料⋯⋯。當然，改 API 回應還算是小事，但如果是某個服務想下線，那你可能要拖個以年為單位的時間才有可能達成⋯⋯。至於為什麼？每個開發團隊都有自己的 KPI 要達成，如果下線那個舊服務不是公司重視的事情，當然是以自己團隊 KPI 優先囉（抱歉了，你就是得等）。
- 資料一致性/去中心化資料管理
通常微服務都會搭配自己的資料庫，譬如 search service 會有自己的 database, product listing service 也會有自己的 database, 這 2 個資料庫交集點就是 product 的資料，所以會產生資料一致性的問題，當商品價格/折扣改變，就得立馬透過 API 溝通，告訴 search service 有價格/折扣改變，可是有時候 search service 並不是馬上就能即時更新的，所以買賣雙方就可能會客訴為什麼價格/折扣不一致？這就是資料散在各個資料庫所帶來的管理問題，在微服務架構下，更加考驗規劃跟管理能力，如果有規劃不好的地方，很容易造成更多麻煩。如果你的微服務之間很需要保持資料一致性，可以查看看 event-driven microservices 這個關鍵字。
也由於 Microservice 架構會帶來複雜性上升的問題，所以 Semaphore 在 Medium 分享 1 篇文章，提出幾個微服務架構踐的最佳實務(best practices)，我挑了其中 4 個最切身經驗的點出來分享：
- 建立有清楚權責的跨功能開發團隊
微服務架構下通常每個開發團隊都只負責 1 個微服務，以往以角色為單位的團隊，就可能變成相對不適合微服務，想像一下某個微服務功能要改版，這時就得每個部門都派人參與，但不是每個人都熟悉這次要改版的微服務，變成負責人又要四處詢問有相關經驗的同事，溝通成本是不是變大了？然後下次派的人又不一樣了，一切又要重演。所以最好的方法是建立有清楚權責的跨功能開發團隊(cross-functional teams)，團隊中至少要有前端、後端、 DevOps 3 個角色，如此一來就有團隊能夠專責專心且有效率地開發、維護特定微服務。（說到這裡，總覺得是暗示組織不夠大的話，不要輕易嘗試微服務架構。噢對，至於績效怎麼評，那好像又是另一個故事囉⋯⋯。）
- 使用正確的工具及框架
由於微服務架構將整個應用切成多個服務，從開發面來看就是每個開發團隊都能打造自己的開發框架、部署流程，但如果自由到每個團隊都從 0 開始打造，從管理面來看就是一種效率/金錢浪費，所以最好約定幾個共通的開發工具/框架，以及盡量統一部署流程，可以滿足絕大多數團隊的需求之外，也減少效率/金錢的浪費，最重要的是降低管理的複雜性。
- 導入 DevSecOps 讓服務更加安全
根據水桶理論，水是從一個桶子最低的邊緣洩漏的，資安事件也是，總是從防護最薄弱的服務開始出現問題。微服務架構下，每個對外服務都可能面臨風險，而且不是所有開發團隊都能具有高度的資安意識跟開發水準，所以導入 DevSecOps 可以幫助提高服務的安全水準，開發生命週期的每個階段都可以有 DevSecOps 的參與，包含 code review, 設定稽核(auditing)、弱點掃描、滲透測試等等，這些其實都是為了保護企業盡量遠離資安事件所帶來的麻煩以及後續影響，也是為了保護各位的工作。
- 使用有效的監控系統
微服務架構下，要同時監控幾百到上千台伺服器是相當可能的事，如果不做監控，最後就很有可能會發現居高不下的帳單，原因在於各個團隊很可能會忘記 scale down server spec 或是過度寬估 server spec 而造成不必要的支出。另外，監控系統也可以在出問題時提供團隊線索解決問題。最後，監控系統最好統一而且方便所有人存取，不要各個團隊都用不一樣的，或者只有少數人知道監控系統在哪裡，這樣做可以統一溝通語言，提升溝通效率之外，也是方便求助外援（總不可能喊支援，結果支援來了還要學系統怎麼用吧，火都在燒了）。
總結，還是使用適合自己的架構吧，沒有不導入微服務架構就會落伍這件事，每個規模本來就有適合每個規模的做法，不一定要跟風。
