微服務是一種軟體架構策略，有利於改善整體效能和可擴充套件性。你可能會想， 我的團隊需不需要採用微服務，設計微服務架構有哪些原則？本文會給你一些靈感。

文章速覽：

• 微服務設計

• 透過領域驅動設計實施微服務

• 選擇技術棧

• 微服務設計架構的 5個原則

 

微服務是一種軟體架構策略，將應用程式分解為一組解耦的、自治的服務。 這些獨立的應用服務透過API 相互通訊。每個服務都由其專業領域的專家團隊管理，以便每個軟體開發團隊可以控制自己的開發週期，按照自己的時間表進行測試和部署，使用自己的企業工具和資源，加速 上線 時間。為了評估 你的團隊是否需要 採用微服務架構。這裡 有一些 值得深入討論的細節。

一、 微服務設計

設計微服務架構的第一步是形勢評估。 開發者網站 （ Developer.com ） 總結的十大微服務設計原則之一是 單一責任原則 ， 即 每個服務 只需要 將其所有資源投入到微服務應用程式的一個功能中。

1. 透過領域驅動設計實施微服務

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

總之 ，應該圍繞特定的業務功能構建每個微服務 。一旦確定了 領 域並 瞭解 了它們的邊界，就可以定義最適合應用堆疊的變數 了 。

2. 選擇技術棧

建立微服務技術棧 較為特別 。通常 你 需要使用各種工具、框架和程式語言，將它們整合成一個耦合的系統。 在選擇工具時考慮以下變數：

1)   程式語言

選擇用於微服務的程式語言 ， 取決於 你最熟悉哪種語言、 可用於所需功能的庫以及每種語言提供的功能套件。 顯然，選擇 你的 開發團隊 已經大範圍 使用的語言可以節省時間和精力。

根據2021 年JetBrains 關於微服務的調查，“ 用於微服務開發的三種流行的語言是Java （41% ）、JavaScript （37% ）和Python （25% ）” 。這些流行的程式語言都有大量的線上開發者支援、成功應用開發的示例、執行環境，比如Node.JS ，以及豐富的客戶端庫。

總之， 確保所選的語言適合當前業務問題 。 例如，Python 在資料分析中很受歡迎，而 JavaScript 是全棧開發的 最優 選擇。

2) 資料庫

在為微服務架構構建的應用程式選擇適合的資料庫時，應將可伸縮性、可用性和安全性置於首要位置。 選擇一個最能支援 你 在微服務中計劃使用的資料模型的資料庫。 你 的技術棧應該能夠處理任何應用負載，確保使用故障切換協議可用性，並保護應用免受惡意攻擊。

3) 通訊

你 的業務功能可能需要您的微服務使用同步的服務間通訊方法執行某些操作，對於其他操作，可能需要使用非同步通訊。 可以使用多種通訊格式和協議來輔助微服務通訊，包括HTTP/REST 、 gRPC 和 AMQP 。

對於非同步通訊，使用支援消費者組的事件驅動訊息代理可以提高可伸縮性和可靠性，確保應用程式能夠擴充套件，而不會導致任何服務無法訪問 的情況 。

4) 監控

每個微服務團隊都負責監視應用程式效能，通常使用日誌記錄和可觀察性工具來跟蹤操作。 這使得開發人員和運維人員可以跟蹤整個系統，如應用程式效能、訊息代理流與資料庫資源利用率。

在使用訊息代理時，考慮使用一個日誌流，其中每個微服務都可以釋出訊息。 這樣，您可以將日誌記錄和可觀察性工具連線到流，並在不減慢應用程式的情況下非同步監視您的應用程式。

二、微服務架構設計的 5 個原則

那麼，如何 確保 你 的微服務架構 可以 發揮作用？以下是五個微服務應用程式設計原則，可供 你 參考。

1. 低耦合和高內聚

低耦合和高內聚可以透過前面提到的單一責任原則來解釋 。 賦予每個領域團隊單一的職責，有助於加強該領域內的內聚，使得該服務內的所有功能都在某種程度上緊密耦合。每個服務都由其自己的領域專家和工具管理，但仍然可以透過API 和其他協議相互通訊。這有點像來自不同部門的同事如何互動：當有助於完成工作時，大家彼此分享資訊，而不會過多地談論與他人無關的細節。

2. 適應性

業務應用程式很少是靜止不變的。隨著新的業務需求的出現，行業的假設發生變化，技術能力提供更多功能，軟體也會發生變化。 微服務應該具有可適應性，以滿足新需求出現時可以進行適應。 世界在變化，人們在變化，所以軟體也應該變化。

3. 基礎設施自動化

實現微服務的一個原因是它們能夠自動化流程，從而提高整體可擴充套件性。藉助 Kubernetes 等容器編排系統，您可以使用單個映象與微服務一起部署微服務的整個資料庫。在 Kubernetes控制器的幫助下，這些可移植性優勢可以幫助 DevOps團隊管理、排程和編排自動容器部署。

4. 離散邊界

實施微服務要求在任何給定應用程式中的服務都要維護自己的分散資料。服務邊界應該將與任何單個服務相關的所有邏輯和資料與應用程式中的其他服務隔離開。

這也是允許容器化微服務進行獨立部署的邏輯。這個原則也有一些反對者，他們認為這會導致資料冗餘激增。但建立這些明確的邊界最大的好處之一是：當一個微服務承載自己的資料時，任何奇怪的行為都被限制在微服務內部。

5. 為故障而設計

干擾是經常發生的，應用服務會在毫無徵兆的情況下癱瘓。 例如，挖掘機開挖光纜 中斷網路操作 ， 人們會忘記續訂域名，系統會因防火牆故障引起的資料連線問題而中斷等。 所以，需要 盡力考慮潛在的故障 的可實施對策 。設計具有彈性的解決方案，比如使用斷路器模式，以防止當某個微服務無法執行給定操作時其他服務中斷。