什麼是微服務如何構建微服務（你了解微服務嗎）

2023-10-04 04:36:49 3

現在很多公司，例如 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 計量和監控，可以幫助解決這個問題。

總結

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

關注我

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