微服務 spring boot 譯<二> 微服務架構

What Is a Microservice Architecture?

微服務體系結構(MSA)是一種構建軟件系統的方法，它將業務域模型分解爲由服務實現的更小的、一致的、有界的上下文。這些服務器是獨立的和自治的，但它們能夠通訊以提供一些業務功能。Microservices一般由具備足夠自治權的小型團隊組成和操做，每一個團隊和服務均可以更改其內部實現細節(包括直接替換它！)，而對系統其他部分的影響最小。

團隊經過約定進行通訊，這是一種服務能夠將意圖發佈到但願使用該服務的其餘組件或系統的方式。他們用服務的接口來指定這些約定，並經過wiki記錄他們的服務。若是沒有足夠的文檔，或者API不夠清晰，服務提供者就沒有完成他的工做。在下一節中，咱們將介紹更多關於約定和約定理論的內容。

每一個團隊將負責設計服務，爲問題集選擇正確的技術，以及部署、管理和在凌晨2點醒來處理任何問題。例如，在亞馬遜，只有一個團隊擁有結帳時調用的稅務計算功能。此服務中的模型(項、地址、稅等)都理解爲「在計算稅金的上下文中」用於結賬；對於這些對象(例如，該項是返回項仍是結賬項？)沒有混淆。擁有稅務計算服務的團隊設計、開發和運營這項服務。亞馬遜擁有一套成熟的自助服務工具，能夠自動完成許多構建/部署/操做步驟，但咱們將繼續討論這個問題。

使用微服務，咱們能夠肯定服務的範圍，這對咱們頗有幫助：

• 瞭解服務正在作什麼，而不與更大應用程序中的其餘問題糾纏在一塊兒

• 在本地快速構建服務

• 爲問題選擇合適的技術(大量的寫入？大量的查詢？低延遲？突發？)

• 以業務所需的節奏構建/部署/發佈，這可能獨立於其餘服務

• 在須要的地方識別和水平縮放體系結構的各個部分

• 提升整個系統的彈性

微服務幫助解決了「咱們如何將服務和團隊解耦以在規模上快速移動？」的問題。它容許團隊專一於提供服務，並在必要時進行更改，而無需花費昂貴的同步點。如下是一些一旦您採用了微服務就不會聽到的內容：

• Jira tickets

• 沒必要要的會議

• 分享庫

• 企業範圍的規範模型

微服務架構適合您嗎？微服務有不少好處，但它們也有本身的缺點。你能夠將微服務看做是對一些問題的優化，這些問題須要有能力在規模上快速地改變事物，但須要付出必定的代價。效率不高。它能夠是更多的資源密集型。你可能最終會獲得看起來像複製的東西。操做的複雜性要高得多。從總體上理解這個系統變得很是困難。調試問題變得很是困難。在某些領域，您可能不得不放寬事務的概念。團隊可能沒有被設計成這樣工做。

不是業務的每個部分都能在一毛錢內改變。不少面向客戶的應用程序都這樣作。後端系統可能不會。可是，當這兩個世界開始融合在一塊兒時，咱們可能會看到證實微服務體系結構合理性的力量被推到了系統的其餘部分。

Challenges

按照微服務方法設計雲本地應用程序須要對如何構建、部署和操做它們進行不一樣的思考。咱們不能僅僅構建咱們的應用程序--咱們知道它將失敗的全部方式--而後僅僅阻止它們。在使用微服務構建的複雜系統中，咱們必須可以處理不肯定性。本節將肯定在開發微型服務時須要牢記的五個主要事項。

Design for Faults

在複雜的系統中，事情會失敗。硬盤崩潰，網絡電纜被拔掉，咱們對實時數據庫進行維護，而不是備份，VM消失。單個故障可能傳播到系統的其餘部分，並致使級聯故障，從而致使整個系統崩潰。

傳統上，在構建應用程序時，咱們會嘗試預測應用程序的哪些部分(例如n層)可能會失敗，並構建一堵足夠大的牆來防止失敗。這種心態在規模上是有問題的，由於咱們不能老是預測在複雜系統中什麼事情會出錯。事情會失敗，因此咱們必須發展咱們的應用程序，使其具備彈性並處理失敗，而不只僅是防止它。咱們應該可以優雅地處理故障，而不是讓故障傳播到系統的所有故障。

構建分佈式系統不一樣於構建共享內存、單一進程、單一應用程序。一個明顯的不一樣之處是，經過網絡進行的通訊不一樣於具備共享內存的本地調用。網絡本質上是不可靠的。網絡上的呼叫可能因爲各類緣由而失敗(例如，信號強度、壞的電纜/路由器/交換機和防火牆)，這多是瓶頸的主要來源。網絡不可靠性不只會影響對你服務的客戶的響應時間，並且還會致使上游系統故障。

潛在的網絡調用可能很難調試；理想狀況下，若是您的網絡調用沒法成功完成，它們將當即失敗，而且您的應用程序會迅速發出通知(例如，經過IOException)。在這種狀況下，咱們能夠快速採起糾正措施，提供降級功能，或者僅僅用一條消息響應，說明請求沒法正確完成，用戶應該稍後再試一次。可是，網絡請求或分佈式應用程序中的錯誤並不老是那麼簡單。若是你必須調用的下游應用程序比正常狀況下須要更長的響應時間，該怎麼辦？這是致命的，由於如今你的應用程序必須考慮到這種緩慢，經過節流請求，超時下游請求，並潛在地拖延經過您的服務的全部調用。這種備份可能會致使上游服務速度放緩，並逐漸中止。它會致使級聯故障..。

Design with Dependencies in Mind

爲了可以從組織或分佈式系統的角度快速移動和敏捷，咱們必須在設計系統時考慮依賴關係；咱們的團隊、技術和治理中須要鬆散的耦合。微服務的目標之一是利用自主團隊和自動服務。這意味着可以在不影響您周圍的服務或整個系統的狀況下，根據業務需求快速地進行更改。這也意味着咱們應該可以依賴於服務，可是若是它們不可用或降級，咱們須要可以優雅地處理它。
在「面向依賴」(InfoQ Enterprise Software Development Series)一書中，Ganesh Prasad說：「創造性的原則之一就是放棄約束。換句話說，若是你在精神上消除了一個或多個依賴，你就能想出解決問題的創造性辦法「。問題是，咱們的組織是在考慮效率的狀況下構建的，這就帶來了許多錯綜複雜的依賴關係。

例如，當您須要與其餘三個團隊協商對你的服務(DBA、QA和Security)進行更改時，這並非很是靈活；這些同步點中的每個均可能致使延遲。這是一個脆弱的過程。若是您可以擺脫這些依賴關係，或者將它們構建到你的團隊中(咱們絕對不能犧牲安全性或質量，因此將這些組件構建到您的團隊中)，您就能夠自由地進行創新，更快地解決客戶面臨的問題或業務預見到的問題，而不會遇到昂貴的瓶頸。

依賴性管理故事的另外一個角度是如何處理遺留系統。向下遊系統公開後端遺留系統的詳細信息(COBOL副本結構、特定系統使用的XML序列化格式等)會致使災難。作一個小小的改變(客戶ID如今是20個數字字符而不是16個)如今波及整個系統，並使那些下游系統所作的假設失效，有可能打破這些假設。咱們須要仔細考慮如何將系統的其他部分與這些類型的依賴隔離開來。

原文：

做者源碼：https://github.com/redhat-developer/microservices-by-example-source