開(kāi)發(fā)微服務(wù)的9個(gè)最佳實(shí)踐

來(lái)源：medium.com/

1 采用單一職責(zé)原則

2 建立職責(zé)明確的團(tuán)隊(duì)

3 使用正確的工具和框架

4 保持微服務(wù)之間的異步通信

5 采用 DevSecOps 模型并保護(hù)微服務(wù)

6 為每個(gè)微服務(wù)使用單獨(dú)的數(shù)據(jù)存儲(chǔ)

7 單獨(dú)部署每個(gè)微服務(wù)

8 編排微服務(wù)

9 使用有效的監(jiān)控系統(tǒng)

結(jié)論

微服務(wù)架構(gòu)是一種演進(jìn)的模式，從根本上改變了服務(wù)器端代碼的開(kāi)發(fā)和管理方式。這種架構(gòu)模式涉及將應(yīng)用程序設(shè)計(jì)和開(kāi)發(fā)為松散耦合服務(wù)的集合，這些服務(wù)通過(guò)定義良好的輕量級(jí) API 進(jìn)行交互以滿足業(yè)務(wù)需求。

它旨在通過(guò)促進(jìn)持續(xù)交付和開(kāi)發(fā)來(lái)幫助軟件開(kāi)發(fā)公司加速開(kāi)發(fā)過(guò)程，微服務(wù)架構(gòu)模式從根本上改變了服務(wù)器端代碼的開(kāi)發(fā)和管理方式。

如果我們談?wù)撈浠咎卣鳎瑒t特定的微服務(wù)本身充當(dāng)應(yīng)用程序，與其他微服務(wù)形成更大的應(yīng)用程序，這使得：

更輕松、更快速的開(kāi)發(fā)

可維護(hù)性

可擴(kuò)展性

從本質(zhì)上講，這使您可以更有效地管理和維護(hù)應(yīng)用程序。然而，這種模式固有的特定復(fù)雜性可以通過(guò)使用某些最佳實(shí)踐來(lái)減輕。

我們都知道微服務(wù)設(shè)計(jì)對(duì)現(xiàn)代架構(gòu)的網(wǎng)絡(luò)彈性有直接影響，當(dāng)企業(yè)決定使用微服務(wù)進(jìn)行構(gòu)建時(shí)，高效且有效地開(kāi)發(fā)它們非常重要，以便它們可以在網(wǎng)絡(luò)上運(yùn)行，而不會(huì)導(dǎo)致過(guò)多的延遲、帶寬消耗和數(shù)據(jù)包丟失。

在本文中，我們將討論如果您想實(shí)現(xiàn)一個(gè)沒(méi)有極端架構(gòu)復(fù)雜性的高效微服務(wù)生態(tài)系統(tǒng)，您應(yīng)該考慮的基本微服務(wù)最佳實(shí)踐。那么，事不宜遲，讓我們開(kāi)始吧。

1 采用單一職責(zé)原則

單一職責(zé)原則是 OOP 中的任何單個(gè)對(duì)象都應(yīng)該針對(duì)一個(gè)特定功能而創(chuàng)建的概念?；旧希橇_伯特·馬丁提出的編程原則的一部分。就像代碼一樣，一個(gè)類應(yīng)該只有一個(gè)需要更改的理由，從而使軟件更易于維護(hù)、可擴(kuò)展且更易于理解。

要在軟件開(kāi)發(fā)中采用SRP，您應(yīng)該確保每個(gè)類或模塊都有明確定義的職責(zé)，并且不會(huì)嘗試做太多事情。您還應(yīng)該保持模塊解耦，并使用清晰簡(jiǎn)潔的接口在它們之間進(jìn)行通信?？偨Y(jié)一下，我們有一個(gè)有趣的引述：

“將那些因相同原因而變化的事物聚集在一起，并將那些因不同原因而變化的事物分開(kāi)。”——奧萊利

我們可以說(shuō)，這是構(gòu)建良好架構(gòu)設(shè)計(jì)的最好、最基本的原則之一，因?yàn)樗馕吨⒎?wù)、模塊、類、子系統(tǒng)或功能不應(yīng)該有多個(gè)原因進(jìn)行更改。

讓我們通過(guò)一個(gè)例子來(lái)理解這個(gè)原理：

電子商務(wù)門戶可能具有如下微服務(wù)架構(gòu)

在這里，所有服務(wù)（例如產(chǎn)品列表服務(wù)、訂單服務(wù)、客戶服務(wù)、支付服務(wù)、購(gòu)物車服務(wù)、愿望清單服務(wù)等）都有單一職責(zé)。這意味著確保在并非絕對(duì)必要的情況下不將一項(xiàng)服務(wù)與另一項(xiàng)服務(wù)集成非常重要，因?yàn)檫@會(huì)使架構(gòu)的維護(hù)和測(cè)試變得更加復(fù)雜。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

