微服務(wù)是一種軟件架構(gòu)策略，有利于改善整體性能和可擴展性。你可能會想，我的團隊需不需要采用微服務(wù)，設(shè)計微服務(wù)架構(gòu)有哪些原則？本文會給你一些靈感。

文章速覽：

微服務(wù)設(shè)計的要素

微服務(wù)架構(gòu)設(shè)計的5個原則

微服務(wù)是一種軟件架構(gòu)策略，將應(yīng)用程序分解為一組解耦的、自治的服務(wù)。這些獨立的應(yīng)用服務(wù)通過API相互通信。每個服務(wù)都由其專業(yè)領(lǐng)域的專家團隊管理，以便每個軟件開發(fā)團隊可以控制自己的開發(fā)周期，按照自己的時間表進行測試和部署，使用自己的企業(yè)工具和資源，加速上線時間。為了評估你的團隊是否需要采用微服務(wù)架構(gòu)。這里有一些值得深入討論的細節(jié)。

一、微服務(wù)設(shè)計的要素

設(shè)計微服務(wù)架構(gòu)的第一步是形勢評估。開發(fā)者網(wǎng)站總結(jié)的十大微服務(wù)設(shè)計原則之一是單一責(zé)任原則，即每個服務(wù)只需要將其所有資源投入到微服務(wù)應(yīng)用程序的一個功能中。

1.通過領(lǐng)域驅(qū)動設(shè)計實施微服務(wù)

軟件架構(gòu)師需要進行領(lǐng)域分析，以確定如何劃分每個服務(wù)以及需要將哪些元素納入應(yīng)用堆棧中。這種領(lǐng)域分析被稱為領(lǐng)域驅(qū)動設(shè)計（Domain Driven Design, DDD）。它將實體模式和聚合模式等模式應(yīng)用到單個限界上下文（bounded context）中，以便以更高的計算精度來識別單個域的邊界。

總之，應(yīng)該圍繞特定的業(yè)務(wù)功能構(gòu)建每個微服務(wù)。一旦確定了領(lǐng)域并了解了它們的邊界，就可以定義最適合應(yīng)用堆棧的變量了。

2.選擇技術(shù)棧

創(chuàng)建微服務(wù)技術(shù)棧較為特別。通常你需要使用各種工具、框架和編程語言，將它們整合成一個耦合的系統(tǒng)。在選擇工具時考慮以下變量：

編程語言

選擇用于微服務(wù)的最佳編程語言，取決于你最熟悉哪種語言、可用于所需功能的庫以及每種語言提供的功能套件。顯然，選擇你的開發(fā)團隊已經(jīng)大范圍使用的語言可以節(jié)省時間和精力。

根據(jù)2021年JetBrains關(guān)于微服務(wù)的調(diào)查，“用于微服務(wù)開發(fā)的三種最流行的語言是Java（41%）、JavaScript（37%）和Python（25%）”。這些流行的編程語言都有大量的在線開發(fā)者支持、成功應(yīng)用開發(fā)的示例、運行環(huán)境，比如Node.JS，以及豐富的客戶端庫。

總之，確保所選的語言適合當(dāng)前業(yè)務(wù)問題。例如，Python在數(shù)據(jù)分析中很受歡迎，而JavaScript是全棧開發(fā)的最優(yōu)選擇。

數(shù)據(jù)庫

在為微服務(wù)架構(gòu)構(gòu)建的應(yīng)用程序選擇適合的數(shù)據(jù)庫時，應(yīng)將可伸縮性、可用性和安全性置于首要位置。選擇一個最能支持你在微服務(wù)中計劃使用的數(shù)據(jù)模型的數(shù)據(jù)庫。你的技術(shù)棧應(yīng)該能夠處理任何應(yīng)用負載，確保使用故障切換協(xié)議可用性，并保護應(yīng)用免受惡意攻擊。

通信

你的業(yè)務(wù)功能可能需要您的微服務(wù)使用同步的服務(wù)間通信方法執(zhí)行某些操作，對于其他操作，可能需要使用異步通信。可以使用多種通信格式和協(xié)議來輔助微服務(wù)通信，包括HTTP/REST、gRPC和AMQP。

