微服務例舉（續）

什麼是微服務？

微服務架構的基礎是將單個應用程序開發爲一套小型獨立服務，這些服務在本身的流程中運行，獨立開發和部署。

如圖1-4所示，經過將單片應用層分解爲獨立的面向業務功能的服務，能夠將在線零售軟件應用程序轉換爲微服務架構。 此外，咱們經過將其功能分解爲每一個服務來擺脫中央ESB，以便服務處理服務間通訊和組合邏輯。

 

圖1-4使用微服務架構構建的在線零售應用程序

所以，微服務層的每一個微服務都提供了明肯定義的業務能力（最好是小範圍），它們是獨立設計，開發，部署和管理的。

儘管與其通訊的ESB和服務層發生了變化，但API管理層幾乎保持不變。 API網關和管理層將業務功能公開爲託管API;咱們能夠選擇將網關隔離到獨立的基於每一個API的運行時。

深刻了解微服務的主要特徵。

以業務能力爲導向

微服務體系結構的一個關鍵概念是，服務必須基於業務功能進行設計，以便給定的服務可以知足特定的業務目的，並具備明肯定義的職責。給定的服務應該專一於只作一件事並作得好。

重要的是要理解粗粒度服務（例如在SOA上下文中開發的Web服務）或細粒度服務（不映射到業務能力）不適合微服務架構。相反，服務的大小應該徹底基於範圍和業務功能。此外，請記住，使服務過小（即，針對映射到業務功能的細粒度功能）將被視爲反模式。

示例場景中，在SOA / Web服務實現中使用了粗粒度服務，例如Product，Order等（參見圖1-3），當咱們進入微服務時，咱們肯定了一組更細粒度的服務，面向業務能力的服務，例如產品詳細信息，訂單處理，產品搜索，購物車等。

服務的大小永遠不會根據代碼行數或處理該服務的人數來肯定。諸如單一責任原則（SRP），康威定律，十二因子應用程序，域驅動設計（DDD）等概念在識別和設計微服務的範圍和功能方面很是有用。將在「設計微服務」中討論圍繞業務功能設計微服務的關鍵概念和基礎知識。

自治：獨立開發，部署和擴展

擁有自治服務多是實現微服務架構背後最重要的驅動力。微服務做爲獨立實體被開發，部署和擴展。與Web服務或單一應用程序體系結構不一樣，服務不共享相同的執行運行時。相反，它們經過利用容器等技術部署爲獨立的運行時。容器和容器管理技術（如Docker，Kubernetes和Mesos）的成功和不斷增長的適應性對於實現服務自治相當重要，並有助於微服務架構的總體成功。將在「部署和運行微服務」中深刻研究微服務的部署方面。

自治服務可確保整個系統的彈性，由於已將故障與服務隔離開來。這些服務經過網絡上的服務間通訊和經過消息傳遞鬆散耦合。能夠在各類交互方式和消息格式之上構建服務間通訊（將「服務間通訊」中詳細介紹）。經過與技術無關的服務合同公開的API，消費者可使用這些合同與該服務協做。此類服務也能夠經過API網關公開爲託管API。

服務的獨立部署提供了獨立擴展服務的先天能力。隨着業務功能的消耗不一樣，咱們能夠擴展得到更多流量的微服務，而無需擴展其餘服務。

咱們能夠在電子商務應用程序用例中觀察這些微服務的特性，如圖1-3所示。粗粒度服務（如Product，Order等）與SOA / Web Services方法共享相同的應用程序服務器運行時。所以，其中一個服務中的故障（例如內存不足或CPU旋轉）可能會破壞整個應用程序服務器運行時。並且，在許多狀況下，與其餘功能相比，能夠很是頻繁地使用諸如產品搜索之類的功能。使用單一方法，沒法擴展產品搜索功能，由於它與其餘服務共享相同的應用程序服務器運行時（您必須共享整個應用程序服務器運行時）。如圖1-4所示，將這些粗粒度服務隔離到微服務中使它們能夠獨立部署，將故障隔離到每一個服務級別，並容許根據消耗的方式獨立擴展給定的微服務。

沒有中央ESB：聰明的終點以及DumbB管道

