作者：Chandani Patel，Nupur Patel

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

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

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

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

應(yīng)該如何定義微服務(wù)架構(gòu)？

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

1. 將應(yīng)用程序分解為服務(wù)

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

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

分解策略：

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

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

分解時要考慮的事項：

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

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

該服務(wù)應(yīng)該具有很少的操作/功能和簡單的消息格式

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

每個服務(wù)都必須可單獨測試和部署

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

每個服務(wù)都應(yīng)該足夠小，以便可以由 6 名成員組成的小團(tuán)隊開發(fā)

應(yīng)用程序必須易于理解和修改

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

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

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

3. 微服務(wù)通信

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

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

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

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

4. 微服務(wù)觀察

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. 微服務(wù)測試

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

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

在單元/集成測試中模擬其他微服務(wù)：模擬外部服務(wù)并運行單元測試和集成測試。這種方法非常快，但不能保證生產(chǎn)安全

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

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

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

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

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

CICD戰(zhàn)略：

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

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

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

CICD期間要考慮的事項：

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

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

每個服務(wù)都在工作，并且可以單獨部署和擴展（例如，部署4個服務(wù)進(jìn)行設(shè)備管理）

每個服務(wù)都與另一個服務(wù)隔離

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

監(jiān)視每個服務(wù)

檢查部署成本

9. 微服務(wù)部署平臺

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

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

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

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

實現(xiàn)示例：

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

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

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

面向 API 微服務(wù)的快速服務(wù)

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

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

Redis for Service Registry & Event Store

Docker、Jenkins 和 Cloud formation 用于部署

審核編輯：郭婷