2 建立職責(zé)明確的團(tuán)隊(duì)

開(kāi)發(fā)微服務(wù)架構(gòu)，需要建立職責(zé)明確的團(tuán)隊(duì)。這可以通過(guò)多種方式完成，例如基于角色的團(tuán)隊(duì)、跨職能團(tuán)隊(duì)等。在此架構(gòu)中，每個(gè)微服務(wù)都作為獨(dú)立的應(yīng)用程序運(yùn)行。

讓我們通過(guò)一個(gè)例子來(lái)理解這一點(diǎn)：

組織可以擁有基于角色的團(tuán)隊(duì)，例如 UI/UX 開(kāi)發(fā)人員、前端開(kāi)發(fā)人員、后端開(kāi)發(fā)人員、數(shù)據(jù)庫(kù)管理員、QA、中間件開(kāi)發(fā)人員等，他們獨(dú)立工作，但每天通過(guò)會(huì)議進(jìn)行互動(dòng)（無(wú)論是面對(duì)面的）或者使用各種通訊工具，如 JIRA、Slack 等。

當(dāng)我們考慮維護(hù)時(shí)，有時(shí)系統(tǒng)中也會(huì)出現(xiàn)小錯(cuò)誤，有時(shí)甚至是大錯(cuò)誤。因此，SCRUM 可能是一個(gè)可能的解決方案。它幫助每個(gè)團(tuán)隊(duì)成員縮短無(wú)意識(shí)的時(shí)間。但是，由于團(tuán)隊(duì)是根據(jù)角色組織的，因此在一個(gè)沖刺中集成一個(gè)更新可能會(huì)成為一項(xiàng)復(fù)雜的任務(wù)。例如，如果 UI/UX 開(kāi)發(fā)人員沒(méi)有從服務(wù)器人員那里獲得有關(guān) API 更改的任何信息，則新 API 將根本沒(méi)有用處。

那么解決辦法是什么呢？

建立職責(zé)明確的跨職能團(tuán)隊(duì)，幫助協(xié)調(diào)團(tuán)隊(duì)之間的工作

負(fù)責(zé)整個(gè)微服務(wù)功能的跨職能團(tuán)隊(duì)可能會(huì)給您的項(xiàng)目帶來(lái)重大好處。該團(tuán)隊(duì)?wèi)?yīng)由所有基于角色的團(tuán)隊(duì)的成員組成，并負(fù)責(zé)協(xié)調(diào)應(yīng)用程序的各個(gè)部分，即 UI、開(kāi)發(fā)、數(shù)據(jù)庫(kù)，甚至 QA。如果應(yīng)用程序有兩個(gè)版本，即網(wǎng)絡(luò)版本和移動(dòng)版本，那么兩個(gè)團(tuán)隊(duì)的開(kāi)發(fā)人員都應(yīng)該出現(xiàn)在該團(tuán)隊(duì)中。這種團(tuán)隊(duì)的主要好處是可以輕松解決錯(cuò)誤、開(kāi)發(fā)新功能并將其部署到生產(chǎn)環(huán)境中。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

3 使用正確的工具和框架

至此，您可能已經(jīng)設(shè)計(jì)了微服務(wù)來(lái)獨(dú)立部署它們，現(xiàn)在您必須實(shí)現(xiàn)這些微服務(wù)的最佳價(jià)值。為此，您需要使用一組良好的 DevOps 工具來(lái)自動(dòng)化構(gòu)建和部署管理。

使用正確的工具、框架和庫(kù)將對(duì)實(shí)現(xiàn)微服務(wù)架構(gòu)大有幫助。如果您計(jì)劃在 Java 中執(zhí)行此操作，請(qǐng)考慮Spring Boot 項(xiàng)目。選擇正確的工具和框架需要花費(fèi)大量的時(shí)間和精力，因此這里列出了適合該工作的“首選”、經(jīng)過(guò)驗(yàn)證的工具和技術(shù)：

Jenkins 和 Bamboo 用于部署自動(dòng)化

Docker 用于容器化

用于 API 測(cè)試的 Postman

用于容器編排和部署的 Kubernetes

Logstash 用于監(jiān)控

DevSecOps 管理軟件開(kāi)發(fā)生命周期的整個(gè)過(guò)程

GitHub 用于源代碼管理和版本控制

Amazon 的簡(jiǎn)單消息隊(duì)列服務(wù)

SonarQube 檢查代碼質(zhì)量和安全性

Ansible 用于管理您的配置

