微服務架構
你還可以 去 github 查看 這些文檔
什么時候使用微服務架構
建議具有以下情況時使用微服務架構風格：
- 發布頻率高的大型應用程序；
- 要求具有高可擴展性的復雜應用程序；
- 具有豐富的領域或子域的應用程序；
- 由小的開發團隊構成的組織。
什么是微服務架構
微服務架構由一組小型的、自主的服務構成。每個服務都是自包含的，並且應該實現單一的業務功能。
從某種程度上看，微服務是面向服務（SOA）體系架構自然演進，但是微服務與SOA有有所不同。以下是微服務的一些特征定義：
- 在一個微服務架構中，服務是小型、獨立、低耦合的；
- 每個服務都是單獨的代碼庫，可以由一個小的開發團隊管理；
- 每個服務都可以獨立部署。一個團隊無需生成和發布整個應用程序，取而代之僅更新已有的服務即可；
- 每個服務只負責持久化他們自己的數據或外部狀態。這與傳統的模型不同，傳統的架構模型需要一個獨立的代碼層來處理數據持久化；
- 服務之間通過具有明確界限的API來彼此通信，每個服務內部的實現細節由服務隱藏；
- 服務之間無需共享相同的技術棧、代碼庫或框架。
除了服務本身之外，還有一些其他的組件出現在典型的微服務架構中：
管理
管理組件負責替換結點上的服務、識別錯誤、跨結點調整服務等等。
服務發現
服務發現組件負責維護一個列表，列表包含服務及其指向的結點。這樣就可以實現服務查找，為每個服務查找對應的結點。
API 網關
API 網關是客戶端的入口點。客戶端不會直接調用服務，而是調用 API 網關，網關會將調用指向其后端中合適的服務。API 網關可以聚合來自多個服務的職責，並返回聚合后的響應。
使用 API 網關的優點包括：
- 將客戶端與服務分離。服務可以在不更新所有客戶端的情況下版本化（發布多個版本）或重構；
- 服務可以使用 非 Web 友好的消息傳遞協議，比如 AMQP；
- API 網關可以實現其他橫切功能，比如認證、日志記錄、SSL 終端和負載均衡等等。
微服務架構的效益
- 獨立部署。你可以僅更新某個服務，而無需重新部署整個應用程序，並且在出現問題的時候進行回滾，或者滾動更新。修復 BUG 或者發布新功能變得更加可控和低風險；
- 獨立開發。單一的開發團隊就可以構建、測試和部署服務，這樣就能實現持續創新和更快的發布節奏；
- 小而專注的團隊。團隊可以只專注於某個服務。縮小每個服務的范圍域使得代碼庫更易於理解，同時新的團隊成員更容易上手；
- 故障隔離。一個服務的故障不會拖垮整個應用程序。但是這並不意味着你因此獲得了服務的彈性，你仍然需要遵循彈性設計的最佳體驗和相應的設計模式；
- 混合技術棧。團隊可以隨意選取最適合他們的服務的技術。
- 細粒度擴展。服務可以進行獨立的擴展。同時，每個VM（虛擬機）上的服務密度越高，就意味着充分利用了VM資源。使用配置約束的話，一個服務可以匹配到一個VM配置（高CPU，高內存等等）。
微服務架構面臨的挑戰
- 復雜性。一個微服務應用程序相比等效的整體應用程序具有更多的移動部件。每個服務都非常小，但整個系統作為一個整體卻將會更加復雜。
- 開發和測試。針對服務依賴的開發需要一個不同尋常的方法。現有的工具不一定是被設計用來處理服務依賴的。跨服務邊界的重構會變得非常困難。測試服務依賴也是一項挑戰，尤其是在應用程序快速發展的階段。
- 缺乏治理 用分散處理的方法來構建微服務有其優勢，同時也會帶來問題。你可能因大量不同語言和框架造成的應用程序難以維護而終結。在不過分限制團隊靈活性的情況下，將一些項目級的標准放在適當的位置可能會很有用。這尤其適用於像日志記錄這樣的橫切功能。
- 網絡擁塞和延遲 大規模使用小粒度的服務將導致大量服務交互通信。還有，如果服務依賴鏈變得太長（服務A調用服務B，服務B調用服務C......），額外的延遲就不可忽視。你需要細心地設計API，避免“太健談”的API，考慮序列化格式，在恰當的地方使用異步通信模式。
- 數據完整性 由於每個微服務只負責它自己的數據持久化，因此保持數據的完整一致成了新的挑戰。如果可以，擁抱最終一致性。
- 管理 要想成功駕馭微服務架構，必須要有一個成熟的 DevOps（開發運維） 文化。跨服務相關的日志記錄會變得極具挑戰性。通常，日志記錄必須將單個請求產生的多個服務調用記錄關聯起來。
- 版本控制 更新服務的時候，必須確保依賴於它的服務不被打斷。多個服務可以在任何給定的時間更新，因此如果沒有精心的設計，你可能會面臨向前或向后兼容性的問題。
- 整體技能 微服務是高度分布的系統。你要仔細評估你的團隊技能和經驗以確保項目成功。
微服務架構的最佳體驗
- 圍繞業務領域的模型服務；
- 分散一切，各個團隊都負責設計和構建服務，避免共享代碼或數據模式；
- 數據存儲對於數據所有者來說是私有的，這實現了每個服務和數據類型的最佳存儲；
- 服務通過設計良好的API通信，這可以避免泄露實現細節。API 應該面向領域建模，而不是服務的內部實現；
- 避免服務間的耦合，造成耦合的原因包括共享數據庫模式和嚴格的通信協議；
- 將橫切關注點從 API 網關分離出來，比如認證和 SSL 終端；
- 將領域知識維持在網關之外。網關應該在不了解業務規則或領域邏輯的情況下處理和路由客戶端請求。否則，網關會變得強依賴和導致服務之間的高度耦合；
- 服務之間應該是松散耦合、高功能內聚的。有可能同時變更的功能應該打包和部署在一起，因為如果他們駐留在獨立的服務中，那些服務會由於越來越緊密的耦合而被結束 —— 一個服務的變更將要求更新其他服務。兩個服務之間的過度通信可能是緊耦合、低內聚的征兆；
- 故障隔離，使用彈性策略可以將服務故障從服務間的關聯中隔離出來。查看彈性模式和設計彈性應用程序已了解更多信息。