作者：Chandani Patel，Nupur Patel

“微服務”是軟件架構(gòu)領域最流行的流行語之一。雖然我們的第一篇文章討論了微服務的基本原理和優(yōu)勢，但在本文中，我們將解釋企業(yè)如何利用關(guān)鍵架構(gòu)原則在實際用例中實現(xiàn)微服務。

如何從設計基于微服務的解決方案體系結(jié)構(gòu)開始

基于微服務的解決方案架構(gòu)并不總是最適合所有用例，使用一刀切的方法有幾個缺點。在設計基于微服務的解決方案體系結(jié)構(gòu)之前，企業(yè)解決方案架構(gòu)師必須解決以下問題。

微服務架構(gòu)是否適合該解決方案？

應該如何定義微服務架構(gòu)？

在為應用程序的第一個版本構(gòu)建微服務架構(gòu)時，我們建議采用“整體式”方法。這意味著您以簡單的方式構(gòu)建應用程序，以首先驗證您的想法。然后，應用此博客中包含的原則，將初始整體式架構(gòu)擴展并演變?yōu)榛谖⒎盏慕鉀Q方案體系結(jié)構(gòu)。創(chuàng)建架構(gòu)純微服務，不能為業(yè)務提供價值，這是沒有價值的。整體架構(gòu)模式將幫助您了解有關(guān)大型復雜系統(tǒng)的幾個問題和限制（微服務架構(gòu)可能會發(fā)生這種情況）。

1. 將應用程序分解為服務

微服務架構(gòu)是一組松散耦合的服務，將應用程序分解為服務在微服務架構(gòu)實現(xiàn)、部署和 CI/CD 中起著關(guān)鍵作用。

解決方案架構(gòu)師可以根據(jù)需求和解決方案定義分解方法，沒有“最佳”分解方法，但有常見的方法，可以幫助您在下面提到的幾種服務中分解解決方案。要應用分解，您需要了解每個組件的需求和角色、多個組件之間的權(quán)重/鏈接以及整個解決方案的每個組件的更多因素。

分解策略：

按模塊/業(yè)務能力分解：此方法建議為每個模塊或功能定義每個組件，即消息傳遞，日志記錄，設備通信，用戶管理。這有助于您將整個功能/模塊分配給單獨的團隊，其中各個團隊將負責模塊/功能

按域分解： 此方法建議定義要部署解決方案的區(qū)域，并進一步定義該區(qū)域的服務。定義與域驅(qū)動設計 （DDD） 子域?qū)姆?。DDD 將應用程序的問題空間（業(yè)務）稱為域。一個域由多個子域組成。每個子域?qū)跇I(yè)務的不同部分。例如用戶管理、設備管理、設備通信

分解時要考慮的事項：

查找每項服務的邊界，并使其與業(yè)務功能保持一致

專注于定義微服務的范圍，而不僅僅是縮小服務。服務的（正確）大小應該是促進給定業(yè)務能力所需的大小

該服務應該具有很少的操作/功能和簡單的消息格式

確保微服務設計確保服務的敏捷/獨立開發(fā)和部署

每個服務都必須可單獨測試和部署

服務必須具有凝聚力。服務應實現(xiàn)一小組強相關(guān)的函數(shù)

每個服務都應該足夠小，以便可以由 6 名成員組成的小團隊開發(fā)

應用程序必須易于理解和修改

該服務必須在負載均衡器基礎結(jié)構(gòu)（如 ELB）中可縮放

2. 微服務發(fā)現(xiàn)和注冊

微服務架構(gòu)使用服務注冊中心來維護發(fā)送請求的服務位置，該注冊表可以在服務端或客戶端進行管理。服務可以自行注冊，也可以通過第三方（部署腳本）注冊服務。每個服務都應在服務啟動時使用運行狀況檢查接口在注冊表上注冊自身。運行狀況檢查接口可幫助注冊表檢查服務可用性。定義服務注冊表時，必須實現(xiàn)一種機制，使服務的客戶端能夠向一組動態(tài)更改的臨時服務實例發(fā)出請求。

3. 微服務通信

為此，體系結(jié)構(gòu)必須允許每個服務相互通信。以下是定義服務間通信的多種方法：

遠程進程調(diào)用：遠程過程調(diào)用將封裝原則應用于集成服務。如果應用程序需要修改另一個應用程序的數(shù)據(jù)，則它通過調(diào)用另一個應用程序來實現(xiàn) 每個服務都可以維護其擁有的數(shù)據(jù)的完整性。此外，每個服務都可以更改其內(nèi)部數(shù)據(jù)，而不會使其他每個應用程序受到影響。您可以使用grpc，Apache Thrift和REST進行此類通信。

消息：使用 Kafka、RabbitMq 等工具在服務間通信中使用異步消息傳遞。當每個請求都是獨立的并且不需要任何回調(diào)時，這將起作用