Jira 用于問(wèn)題跟蹤和項(xiàng)目管理

4 保持微服務(wù)之間的異步通信

微服務(wù)之間發(fā)生兩種類型的通信：同步和異步。讓我們通過(guò)一個(gè)例子來(lái)理解這一點(diǎn)：

對(duì)于電子商務(wù)平臺(tái)來(lái)說(shuō)，同步通信意味著用戶將被要求“保持在線”并完成一系列步驟（選擇商品、添加送貨地址、付款詳細(xì)信息、訂單驗(yàn)證），最終導(dǎo)致客戶通知“謝謝”您的訂單！我們將于下周交付”。

一旦處理客戶通知，也會(huì)發(fā)生一些異步通信，這些異步通信是訂單“履行”階段的一部分，例如：倉(cāng)庫(kù)通知、庫(kù)存更新等。

在同步通信的情況下，一個(gè)服務(wù)變得依賴于另一服務(wù)。有時(shí)，使用多個(gè)微服務(wù)之間的同步通信來(lái)完成整個(gè)任務(wù)會(huì)變得非常耗時(shí)。

另一方面，異步通信彼此不依賴，每個(gè)服務(wù)都可以花一些時(shí)間來(lái)完成其任務(wù)。因此，人們應(yīng)該盡可能地最大化微服務(wù)之間的異步通信，它減少了依賴性并提高了應(yīng)用程序的整體效率。

您可以在下面看到這樣的示例：

5 采用 DevSecOps 模型并保護(hù)微服務(wù)

安全性在此架構(gòu)中非常重要。隨著微服務(wù)架構(gòu)在云原生應(yīng)用程序開(kāi)發(fā)中的發(fā)展，DevSecOps 實(shí)踐越來(lái)越多地用于通過(guò)增強(qiáng)的安全措施來(lái)確保持續(xù)集成和持續(xù)交付。使用微服務(wù)構(gòu)建的應(yīng)用程序可以分為以下代碼類型：

應(yīng)用代碼（核心邏輯）

應(yīng)用服務(wù)代碼（網(wǎng)絡(luò)連接、會(huì)話建立等）

基礎(chǔ)設(shè)施（數(shù)據(jù)存儲(chǔ)資源、網(wǎng)絡(luò)、平臺(tái)等）

監(jiān)控（應(yīng)用程序的持續(xù)可觀察性）

DevSecOps 包含三個(gè)概念：開(kāi)發(fā)、安全和操作，并已被證明是具有持續(xù)集成、持續(xù)交付和持續(xù)部署管道等原語(yǔ)的代碼類型的促進(jìn)范例。這些管道是使用開(kāi)發(fā)人員的源代碼進(jìn)行開(kāi)發(fā)、測(cè)試、部署以及許多此類操作的工作流程，這些操作由具有反饋機(jī)制的自動(dòng)化工具支持。此外，它還使開(kāi)發(fā)團(tuán)隊(duì)能夠更快地交付更好、更安全的代碼。微服務(wù)架構(gòu)中的 DevSecOps 實(shí)踐提供了許多好處，例如：

高安全保證

減少代碼漏洞

提高產(chǎn)品質(zhì)量

提高生產(chǎn)力

提高操作速度

更快地交付更好、更高質(zhì)量的軟件

6 為每個(gè)微服務(wù)使用單獨(dú)的數(shù)據(jù)存儲(chǔ)

一項(xiàng)重要的實(shí)踐是確保盡可能使用單獨(dú)的數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)數(shù)據(jù)，而不是為多個(gè)微服務(wù)使用相同的數(shù)據(jù)庫(kù)。然而，更深入的分析可能表明一個(gè)微服務(wù)僅適用于數(shù)據(jù)庫(kù)表的子集，而另一方面，另一個(gè)微服務(wù)僅適用于全新的表子集。如果兩個(gè)數(shù)據(jù)子集都是正交的，則需要將數(shù)據(jù)庫(kù)分成單獨(dú)的服務(wù)。

因此，請(qǐng)確保為您的微服務(wù)擁有單獨(dú)的數(shù)據(jù)存儲(chǔ)，以減少延遲并提高安全性。這已經(jīng)被提到很多次了，但需要強(qiáng)調(diào)的是，微服務(wù)之間應(yīng)該盡可能少地依賴。

微服務(wù)架構(gòu)的主要屬性之一是每個(gè)服務(wù)的數(shù)據(jù)都是私有的，例如，每個(gè)服務(wù)數(shù)據(jù)庫(kù)模式就是如此。

我們還可以使用共享數(shù)據(jù)庫(kù)服務(wù)器，該服務(wù)器可供多個(gè)服務(wù)使用，并對(duì)其數(shù)據(jù)進(jìn)行邏輯分離。

