微服務架構

一、上下文

您正在開發服務器端企業應用程序。它必須支持各類不一樣的客戶端，包括桌面瀏覽器，移動瀏覽器和本機移動應用程序。該應用程序還可能會公開供第三方使用的API。它還能夠經過Web服務或消息代理與其餘應用程序集成。應用程序經過執行業務邏輯來處理請求（HTTP請求和消息）; 訪問數據庫; 與其餘系統交換消息; 並返回HTML / JSON / XML響應。存在與應用程序的不一樣功能區域相對應的邏輯組件。

二、問題

應用程序的部署架構是什麼？

三、目的

有一組開發人員正在處理該應用程序 新團隊成員必須迅速提升工做效率 應用程序必須易於理解和修改 您但願實踐應用程序的持續部署 您必須在多臺計算機上運行該應用程序的多個實例，以知足可伸縮性和可用性要求 您想利用新興技術（框架，編程語言等）

解決方案

虛構的電子商務應用程序 讓咱們假設您正在構建一個電子商務應用程序，該應用程序接收來自客戶的訂單，驗證庫存和可用信用，並運送它們。該應用程序包含幾個組件，包括實現用戶界面的StoreFrontUI，以及用於檢查信用，維護庫存和裝運訂單的一些後端服務。該應用程序包含一組服務。

優勢

該解決方案具備許多優勢：

支持大型複雜應用程序的持續交付和部署。 改進的可維護性 - 每項服務都相對較小，所以更易於理解和更改 更好的可測試性 - 測試服務更小，速度更快 更好的可部署性 - 能夠獨立部署服務 它使您可以圍繞多個自治團隊組織開發工做。每一個（所謂的兩個披薩）團隊擁有並負責一項或多項服務。每一個團隊均可以獨立於全部其餘團隊開發，測試，部署和擴展他們的服務。 每一個微服務都相對較小： 開發人員更容易理解 IDE能夠更快地提升開發人員的工做效率 應用程序啓動速度更快，這使開發人員的工做效率更高，並加快了部署速度 改善了故障隔離。例如，若是一個服務中存在內存泄漏，則只會影響該服務。其餘服務將繼續處理請求。相比之下，單片架構中的一個行爲不當的組件可能會致使整個系統崩潰。 消除對技術堆棧的任何長期承諾。在開發新服務時，您能夠選擇新的技術堆棧。一樣，在對現有服務進行重大更改時，您可使用新技術堆棧重寫它。

缺點

該解決方案有許多缺點：

開發人員必須處理建立分佈式系統的額外複雜性： 開發人員必須實現跨服務通訊機制並處理部分失敗 實現跨多個服務的請求更加困難 測試服務之間的交互更加困難 實現跨多個服務的請求須要團隊之間的仔細協調 開發人員工具/ IDE面向構建單一應用程序，並不爲開發分佈式應用程序提供明確支持。 部署複雜性。在生產中，還存在部署和管理由許多不一樣服務組成的系統的操做複雜性。 增長內存消耗。微服務架構用NxM服務實例替換N個單片應用程序實例。若是每一個服務都在本身的JVM（或等效服務器）中運行，這一般是隔離實例所必需的，那麼就會產生M倍運行時M次的開銷。此外，若是每一個服務都在本身的VM上運行（例如EC2實例），就像Netflix同樣，開銷甚至更高。

什麼時候使用微服務架構？

使用這種方法的一個挑戰是決定什麼時候使用它。在開發應用程序的第一個版本時，您一般不會遇到此方法所解決的問題。此外，使用精心設計的分佈式架構將減緩開發速度。對於初創公司而言，這多是一個主要問題，其最大的挑戰一般是如何快速發展業務模型和隨附的應用程序。使用Y軸拆分可能會使快速迭代變得更加困難。然而，稍後，當挑戰是如何擴展而且您須要使用功能分解時，糾結的依賴關係可能使您難以將總體應用程序分解爲一組服務。

如何將應用程序分解爲服務？

另外一個挑戰是決定如何將系統劃分爲微服務。這是一門藝術，但有許多策略能夠提供幫助：

按業務能力分解並定義與業務功能相對應的服務。 經過域驅動設計子域進行分解。 經過動詞或用例分解並定義負責特定操做的服務。例如Shipping Service，負責運送完整訂單。 經過定義一個服務來分解名詞或資源，該服務負責對給定類型的實體/資源的全部操做。例如 Account Service，負責管理用戶賬戶的人。 理想狀況下，每項服務應該只有一小部分職責。（叔叔）Bob Martin談到使用單一責任原則（SRP）設計課程。SRP將類的責任定義爲改變的理由，並聲明類只應有一個改變的理由。將SRP應用於服務設計也是有意義的。

另外一個有助於服務設計的類比是Unix實用程序的設計。Unix提供了大量的實用程序，如grep，cat和find。每一個實用程序都完成一件事，一般很是好，而且可使用shell腳本與其餘實用程序結合執行復雜的任務。

如何保持數據一致性？

爲了確保鬆散耦合，每一個服務都有本身的數據庫。維護服務之間的數據一致性是一項挑戰，由於2階段提交/分佈式事務不是許多應用程序的選項。應用程序必須使用Saga模式。服務在其數據發生更改時發佈事件。其餘服務使用該事件並更新其數據。有幾種方法可靠地更新數據和發佈事件，包括事件採購和事務日誌拖尾。

如何實現查詢？

另外一個挑戰是實現須要檢索多個服務所擁有的數據的查詢。

該API組成，並命令查詢職責隔離（CQRS）模式。

相關模式

有許多與微服務模式相關的模式。該單機結構是將微服務架構的替代方案。其餘模式解決了在應用微服務架構時將遇到的問題。