微服務架構促進了企業服務總線（ESB）的消除。 ESB曾經是大多數智能設備在基於SOA / Web服務的架構中所處的位置。微服務架構引入了一種新的服務集成方式，稱爲智能端點和啞管，而不是使用ESB。如本章前面所述，大多數業務功能都是經過底層服務和系統的集成或管理在ESB級別實現的。使用智能端點和啞管，全部業務邏輯（包括服務間通訊邏輯）都駐留在每一個微服務級別（它們是智能端點），全部這些服務都鏈接到原始消息系統（啞管） ，沒有任何業務邏輯。

大多數天真的微服務採用者認爲，經過將系統轉換爲微服務架構，他們能夠簡單地擺脫集中式ESB架構的全部複雜性。然而，現實狀況是，經過微服務架構，ESB的集中功能分散到全部微服務中。如今，ESB提供的功能必須在微服務級別實現。

由於，關鍵是ESB的複雜性不會消失。相反，它會分佈在您發的全部微服務中。微服務組合（使用同步或異步樣式），經過不一樣通訊協議的服務間通訊，諸如斷路器的彈性模式的應用，與其餘應用程序的集成，SaaS（例如，Salesforce），API，數據和專有系統以及可觀察的集成服務，均可做爲開發的微服務的一部分來實現。事實上，因爲在微服務架構中必須處理的服務數量，建立組合和服務間通訊的複雜性可能更具挑戰性（因爲網絡上的服務間通訊，服務更容易出錯） ）。

大多數早期的微服務採用者（如Netflix）只是從頭開始實現了大部分功能。可是，若是咱們要用微服務架構徹底取代ESB，必須選擇特定的技術，在微服務級別構建這些ESB的功能，而不是從頭開始從新實現它們。

下面將詳細研究和並討論一些必要的問題

將詳細介紹全部要求，並在「服務間通訊」和「集成微服務」中討論實現它們的可用技術。

失敗和容錯

因爲服務及其服務間網絡通訊的激增，微服務更容易出現故障。給定的微服務應用程序是細粒度服務的集合，所以一個或多個服務的失敗不該該致使整個應用程序崩潰。所以，咱們應該優雅地處理微服務的特定故障，以便對應用程序的業務功能的影響最小。以容錯的方式設計微服務，須要從設計，開發和部署階段調整所需的技術。

例如，在零售示例中，假設產品詳細信息微服務對電子商務應用程序的功能相當重要。所以，咱們須要應用全部與彈性相關的功能，例斷路器，災難恢復，負載平衡，故障轉移和基於流量模式的動態擴展，會在「集成微服務」中詳細討論。

使用Netflix的Chaos Monkey等工具模仿全部這些可能的故障做爲服務開發和測試的一部分很是重要。給定的服務實施還應負責全部與彈性相關的活動;這些行爲會自動驗證爲CICD（持續集成，持續交付）流程的一部分。

容錯的另外一個方面是可以觀察在生產中運行的微服務的行爲。檢測或預測服務中的故障並恢復此類服務很是重要。例如，假設您在在線零售應用程序示例中爲全部微服務啓用了監視，跟蹤，日誌記錄等。而後，您會在產品搜索服務中觀察到顯着的延遲和低TPS（每秒事務數）。這代表該服務可能在未來中斷。若是微服務是可觀察的，應該可以分析當前症狀的緣由。所以，即便在開發階段使用了混沌測試，爲全部微服務提供可靠的可觀察性基礎設施以實現容錯也很重要。咱們將在「可觀察性」中詳細討論可觀察性技術。

將會詳細介紹「集成微服務」以及「部署和運行微服務」中的容錯技術和最佳實踐。

分散式數據管理

在單一體系結構中，應用程序將數據存儲在單個和集中式邏輯數據庫中，以實現應用程序的各類功能和任務。在微服務架構中，功能分散在多個微服務中。若是咱們使用相同的集中式數據庫，那麼微服務將再也不彼此獨立（例如，若是數據庫模式由一個微服務更改，那麼將破壞其餘幾個服務）。所以，每一個微服務必須具備本身的數據庫和數據庫模式。

每一個微服務均可以有一個私有數據庫來保存須要實現其提供的業務功能的數據。給定的微服務只能訪問專用的私有數據庫，而不能訪問其餘微服務的數據庫。

