現在很多公司，例如 Amazon、阿裡 和Netflix，已經通過采用稱為微服務架構模式的方式解決單體地獄問題。與其構建一個龐大的單體應用程序，不如将您的應用程序拆分為一組更小的、相互連接的服務。

服務通常實現一組不同的特性或功能，例如訂單管理、客戶管理等。每個微服務都是一個微型應用程序，具有自己的六邊形架構，由業務邏輯和各種适配器組成。一些微服務會公開一個由其他微服務或應用程序客戶端使用的 API。其他微服務可能會實現 Web UI。在運行時，每個實例通常是雲虛拟機或 Docker 容器。

例如，打車軟件系統的可能分解如下圖所示：

示例乘車應用程序的微服務架構，每個微服務都提供一個 RESTful API

應用程序的每個功能區域現在都由其自己的微服務實現。此外，Web 應用程序被拆分為一組更簡單的 Web 應用程序（例如，在我們的出租車打車示例中，一個用于乘客，一個用于司機）。這使得為特定用戶、設備或特殊用例部署不同的體驗變得更加容易。

每個後端服務都公開一個 REST API，大多數服務使用其他服務提供的 API。例如，Driver Management 使用通知服務器來告知可用的司機有關潛在行程的信息。UI 服務調用其他服務以呈現網頁。服務也可能使用異步的、基于消息的通信。本系列稍後将更詳細地介紹服務間通信。

一些 REST API 也暴露給司機和乘客使用的移動應用程序。但是，這些應用程序不能直接訪問後端服務。相反，通信由稱為API 網關的中介進行調解。API Gateway 負責負載均衡、緩存、訪問控制、API 計量和監控等任務，并且可以使用 NGINX 有效地實現API 網關。

在 Y 軸上将功能分解為微服務的“Scale Cube

微服務架構模式對應于Scale Cube的 Y 軸縮放，這是來自優秀書籍The Art of Scalability 的可擴展性的 3D 模型。另外兩個縮放軸是 X 軸縮放，它包括在負載均衡器後面運行應用程序的多個相同副本，以及 Z 軸縮放（或數據分區），其中請求的屬性（例如，主鍵行或客戶身份）用于将請求路由到特定服務器。

應用程序通常一起使用這三種類型的縮放。Y 軸縮放将應用程序分解為微服務，如本節第一張圖所示。在運行時，X 軸擴展在負載均衡器後面運行每個服務的多個實例，以提高吞吐量和可用性。一些應用程序還可能使用 Z 軸縮放來劃分服務。下圖顯示了旅行管理服務如何與在 Amazon EC2 上運行的 Docker 一起部署。

用于搭車服務的示例微服務應用程序，部署在 Docker 容器中并由負載均衡器提供前端

在運行時，行程管理服務由多個服務實例組成。每個服務實例都是一個 Docker 容器。為了實現高可用性，容器在多個雲虛拟機上運行。在服務實例前面是一個負載均衡器，例如 NGINX，它在實例之間分配請求。負載平衡器還可以處理其他問題，例如緩存、訪問控制、API 計量和監控。

微服務架構模式顯着影響應用程序和數據庫之間的關系。每個服務都有自己的數據庫模式，而不是與其他服務共享單個數據庫模式。一方面，這種方法與企業級數據模型的想法不一緻。此外，它通常會導緻某些數據重複。但是，如果您想從微服務中受益，那麼每個服務都有一個數據庫模式是必不可少的，因為它可以确保松散耦合。下圖顯示了示例應用程序的數據庫架構。

乘車服務示例微服務應用程序中的數據庫架構

每個服務都有自己的數據庫。此外，服務可以使用最适合其需求的數據庫類型，即所謂的多語言持久性架構。例如，尋找靠近潛在乘客的司機的司機管理必須使用支持有效地理查詢的數據庫。

從表面上看，微服務架構的模式類似于 SOA。使用這兩種方法，架構都由一組服務組成。然而，考慮微服務架構模式的一種方式是，它是一種 SOA，沒有Web 服務規範和企業服務總線 (ESB) 的商業化和感知包袱。基于微服務的應用程序更喜歡更簡單、輕量級的協議，例如 REST，而不是 WS-*。他們也非常避免使用 ESB，而是在微服務本身中實現類似 ESB 的功能。微服務架構模式也拒絕 SOA 的其他部分，例如規範模式的概念。

微服務架構模式有許多重要的好處。首先，它解決了業務複雜性問題。它将原本龐大的單體應用程序分解為一組服務。雖然功能總量不變，但應用程序已被分解為可管理的業務或服務。每個服務都有一個以 RPC 或消息驅動的 API 形式定義好的邊界。微服務架構模式強制執行一定程度的模塊化，在實踐中，使用單體代碼庫很難實現。因此，單個服務的開發速度要快得多，并且更容易理解和維護。

其次，這種架構使每個服務都可以由專注于該服務的團隊獨立開發。開發人員可以自由選擇任何有意義的技術，前提是服務遵守 API 合同。當然，大多數組織都希望避免完全的無政府狀态并限制技術選擇。然而，這種自由意味着開發人員不再有義務使用在新項目開始時可能已經過時的技術。在編寫新服務時，他們可以選擇使用當前技術。此外，由于服務相對較小，使用當前技術重寫舊服務變得可行。

