企業正在迅速採用微服務架構來建立靈活，可擴充套件的應用程式，這些應用程式可以快速迭代，具有較高的容錯能力和較低的停機時間。您如何構建正確的微服務架構？

儘管確切的架構會有所不同，但是有一些最佳實踐可以幫助設計有效和最佳的微服務架構。

領域驅動設計

微服務的重點是將統一架構分解為更小，更易管理的部分。必須以對所有利益相關者都有意義的方式來完成這種分解。

定義單個微服務範圍的幾種常用方法：

• 建立與應用程式開發過程中存在的不同運營團隊相對應的微服務。例如，一個團隊可能正在研究使用者身份驗證，另一個團隊正在研究資料收集，並且每個團隊都應負責建立一組實現特定任務的微服務。
• 建立與特定功能相對應的微服務。例如，分析應用程式可以具有聊天機器人功能，可視儀表板，資料分析功能等。這些中的每一個都可以建立為單獨的片段，並通過API進行交流。

這個想法是建立一組獨立的服務，以提供集中的增值服務。面臨的挑戰是避免將過多的功能過度填充到一個微服務中。通常建議將程式碼保持足夠簡單，以便在需要時可以輕鬆地重新部署。

獨立微服務

微服務的獨立性是其有效性的關鍵。它們鬆散耦合並且可以在沒有複雜的相互依賴性的情況下工作，這一事實確保了整個應用程式不會由於單點故障而崩潰。因此，在一些關鍵領域中必須確保獨立性：

• 獨立團隊：理想情況下，每個微服務都應擁有自己的專門團隊，其中包括產品經理和DevOps團隊。一支團隊將每項服務從開發到部署的過程，都有助於減少釋出頻率和最大程度地延長正常執行時間。
• 自動進行獨立部署：自動化構建和釋出週期，並確保每個微服務都可以獨立於其他微服務進行部署，這對於設計良好的應用程式至關重要。這樣，它們可以在任何環境下啟動並執行。
• 單獨的儲存：每個微服務都應擁有自己的特定資料庫，而其他所有需要該資料的服務都應僅通過API進行訪問。在短期內，共享資料庫似乎是一個方便的選擇。但是隨著微服務的擴充套件，這種共享導致它們相互耦合，從而破壞了目標。
• 隔離故障：為了確保即使一項服務出現故障，應用程式也可以繼續執行，微服務架構需要隔離故障。一種常用的方法是在應用程式中建立斷路器。當服務失敗超過設定次數後，斷路器將跳閘，並立即使給定時間段內對該服務的所有請求失敗。該服務提供的功能在該時間段內仍然不可用，即使應用程式的其餘部分保持正常工作也是如此。超時後，斷路器允許通過幾個請求，如果成功，則恢復為正常操作。

與此類似，其他設計模式（例如非同步通訊和事件驅動的體系結構）也可以用於故障隔離。

不變的基礎設施

不變的基礎架構將服務分為資料和“其他”，並且在每個版本中都將“其他”部分替換。建立新版本的微服務，而不是立即更新當前版本。新版本經過測試和微調，而舊版本是應用程式正在使用的版本。僅當新版本穩定時，才可以將其與前一個版本合併。

標準制定​​​​​​​

隨著組織更多地依賴微服務架構，不同的團隊從事不同的服務，流程和實踐可能會因團隊而異。每個團隊可以開始進行不同的開發，部署和錯誤處理。這可能導致不同團隊重複執行許多程式碼，從而影響效率和週轉時間。

因此，建議建立團隊可以遵守的組織範圍的標準。微服務建立和部署的過程以及它們相應的API應該有充分的文件記錄。這也使不同的團隊可以瞭解正在使用的其他微服務API，以及如何最好地使用它們。​​​​​​​