[譯]微服務架構(Microservices Architecture)

標籤：style   blog   http   ar   io   color   os   使用   sp   

This a translation of an article ( http://microservices.io/patterns/microservices.html) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson).

模式：微服務架構

假設你在開發一個服務端應用。該應用必須支援各種各樣的用戶端，包括案頭瀏覽器、手機瀏覽器和本地手機應用。應用可能也需要公開部分API供第三方使用，還可能與其他應用通過web service或訊息代理(message broker)相整合。應用執行商務邏輯來處理請求(HTTP請求或者訊息)；訪問資料庫；與其他系統交換訊息；並返回HTML/JSON/XML類型的響應。

應用或是多層架構或是六角架構，並且包含多種類型的組件：

• 表示組件(Presentation components) - 響應處理HTTP請求，並返回HTML或JSON/XML(對於web service API)

• 商務邏輯(Business logic) - 應用的商務邏輯

• 資料庫訪問邏輯(Database access logic) - Data Access Objects用於訪問資料庫

• 應用整合邏輯(Application integration logic) - 訊息層，如基於Spring的整合

這些邏輯組件分別響應應用中不同的功能模組。

問題

應用的部署架構是什嗎？

推動力

• 該應用由一個開發人員團隊在維護

• 團隊新成員必須快速上手

• 應用應該易於理解和修改

• 你想對應用進行持續整合

• 你必須在多台機器上部署多份應用的拷貝，以滿足延展性和可用性的要求

• 你想使用新技術(架構、程式設計語言等)

解決方案

通過採用伸縮立方(Scale Cube)(特別是y軸方向上的伸縮)來架構應用，將應用按功能分解為一組相互協作的服務的集合。每個服務實現一組有限並相關的功能。比如，一個應用可能包含訂單管理服務，客戶管理服務等。

服務間通過HTTP/REST等同步協議或AMQP等非同步協議進行通訊。

服務獨立開發和部署。

每個服務為了與其他服務解耦，都有自己的資料庫。必要時，資料庫間的一致性通過資料庫複寫機制或應用級事件來維護。

舉例

我們假設你在構建一個電子商務應用，應用從客戶接收訂單，驗證庫存和可用額度，並派送訂單。應用程式套件含多個組件，包括StoreFrontUI，用來實現使用者介面，以及一些後台服務，用於檢測信用額度、維護庫存和派送訂單。

應用作為一組服務部署。

結果

這個方案有一些好處：

• 每個微服務都相對較小

• 易於開發人員理解

• IDE反應更快，開發人員更高效

• web容器啟動更快，開發人員更高效，並提升了部署速度

• 每個服務都可以獨立部署 - 易於頻繁部署新版本的服務

• 易於伸縮開發組織圖。你可以對多個團隊的開發工作進行組織。每個(雙披薩[1])團隊負責單個服務。每個團隊可以獨立於其他團隊開發、部署和伸縮服務。

• 提升故障隔離(fault isolation)。比如，如果一個服務存在記憶體泄露，那麼只有該服務受影響，其他服務仍然可以處理請求。相比之下，一體架構的一個出錯組件可以拖垮整個系統。

• 每個服務可以單獨開發和部署

• 消除了任何對技術棧(technologh stack)的長期投入(long-term commitments)

這個方案也有一些缺點：

• 開發人員要處理分布式系統的額外複雜度。

• 開發人員工具/IDE是面向構建一體應用的，並沒有顯示提供對開發分布式應用的支援

• 測試更加困難

• 開發人員需要實現服務間通訊機制

• 不使用分散式交易實現跨服務的用例更加困難

• 實現跨服務的用例需要團隊間的細緻協作

• 生產環境的部署複雜度。對於包含多種不同服務類型的系統，部署和管理的操作複雜度仍然存在。

• 記憶體消耗增加。微服務架構使用NxM個服務執行個體來替代N個一體應用執行個體。如果每個服務運行在自己獨立的JVM(或類似)上，通常有必要對執行個體進行隔離，對這麼多啟動並執行JVN，就有M倍的開銷。另外，如果每個服務運行在獨立的VM(如EC2執行個體)，如Netflix，開銷會更高。

使用該方法的一個挑戰就是決定何時使用才合理。在開發應用的初期，你通常不會遇到這種方法試圖解決的問題。而且，使用這個精細、分布式的架構將會拖慢開發進度。對初創公司，這是個嚴重問題，因為它們的最大挑戰通常是如何快速發展業務模型及相關應用。使用Y軸切分使快速迭代更加困難。但是之後，當挑戰變成如何伸縮，你需要使用功能分解將一體應用切分為一組服務時，混亂的依賴關係可能使之變得困難。

另一個挑戰是如何將系統分隔為微服務。這是個技術活，但有些策略可能有協助。一種方法是通過動詞或用例來分隔。比如，之後你將看到分隔後的電子商務應用有個負責派送已完成訂單的Shipping服務。另一個通過動詞分隔的例子是實現登入用例的登入服務。

另一種分隔方法是通過名稱或資源來分隔系統。這種服務負責對給定類型的實體/資源的所有操作。比如，之後你會發現為何電子商務系統有個Inventory服務來跟蹤產品是否在庫存中。

理論上，每個服務應該只承擔很小的職責。Bob Martin(大叔)講過使用單一職責原則(SRP)來設計類。SRP定義類的職責作為變化的原因，而且類應該只有一個變化的原因。使用SRP來設計服務也是合理的。

另一個有助於服務設計的類比是Unix工具 + 生產力的設計方法。Unix提供大量的工具 + 生產力如grep、cat和find。每個工具只做一件事，通常做得非常好，並且可以跟其他工具使用shell指令碼組合來執行複雜任務。

相關模式

一體架構是個替代模式。API Gateway模式 定義了用戶端如何訪問服務。

已知案例

大多數大規模的web網站，如 Netflix, Amazon和eBay都從一體架構轉變為微服務架構。

Netflix是個非常受歡迎的視頻流服務提供者，佔有多達30%的互連網流量，它有著大規模、基於服務的架構。他們每天處理800+不同類型裝置超過10億次視頻流API的請求。每個API可以展開成平均6次對後端服務的調用。

Amazon.com原有個兩層架構。為了伸縮，他們遷移到一個包含上百個後端服務的基於服務的架構。調用這些服務的應用中包括實現Amazon.com網站和web service API的應用。Amazon.com網站應用程式調用100-150個服務來擷取資料用於構建網頁。

拍賣網站ebay.com也從一體架構發展成基於服務的架構。應用程式層包含多個獨立的應用。每個應用實現特定功能模組(如購買或銷售)的商務邏輯。每個應用使用X軸的分隔，有些應用如搜尋，使用Z軸分隔。Ebay.com也對資料庫層採用X,Y,Z的組合伸縮方式。

變更

註：

[1] 雙披薩團隊(two-pizza team)：兩個披薩就可以餵飽整個團隊，指團隊規模很小。

前一篇一體化架構的翻譯，請移步這裡

[譯]微服務架構(Microservices Architecture)