7 單獨(dú)部署每個(gè)微服務(wù)

如果您單獨(dú)部署每個(gè)微服務(wù)，那么在維護(hù)或升級(jí)工作的同時(shí)，您肯定會(huì)節(jié)省大量與多個(gè)團(tuán)隊(duì)協(xié)調(diào)的時(shí)間。此外，如果一個(gè)或多個(gè)微服務(wù)具有相同的資源，我們建議您使用專用基礎(chǔ)設(shè)施來(lái)隔離每個(gè)微服務(wù)的故障并避免全面中斷。

部署微服務(wù)的一些最常見(jiàn)和流行的模式是：

每個(gè)主機(jī)多個(gè)服務(wù)實(shí)例

每個(gè)容器的服務(wù)實(shí)例

每個(gè)主機(jī)單個(gè)服務(wù)實(shí)例

每個(gè)虛擬機(jī)的服務(wù)實(shí)例

8 編排微服務(wù)

微服務(wù)的編排是在流程和工具方面取得成功的最有影響力的因素之一。您可以使用 Docker 在虛擬機(jī)上運(yùn)行容器，但它無(wú)法提供與容器編排平臺(tái)相同級(jí)別的彈性。在嘗試采用微服務(wù)架構(gòu)時(shí)，這樣的決定很可能會(huì)對(duì)您的正常運(yùn)行時(shí)間產(chǎn)生負(fù)面影響。

以下是一些經(jīng)過(guò)驗(yàn)證的編排平臺(tái)：

K8（Kubernetes）

AKS（Azure Kubernetes 服務(wù)）

ECS（亞馬遜彈性容器服務(wù)）

Azure 容器應(yīng)用程序

這些平臺(tái)有助于管理容器配置和部署、負(fù)載平衡、擴(kuò)展、網(wǎng)絡(luò)通信問(wèn)題等。

9 使用有效的監(jiān)控系統(tǒng)

微服務(wù)架構(gòu)可幫助您對(duì)數(shù)千個(gè)模塊化服務(wù)進(jìn)行巨大擴(kuò)展，并提供提高速度和有組織的監(jiān)控方法的潛力。然而，重要的是要確保檢查所有微服務(wù)并定期檢查它們是否按預(yù)期運(yùn)行以及是否有效地使用可用資源。根據(jù)這些觀察結(jié)果，如果未達(dá)到預(yù)期，您可以采取適當(dāng)?shù)拇胧?/p>

讓我們分析一個(gè)示例情況，假設(shè)您應(yīng)用了微服務(wù)架構(gòu)模式，該模式不具備處理請(qǐng)求的能力，但它們?nèi)栽谶\(yùn)行。例如，如果數(shù)據(jù)庫(kù)連接耗盡，監(jiān)控系統(tǒng)應(yīng)該能夠在實(shí)例發(fā)生故障時(shí)生成警報(bào)，并且請(qǐng)求應(yīng)路由到工作服務(wù)實(shí)例。

監(jiān)控微服務(wù)并準(zhǔn)確解釋這些統(tǒng)計(jì)數(shù)據(jù)將幫助您改進(jìn)決策并在需要時(shí)保持微服務(wù)可用。

讓我們看一下微服務(wù)監(jiān)控工具的幾個(gè)示例。

AWS CloudWatch：一種監(jiān)控、可觀察性和管理服務(wù)，可收集和可視化實(shí)時(shí)日志，并為 AWS、混合和本地應(yīng)用程序及基礎(chǔ)設(shè)施資源提供可操作的見(jiàn)解。

Jaeger：旨在監(jiān)控和解決微服務(wù)環(huán)境中的復(fù)雜問(wèn)題的軟件。

Datagod：一個(gè)適用于云規(guī)模應(yīng)用程序的可觀察性、安全性和分析平臺(tái)，使用基于 SaaS 的數(shù)據(jù)分析平臺(tái)為數(shù)據(jù)庫(kù)、服務(wù)和工具提供全面的解決方案。

Graphite：顧名思義，它是一種開(kāi)源軟件，可以監(jiān)控?cái)?shù)字時(shí)間序列數(shù)據(jù)并繪制圖表，并提供對(duì)底層系統(tǒng)的深入洞察。

Prometheus：一個(gè)免費(fèi)的開(kāi)源軟件工具，提供監(jiān)控和修改解決方案。

結(jié)論

這就是這篇文章的內(nèi)容。我希望您覺(jué)得這篇文章很有用，并且您將遵循這些微服務(wù)的最佳實(shí)踐，最終得到一個(gè)獨(dú)立的、松散耦合的系統(tǒng)，以便獲得該架構(gòu)的好處。