在某些業務場景中，可能必須爲單個事務更新多個數據庫。在這種狀況下，其餘微服務的數據庫應能只經過相應的服務API進行更新（不容許它們直接訪問數據庫）。分散式數據管理爲您提供徹底分離的微服務，並可自由選擇不一樣的數據管理技術（SQL或NoSQL等，爲每項服務提供不一樣的數據庫管理系統）。咱們將在「數據管理」中詳細介紹微服務架構的數據管理技術。

服務治理

 SOA治理是SOA運營成功背後的關鍵驅動力之一; 它提供組織中不一樣實體（開發團隊，服務消費者等）之間的合做與協調。 雖然它定義了一套全面的理論概念做爲SOA治理的一部分，但在實踐中只有少數幾個概念被積極使用。當轉向微服務架構時，大多數有用的治理概念都被丟棄，微服務中的治理被解釋爲一個分散的過程，它容許每一個團隊/實體管理本身的域，由於它更喜歡。 分散治理適用於服務開發，部署和執行過程，但除此以外還有不少其餘內容。 所以，故意不使用分散治理這一術語。

能夠肯定治理的兩個關鍵方面：服務的設計時治理（選擇技術，協議等）和運行時治理（服務定義，服務註冊和發現，服務版本控制，服務運行時依賴性，服務全部權和使用者，實施QoS和服務可觀察性）。

微服務中的設計時治理主要是一個分散的過程，每一個服務全部者均可以自由地設計，開發和運行他們的服務。而後，他們可使用正確的工具來完成工做，而不是在單一技術平臺上進行標準化。可是，應該定義一些適用於整個組織的通用標準（例如，不管開發語言如何，全部代碼都應經過審覈流程並自動合併到主線中）。

微服務的運行時治理方面是在各個層面實現的，一般不會在微服務上下文中將其稱爲運行時治理（服務註冊表和發現是一種在微服務架構中很是有用的流行概念）。所以，若是咱們看一下運行時治理的觀點，而不是將這些概念做爲一組離散概念來學習，就更容易理解它們。

運行時治理在微服務架構中絕對相當重要（它比SOA運行時治理更重要），僅僅由於必須處理的微服務數量。運行時治理的實現一般做爲集中組件完成。例如，假設須要在在線零售應用場景中發現服務端點和元數據。而後，全部服務都必須調用集中式註冊服務（它能夠具備本身的擴展功能，可是邏輯上集中的組件）。一樣，若是咱們想要經過集中限制來應用QoS（服務質量）強制執行（例如安全性），咱們須要一箇中心位置，例如API Manager / gateway來實現這一點。實際上，一些運行時治理方面也在API網關層實現。

將在「微服務治理」和「API，事件和流」中的API管理中詳細介紹微服務治理方面。

可觀測

服務可觀察性能夠被視爲監視，分佈式日誌記錄，分佈式跟蹤以及服務的運行時行爲和依賴性和可視化的組合。所以，可觀察性也能夠被視爲運行時治理的一部分。隨着細粒度服務的激增，觀察服務的運行時行爲的能力絕對相當重要。可觀察性組件一般是微服務實現中的集中組件，而且每一個服務將數據推送到那些組件中（而不是可觀察性運行時從服務中提取數據）。可觀察性對於識別和調試潛在問題很是有用，而服務正在生產中，也可用於業務功能目的（如貨幣化）。將在「可觀察性」中討論構建可觀察服務的各類工具和技術。

微服務：福利和責任

與任何架構或技術同樣，微服務架構也有好處和責任。因爲對關鍵的微服務特性有很好的理解，所以如今是討論它們的好時機。讓咱們從微服務的好處開始。

優勢

微服務架構普及的主要緣由之一是它提供優於傳統軟件架構模式的好處。讓咱們仔細看看微服務架構的主要優勢。

商業功能的敏捷和快速發展

 微服務架構有利於自主服務開發，這有助於靈活快速地開發業務功能。在傳統架構中，將業務功能轉換爲生產就緒軟件應用程序功能須要不少週期，主要是因爲系統的大小，代碼庫和依賴性。經過自主服務開發，只須要關注服務的接口和功能（而不是整個系統的功能，這要複雜得多），由於全部其餘服務只能經過服務接口經過網絡調用進行通訊。

替換性