對于異步通信，使用支持消費者組的事件驅(qū)動消息代理可以提高可伸縮性和可靠性，確保應(yīng)用程序能夠擴展，而不會導(dǎo)致任何服務(wù)無法訪問的情況。

監(jiān)控

每個微服務(wù)團隊都負責(zé)監(jiān)視應(yīng)用程序性能，通常使用日志記錄和可觀察性工具來跟蹤操作。這使得開發(fā)人員和運維人員可以跟蹤整個系統(tǒng)，如應(yīng)用程序性能、消息代理流與數(shù)據(jù)庫資源利用率。

在使用消息代理時，考慮使用一個日志流，其中每個微服務(wù)都可以發(fā)布消息。這樣，您可以將首選的日志記錄和可觀察性工具連接到流，并在不減慢應(yīng)用程序的情況下異步監(jiān)視您的應(yīng)用程序。

二、微服務(wù)架構(gòu)設(shè)計的5個原則

那么，如何確保你的微服務(wù)架構(gòu)可以發(fā)揮最佳作用？以下是五個微服務(wù)應(yīng)用程序設(shè)計原則，可供你參考。

1.低耦合和高內(nèi)聚

低耦合和高內(nèi)聚可以通過前面提到的單一責(zé)任原則來解釋。賦予每個領(lǐng)域團隊單一的職責(zé)，有助于加強該領(lǐng)域內(nèi)的內(nèi)聚，使得該服務(wù)內(nèi)的所有功能都在某種程度上緊密耦合。每個服務(wù)都由其自己的領(lǐng)域?qū)＜液凸ぞ吖芾?，但仍然可以通過API和其他協(xié)議相互通信。這有點像來自不同部門的同事如何互動：當(dāng)有助于完成工作時，大家彼此分享信息，而不會過多地談?wù)撆c他人無關(guān)的細節(jié)。

2.適應(yīng)性

業(yè)務(wù)應(yīng)用程序很少是靜止不變的。隨著新的業(yè)務(wù)需求的出現(xiàn)，行業(yè)的假設(shè)發(fā)生變化，技術(shù)能力提供更多功能，軟件也會發(fā)生變化。微服務(wù)應(yīng)該具有可適應(yīng)性，以滿足新需求出現(xiàn)時可以進行適應(yīng)。世界在變化，人們在變化，所以軟件也應(yīng)該變化。

3.基礎(chǔ)設(shè)施自動化

實現(xiàn)微服務(wù)的一個原因是它們能夠自動化流程，從而提高整體可擴展性。借助 Kubernetes 等容器編排系統(tǒng)，您可以使用單個鏡像與微服務(wù)一起部署微服務(wù)的整個數(shù)據(jù)庫。在Kubernetes控制器的幫助下，這些可移植性優(yōu)勢可以幫助DevOps團隊管理、調(diào)度和編排自動容器部署。

4.離散邊界

實施微服務(wù)要求在任何給定應(yīng)用程序中的服務(wù)都要維護自己的分散數(shù)據(jù)。服務(wù)邊界應(yīng)該將與任何單個服務(wù)相關(guān)的所有邏輯和數(shù)據(jù)與應(yīng)用程序中的其他服務(wù)隔離開。

這也是允許容器化微服務(wù)進行獨立部署的邏輯。這個原則也有一些反對者，他們認為這會導(dǎo)致數(shù)據(jù)冗余激增。但建立這些明確的邊界最大的好處之一是：當(dāng)一個微服務(wù)承載自己的數(shù)據(jù)時，任何奇怪的行為都被限制在微服務(wù)內(nèi)部。

5.為故障而設(shè)計

干擾是經(jīng)常發(fā)生的，應(yīng)用服務(wù)會在毫無征兆的情況下癱瘓。例如，挖掘機開挖光纜中斷網(wǎng)絡(luò)操作，人們會忘記續(xù)訂域名，系統(tǒng)會因防火墻故障引起的數(shù)據(jù)連接問題而中斷等。所以，需要盡力考慮潛在的故障的可實施對策。設(shè)計具有彈性的解決方案，比如使用斷路器模式，以防止當(dāng)某個微服務(wù)無法執(zhí)行給定操作時其他服務(wù)中斷。