大家好，我是不才陳某~

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

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

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

• 更輕松、更快速的開發(fā)
• 可維護(hù)性
• 可擴(kuò)展性

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

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

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

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

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

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

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

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

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

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

圖片

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

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

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

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

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

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

那么解決辦法是什么呢？

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

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

3. 使用正確的工具和框架

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

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

• Jenkins 和 Bamboo 用于部署自動化
• Docker 用于容器化
• 用于 API 測試的 Postman
• 用于容器編排和部署的 Kubernetes
• Logstash 用于監(jiān)控
• DevSecOps 管理軟件開發(fā)生命周期的整個過程
• GitHub 用于源代碼管理和版本控制
• Amazon 的簡單消息隊列服務(wù)
• SonarQube 檢查代碼質(zhì)量和安全性
• Ansible 用于管理您的配置
• Jira 用于問題跟蹤和項目管理

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

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

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

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

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

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

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

圖片

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

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

• 應(yīng)用代碼（核心邏輯）
• 應(yīng)用服務(wù)代碼（網(wǎng)絡(luò)連接、會話建立等）
• 基礎(chǔ)設(shè)施（數(shù)據(jù)存儲資源、網(wǎng)絡(luò)、平臺等）
• 監(jiān)控（應(yīng)用程序的持續(xù)可觀察性）

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

• 高安全保證
• 減少代碼漏洞
• 提高產(chǎn)品質(zhì)量
• 提高生產(chǎn)力
• 提高操作速度
• 更快地交付更好、更高質(zhì)量的軟件

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

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

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

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

圖片

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

7. 單獨部署每個微服務(wù)

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

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

• 每個主機(jī)多個服務(wù)實例
• 每個容器的服務(wù)實例
• 每個主機(jī)單個服務(wù)實例
• 每個虛擬機(jī)的服務(wù)實例

8. 編排微服務(wù)

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

以下是一些經(jīng)過驗證的編排平臺：

• K8（Kubernetes）
• AKS（Azure Kubernetes 服務(wù)）
• ECS（亞馬遜彈性容器服務(wù)）
• Azure 容器應(yīng)用程序

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

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

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

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

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

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

• AWS CloudWatch： 一種監(jiān)控、可觀察性和管理服務(wù)，可收集和可視化實時日志，并為 AWS、混合和本地應(yīng)用程序及基礎(chǔ)設(shè)施資源提供可操作的見解。
• Jaeger： 旨在監(jiān)控和解決微服務(wù)環(huán)境中的復(fù)雜問題的軟件。
• Datagod： 一個適用于云規(guī)模應(yīng)用程序的可觀察性、安全性和分析平臺，使用基于 SaaS 的數(shù)據(jù)分析平臺為數(shù)據(jù)庫、服務(wù)和工具提供全面的解決方案。
• Graphite： 顧名思義，它是一種開源軟件，可以監(jiān)控數(shù)字時間序列數(shù)據(jù)并繪制圖表，并提供對底層系統(tǒng)的深入洞察。
• Prometheus： 一個免費(fèi)的開源軟件工具，提供監(jiān)控和修改解決方案。

結(jié)論

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