域特定調(diào)用：使用域特定協(xié)議進行服務間調(diào)用，例如SMTP或IMAP用于電子郵件，RTSP，RTMP，HLS或HTTP用于媒體流

4. 微服務觀察

觀察是微服務框架的另一個關(guān)鍵點。這允許您調(diào)試和監(jiān)視每個服務。在設計微服務時，有幾個方面需要解決。

日志聚合：使用來自每個服務實例的集中日志。用戶/審閱者可以搜索和分析日志。他們可以配置多個嚴重錯誤的警報，并按類別檢查錯誤數(shù)。這可以通過將logstash集成為中央日志服務器來實現(xiàn)

運行狀況檢查：運行狀況檢查界面可幫助用戶/審閱者檢查服務是否可用。這可以通過創(chuàng)建具有靜態(tài)響應的 REST 接口并集成負載均衡器來實現(xiàn)，該負載均衡器會定期檢查 API 的運行狀況并更新服務狀態(tài)。

應用程序指標：它提供服務狀態(tài)指標，包括信息，例如 – 每個 API 調(diào)用多少次？來自的最大請求數(shù)來自何處？此服務在后臺運行，并與服務器的每個操作交互，因此您選擇的服務應占用最小的運行時開銷。例如，節(jié)點的Appmetrics，JAVA的Coda Hale

日志部署和更改：查看部署和其他更改何時發(fā)生非常有用，因為問題通常在更改后立即發(fā)生。例如，啟用部署狀態(tài)通知，啟用應用程序崩潰通知

5. 微服務數(shù)據(jù)庫管理

大多數(shù)服務需要在數(shù)據(jù)庫中具有持久性數(shù)據(jù)。例如，設備服務存儲有關(guān)設備的信息，用戶服務存儲有關(guān)用戶的信息。

數(shù)據(jù)庫管理策略：

在微服務框架中管理數(shù)據(jù)庫有多種方法。

每個服務的數(shù)據(jù)庫：將每個微服務的持久數(shù)據(jù)保密為該服務，并且只能通過其 API 訪問

解決方案的共享數(shù)據(jù)庫：使用由多個服務共享的（單個）數(shù)據(jù)庫。每個服務使用本地 ACID 事務自由訪問其他服務擁有的數(shù)據(jù)

混合數(shù)據(jù)庫：分別創(chuàng)建一個通用的共享數(shù)據(jù)庫和特定于服務的數(shù)據(jù)庫，例如，在典型的物聯(lián)網(wǎng)云平臺即服務中，架構(gòu)師可以選擇將請求超時存儲在特定數(shù)據(jù)庫中，該數(shù)據(jù)庫只能通過該模塊公開的特定服務進行訪問

管理數(shù)據(jù)庫時要考慮的事項：

某些業(yè)務事務必須強制實施跨多個服務的不變量

某些業(yè)務事務需要查詢由多個服務擁有的數(shù)據(jù)。例如，要檢索用戶設備，它將從用戶服務和設備服務請求詳細信息

某些查詢必須聯(lián)接由多個服務擁有的數(shù)據(jù)

有時必須復制和共享數(shù)據(jù)庫才能擴展

不同的服務有不同的數(shù)據(jù)存儲要求。例如，日志服務將使用LogStash，用戶服務和設備管理將使用MongoDB

6. 微服務外部接口（API 網(wǎng)關(guān)）

外部接口是用戶/應用程序與微服務交互的入口。實現(xiàn) API 網(wǎng)關(guān)，為來自客戶端的所有服務請求啟用單個入口點。API 網(wǎng)關(guān)將對請求進行身份驗證，并將代理/路由到實際服務。API 網(wǎng)關(guān)為受保護的端點實現(xiàn)安全性（在標頭或查詢參數(shù)中包含訪問令牌）。企業(yè)架構(gòu)師應設計 API 網(wǎng)關(guān)來負責安全性、應用程序數(shù)據(jù)保護和請求限制數(shù)量（每個用戶、每個 IP 或每個應用程序），以防止 DDoS 攻擊。

7. 微服務測試

嘗試測試與其他服務通信的應用程序時，可以執(zhí)行以下兩項操作之一：

部署所有微服務并執(zhí)行端到端測試：在測試環(huán)境中模擬生產(chǎn)，并在部署之前運行端到端測試。此方法將測試實際用例并確保服務質(zhì)量。這種測試的缺點是它們非常耗時且調(diào)試非常困難

在單元/集成測試中模擬其他微服務：模擬外部服務并運行單元測試和集成測試。這種方法非?？欤荒鼙ＷC生產(chǎn)安全

測試微服務的常見建議是使用組合集成測試和單元測試。將一些測試作為單元測試運行，其中一些作為集成測試運行，以確保解決方案中所需的質(zhì)量。

