微服務是一種軟體架構策略，將應用程式分解為一組解耦的、自治的服務。採用微服務架構將改善整體性能和可擴展性，本文將概述微服務設計和實施的基本考慮因素。 ...
微服務是一種軟體架構策略，有利於改善整體性能和可擴展性。你可能會想，我的團隊需不需要採用微服務，設計微服務架構有哪些原則？本文會給你一些靈感。
文章速覽：
- 微服務設計
- 通過領域驅動設計實施微服務
- 選擇技術棧
- 微服務設計架構的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.為故障而設計
干擾是經常發生的，應用服務會在毫無徵兆的情況下癱瘓。例如，挖掘機開挖光纜中斷網路操作，人們會忘記續訂功能變數名稱，系統會因防火牆故障引起的數據連接問題而中斷等。所以，需要儘力考慮潛在的故障的可實施對策。設計具有彈性的解決方案，比如使用斷路器模式，以防止當某個微服務無法執行給定操作時其他服務中斷。
