開發(fā)微服務的9個最佳實踐

來源：medium.com/

1 采用單一職責原則

2 建立職責明確的團隊

3 使用正確的工具和框架

4 保持微服務之間的異步通信

5 采用 DevSecOps 模型并保護微服務

6 為每個微服務使用單獨的數(shù)據(jù)存儲

7 單獨部署每個微服務

8 編排微服務

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

結論

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

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

如果我們談論其基本特征，則特定的微服務本身充當應用程序，與其他微服務形成更大的應用程序，這使得：

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

可維護性

可擴展性

從本質上講，這使您可以更有效地管理和維護應用程序。然而，這種模式固有的特定復雜性可以通過使用某些最佳實踐來減輕。

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

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

1 采用單一職責原則

單一職責原則是 OOP 中的任何單個對象都應該針對一個特定功能而創(chuàng)建的概念。基本上，它是羅伯特·馬丁提出的編程原則的一部分。就像代碼一樣，一個類應該只有一個需要更改的理由，從而使軟件更易于維護、可擴展且更易于理解。

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

“將那些因相同原因而變化的事物聚集在一起，并將那些因不同原因而變化的事物分開?！薄獖W萊利

我們可以說，這是構建良好架構設計的最好、最基本的原則之一，因為它意味著微服務、模塊、類、子系統(tǒng)或功能不應該有多個原因進行更改。

讓我們通過一個例子來理解這個原理：

電子商務門戶可能具有如下微服務架構

在這里，所有服務（例如產品列表服務、訂單服務、客戶服務、支付服務、購物車服務、愿望清單服務等）都有單一職責。這意味著確保在并非絕對必要的情況下不將一項服務與另一項服務集成非常重要，因為這會使架構的維護和測試變得更加復雜。

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

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

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

2 建立職責明確的團隊

開發(fā)微服務架構，需要建立職責明確的團隊。這可以通過多種方式完成，例如基于角色的團隊、跨職能團隊等。在此架構中，每個微服務都作為獨立的應用程序運行。

讓我們通過一個例子來理解這一點：

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

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

那么解決辦法是什么呢？

建立職責明確的跨職能團隊，幫助協(xié)調團隊之間的工作

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

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

項目地址：https://github.com/YunaiV/yudao-cloud

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

3 使用正確的工具和框架

至此，您可能已經設計了微服務來獨立部署它們，現(xiàn)在您必須實現(xiàn)這些微服務的最佳價值。為此，您需要使用一組良好的 DevOps 工具來自動化構建和部署管理。

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

Jenkins 和 Bamboo 用于部署自動化

Docker 用于容器化

用于 API 測試的 Postman

用于容器編排和部署的 Kubernetes

Logstash 用于監(jiān)控

DevSecOps 管理軟件開發(fā)生命周期的整個過程

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

Amazon 的簡單消息隊列服務

SonarQube 檢查代碼質量和安全性

Ansible 用于管理您的配置

Jira 用于問題跟蹤和項目管理

4 保持微服務之間的異步通信

微服務之間發(fā)生兩種類型的通信：同步和異步。讓我們通過一個例子來理解這一點：

對于電子商務平臺來說，同步通信意味著用戶將被要求“保持在線”并完成一系列步驟（選擇商品、添加送貨地址、付款詳細信息、訂單驗證），最終導致客戶通知“謝謝”您的訂單！我們將于下周交付”。

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

在同步通信的情況下，一個服務變得依賴于另一服務。有時，使用多個微服務之間的同步通信來完成整個任務會變得非常耗時。

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

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

5 采用 DevSecOps 模型并保護微服務

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

應用代碼（核心邏輯）

應用服務代碼（網絡連接、會話建立等）

基礎設施（數(shù)據(jù)存儲資源、網絡、平臺等）

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

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

高安全保證

減少代碼漏洞

提高產品質量

提高生產力

提高操作速度

更快地交付更好、更高質量的軟件

6 為每個微服務使用單獨的數(shù)據(jù)存儲

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

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

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

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

7 單獨部署每個微服務

如果您單獨部署每個微服務，那么在維護或升級工作的同時，您肯定會節(jié)省大量與多個團隊協(xié)調的時間。此外，如果一個或多個微服務具有相同的資源，我們建議您使用專用基礎設施來隔離每個微服務的故障并避免全面中斷。

部署微服務的一些最常見和流行的模式是：

每個主機多個服務實例

每個容器的服務實例

每個主機單個服務實例

每個虛擬機的服務實例

8 編排微服務

微服務的編排是在流程和工具方面取得成功的最有影響力的因素之一。您可以使用 Docker 在虛擬機上運行容器，但它無法提供與容器編排平臺相同級別的彈性。在嘗試采用微服務架構時，這樣的決定很可能會對您的正常運行時間產生負面影響。

以下是一些經過驗證的編排平臺：

K8（Kubernetes）

AKS（Azure Kubernetes 服務）

ECS（亞馬遜彈性容器服務）

Azure 容器應用程序

這些平臺有助于管理容器配置和部署、負載平衡、擴展、網絡通信問題等。

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

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

讓我們分析一個示例情況，假設您應用了微服務架構模式，該模式不具備處理請求的能力，但它們仍在運行。例如，如果數(shù)據(jù)庫連接耗盡，監(jiān)控系統(tǒng)應該能夠在實例發(fā)生故障時生成警報，并且請求應路由到工作服務實例。

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

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

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

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

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

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

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

結論

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