在計劃測試時，您必須將服務組件測試和服務集成合同測試作為測試過程的一部分。您可以在開發(fā)中使用多個測試工具/框架，例如Junit，Java和Mocha的Spring Cloud Contract，Chai，Sinon，Proxyquire等，用于Nodejs。您可以通過checkstyle生成HTML報告，以驗證測試報告和代碼覆蓋率。

理想情況下，建議對任何源代碼使用 80% 的代碼覆蓋率。

8. 微服務;持續(xù)集成和部署

每個服務都部署為一組服務實例，以實現(xiàn)吞吐量和可用性。

CICD戰(zhàn)略：

每個實例多個服務： 在同一主機（物理或虛擬）上運行多個服務。例如，將所有 NodeJS 服務部署在 EC2 實例上作為單獨的服務。當您處于開發(fā)階段或有少量用戶訪問您的應用程序時，這將起作用。隨著用戶的增長，此方法會導致資源沖突、內(nèi)存和 CPU 利用率問題以及對服務行為的監(jiān)控不足等問題。

每個主機的服務實例： 在每個主機上部署一個服務。這通過一種有效的方法來平衡負載，例如當特定服務的負載很高時，這克服了每個實例多個服務的問題。在這種情況下，您可以將部署擴展到單個服務的多個實例。這種模式也有一個缺點;假設您有一個不經(jīng)常使用的服務，即訂單爭議，但這將部署在一個實例上，您不能將這里的 CPU 和內(nèi)存資源用于另一個服務

無服務器部署： 使用可刪除服務器和基礎結(jié)構(gòu)管理的部署服務。它允許您壓縮包，將其部署到應用程序服務上，并根據(jù)請求向您收費。在此方法中，您無需擔心資源管理和負載管理。將服務設計為在沒有服務器的情況下運行，使用公共資源（如用于文件存儲的 S3 或 Azure 存儲）、將 Dynamodb 或 Azure 數(shù)據(jù)庫作為數(shù)據(jù)庫、SNS 或事件網(wǎng)格用于在兩個服務之間進行通信，SES 作為電子郵件服務。流行的框架組件包括AWS lambda，Google Cloud function，Azure函數(shù)

CICD期間要考慮的事項：

在定義部署微服務體系結(jié)構(gòu)時，最好檢查以下事項。

開發(fā)中使用的語言、框架和框架版本

每個服務都在工作，并且可以單獨部署和擴展（例如，部署4個服務進行設備管理）

每個服務都與另一個服務隔離

為每個服務添加 CPU 和內(nèi)存約束

監(jiān)視每個服務

檢查部署成本

9. 微服務部署平臺

您還可以使用部署平臺為無服務器和基于服務器的模型自動部署微服務。

如果你有一個龐大的系統(tǒng)，有多個集成服務，可以自我管理服務器實例和服務，這通常是一個經(jīng)濟高效的解決方案。您可以將 AWS 云形成和任務定義與 Docker swarm 模式和 Kubernetes 結(jié)合使用，以集中部署、擴展和管理所有應用程序。AWS 云形成允許您使用單個文件對基礎設施進行建模和預置，任務定義允許您為您的環(huán)境定義多個 Docker 映像。一旦環(huán)境啟動，任務定義將負責所有服務，即如果您的服務崩潰，它將自動啟動新的 Docker 實例。

如果您的解決方案很小，但需要服務，那么您可以將服務部署到 AWS Elastic Beanstalk 等 PaaS 平臺，它允許您在熟悉的服務器（如 Apache、Nginx、Passenger 和 IIS）上部署和擴展使用 Java、.NET、PHP、Node.js、Python、Ruby、Go 和 Docker 開發(fā)的 Web 應用程序和服務。它根據(jù)您使用的資源收費。

要部署無服務器代碼，您可以使用多種工具，如 claudia.js它允許您自動執(zhí)行 AWS lambda 和 API 網(wǎng)關(guān)部署。

實現(xiàn)示例：

假設我們正在使用微服務架構(gòu)構(gòu)建物聯(lián)網(wǎng)解決方案，該架構(gòu)包括設備連接、用戶管理、警報和規(guī)則引擎。除此之外，該解決方案還必須向第三方應用程序（如 Android 和 iOS）公開 REST API 詳細信息。

由于我們的解決方案使用微服務架構(gòu)，因此它將解決方案劃分為多個服務，例如：

API 網(wǎng)關(guān)（例如，提供安全網(wǎng)關(guān)（使用 API 密鑰）的快速網(wǎng)關(guān)，包括速率限制等多項功能，將請求路由到微服務）

面向 API 微服務的快速服務

用于服務間通信的塞內(nèi)卡微服務工具

MongoDB集群作為數(shù)據(jù)庫。

Redis for Service Registry & Event Store

Docker、Jenkins 和 Cloud formation 用于部署

審核編輯：郭婷