第三，微服務架構模式使每個微服務都可以獨立部署。開發人員永遠不需要協調其服務本地更改的部署。這些類型的更改可以在經過測試後立即部署。例如，UI 團隊可以執行 A/B 測試并快速叠代 UI 更改。微服務架構模式使持續部署成為可能。

最後，微服務架構模式使每個服務都可以獨立擴展。您可以僅部署滿足其容量和可用性限制的每個服務的實例數量。此外，您可以使用最符合服務資源要求的硬件。例如，您可以在 EC2 計算優化實例上部署 CPU 密集型圖像處理服務，并在 EC2 内存優化實例上部署内存數據庫服務。

正如弗雷德布魯克斯在将近 30 年前所寫的那樣，沒有靈丹妙藥。與其他所有技術一樣，微服務架構也有缺點。一個缺點是名稱本身。*微*服務一詞過分強調服務規模。事實上，有些開發人員主張構建極其細粒度的 10-100 LOC 服務。雖然小型服務更可取，但重要的是要記住它們是達到目的的手段，而不是主要目标。微服務的目标是充分分解應用程序，以促進敏捷應用程序的開發和部署。

微服務的另一個主要缺點是由于微服務應用程序是分布式系統這一事實而産生的複雜性。開發人員需要選擇并實現基于消息傳遞或 RPC 的進程間通信機制。此外，他們還必須編寫代碼來處理部分失敗，因為請求的目的地可能很慢或不可用。雖然這些都不是火箭科學，但它比在模塊通過語言級方法/過程調用相互調用的單體應用程序中複雜得多。

微服務的另一個挑戰是分區數據庫架構。更新多個業務實體的業務事務相當普遍。這些類型的事務在單體應用程序中實現起來很簡單，因為隻有一個數據庫。但是，在基于微服務的應用程序中，您需要更新由不同服務擁有的多個數據庫。使用分布式事務通常不是一種選擇，不僅僅是因為CAP 定理。當今許多高度可擴展的 NoSQL 數據庫和消息傳遞代理根本不支持它們。您最終不得不使用基于最終一緻性的方法，這對開發人員來說更具挑戰性。

測試微服務應用程序也複雜得多。例如，使用 Spring Boot 這樣的現代框架，編寫一個啟動單體 Web 應用程序并測試其 REST API 的測試類是微不足道的。相比之下，服務的類似測試類将需要啟動該服務和它所依賴的任何服務（或至少為這些服務配置存根）。再一次，這不是火箭科學，但重要的是不要低估這樣做的複雜性。

微服務架構模式的另一個主要挑戰是實現跨多個服務的更改。例如，假設您正在實現一個需要更改服務 A、B 和 C 的故事，其中 A 依賴于 B，B 依賴于 C。在單體應用程序中，您可以簡單地更改相應的模塊，集成更改，并一次性部署它們。相反，在微服務架構模式中，您需要仔細計劃和協調對每個服務的更改的推出。例如，您需要更新服務 C，然後是服務 B，最後是服務 A。幸運的是，大多數更改通常隻影響一項服務，而需要協調的多服務更改相對較少。

部署基于微服務的應用程序也更加複雜。單一應用程序隻需部署在傳統負載均衡器後面的一組相同服務器上。每個應用程序實例都配置有基礎設施服務的位置（主機和端口），例如數據庫和消息代理。相比之下，微服務應用程序通常由大量服務組成。例如，根據Adrian Cockcroft的說法，Hailo 擁有 160 種不同的服務，而 Netflix 擁有超過 600 種服務*[編輯——Hailo 已被 MyTaxi 收購。]*. 每個服務将有多個運行時實例。這是需要配置、部署、擴展和監控的更多活動部件。此外，您還需要實現服務發現機制（将在稍後的文章中讨論），使服務能夠發現它需要與之通信的任何其他服務的位置（主機和端口）。傳統的基于故障單的手動操作方法無法擴展到這種複雜程度。因此，成功部署微服務應用程序需要開發人員更好地控制部署方法，以及高度自動化。

實現自動化的一種方法是使用現成的 PaaS，例如Cloud Foundry。PaaS 為開發人員提供了一種部署和管理微服務的簡單方法。它使他們免受諸如采購和配置 IT 資源之類的顧慮。同時，配置 PaaS 的系統和網絡專業人員可以确保符合最佳實踐和公司政策。另一種自動化微服務部署的方法是開發本質上是您自己的 PaaS。一個典型的起點是将集群解決方案（如Kubernetes與 Docker 等技術結合使用。在本系列的後面，我們将了解基于軟件的應用程序交付 NGINX Plus 等方法可以輕松處理微服務級别的緩存、訪問控制、API 計量和監控，可以幫助解決這個問題。

構建複雜的應用程序本質上是困難的。單體架構隻對簡單、輕量級的應用程序有意義。如果您将它用于複雜的應用程序，您最終将陷入痛苦的世界。盡管存在缺陷和實施挑戰，但微服務架構模式是複雜、不斷發展的應用程序的更好選擇。

本站所有文章和資源僅為個人工作和學習中的記錄，部分觀點有一定主觀性，若有不妥，歡迎斧正。

歡迎指出網站中有問題的地方，我會盡快修正，謝謝！歡迎轉載謝謝！

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部