因爲其自主性，微服務也是可替換的。因爲咱們將服務構建爲一個獨立的實體，經過網絡調用和定義的API進行通訊，所以能夠輕鬆地將該功能替換爲另外一個更好的實現。專一於特定功能，具備限的範圍和大小，並將其部署在獨立的運行時中，全部這些都使構建可替換服務變得更加容易。

故障隔離和可預測性

可替換性還有助於實現故障隔離和預測。如上所述，因爲任何給定組件或服務的失敗，基於微服務的應用程序不會像傳統的單片應用程序那樣爆炸。具備適當的可觀察性功能還有助於識別或預測潛在的故障。

敏捷部署和可伸縮性

易於部署和擴展是微服務最重要的價值。藉助現代基於雲的容器本機基礎架構，輕鬆部署服務並動態擴展服務的能力變得微不足道。因爲正在構建自治服務功能，所以能夠輕鬆利用全部此類容器和原生雲技術來促進敏捷部署和可伸縮性。

與組織結構保持一致

因爲微服務是面向業務能力的，所以它們能夠與組織/團隊結構保持一致。一般，給定組織的結構能夠提供業務功能。所以，能夠輕鬆地將每項服務的全部權提供給擁有業務功能的團隊。所以，鑑於微服務專一於特定的業務功能，能夠選擇一個相對較小的團隊來擁有該微服務。這對開發團隊產生了積極影響，由於給定服務的範圍簡單且定義明確。這樣，團隊就能夠徹底擁有服務的整個生命週期。

責任

微服務架構的大部分責任主要是須要應對服務激增。

服務間通訊

服務間通訊複雜性可能比實際服務的實施更具挑戰性。如前所述，智能端點和啞管概念迫使將服務間通訊邏輯做爲微服務的一部分。服務開發人員必須花費大量時間在管道上的微服務，以建立複合業務的功能。

服務治理

經過網絡傳遞許多服務也使服務的治理與可觀察性方面變得複雜。若是沒有適當的治理和可觀察性工具，那麼識別服務依賴性和檢測故障將是一場噩夢。例如，使用微服務架構，服務生命週期管理，測試，發現，監控，服務質量以及各類其餘服務治理功能將變得更加複雜。

嚴重依賴於部署方法

部署和擴展微服務的成功在很大程度上取決於容器和容器編排系統的採用。若是你沒有這樣的基礎設施，將須要投入時間和精力（甚至不考慮擁有一個沒有容器而成功的微服務架構）。最終，成功的微服務架構也取決於團隊和人員。服務的全部權，考慮使服務輕量級和容器本地化，沒有集中服務等的中心點，須要組織級工程文化的變化。

分佈式數據的複雜性與事務管理

因爲微服務架構促進了將數據本地化到給定服務，所以分佈式數據管理將很是艱鉅。這一樣適用於分佈式事務。實現跨多個微服務的事務邊界將很是具備挑戰性。

如何以及什麼時候使用微服務

微服務架構如何從傳統的集中式企業架構演變而來，涵蓋了它的關鍵特性，並討論了使用它的優缺點。可是，須要有一套可靠的指南來肯定什麼時候使用微服務架構以及何時避免使用微服務架構。

當企業架構須要模塊化時，微服務架構是理想的選擇。

當嘗試使用軟件應用程序解決業務問題很是簡單，也可能根本不須要微服務（具備簡單的單片Web應用程序和數據庫一般就足夠了）。

軟件應用程序必須採用基於容器的部署。

若是系統太複雜而沒法分離到微服務中，那麼應該肯定能夠以最小的影響引入微服務的區域。而後，開始在微服務上實現一個小用例，並圍繞它構建所需的生態系統組件。

瞭解業務功能對於設計微服務相當重要。在服務實現以前，瞭解微服務設計技術（如「設計微服務」中所述）是必不可少的。

對於每一個特定的微服務域（例如數據管理，服務間通訊，安全性等），將在後面的章節中詳細討論最佳實踐和反模式。

摘要

本章的主要目標是概述企業體系結構的當前狀態以及微服務如何適應它。在節中，討論了企業架構如何從單片應用程序演變爲微服務。討論了當進入微服務時，ESB和API網關的角色如何變化。還討論了微服務架構的關鍵特性及其優缺點，這將是理解其他部分的基礎。