微服務先備條件

當我與人討論使用 微服務架構風格 時，我聽到了許多樂觀的意見。開發人員喜歡使用較小的單元，並且期望比巨石架構有更好的模組化。但與任何架構決策一樣，都需要權衡取捨。特別是微服務對營運有嚴重的影響，因為營運現在必須處理小型服務的生態系統，而不是單一且定義良好的巨石架構。因此，如果您沒有某些基本能力，就不應該考慮使用微服務風格。

快速配置：您應該可以在幾個小時內啟動新的伺服器。這自然符合 雲端運算，但這也是可以在沒有完整雲端服務的情況下完成的事情。為了能夠進行如此快速的配置，您需要大量的自動化 - 它可能不必一開始就完全自動化，但要認真執行微服務，以後需要這樣做。

基本監控：由於許多鬆散耦合的服務在生產中協作，因此事情必定會以在測試環境中難以檢測的方式出錯。因此，監控機制對於快速檢測嚴重問題至關重要。此處的基準是檢測技術問題（計算錯誤、服務可用性等），但監控業務問題（例如檢測訂單下降）也是值得的。如果突然出現問題，則您需要確保可以快速回滾，因此…

快速應用程式部署：由於需要管理許多服務，因此您需要能夠快速部署它們，無論是在測試環境還是生產環境中。通常這將涉及一個 部署管線，其執行時間不超過幾個小時。在早期階段，一些手動介入是可以的，但您很快就會希望完全自動化它。

這些功能意味著重要的組織轉變 - 開發人員和營運之間的密切合作：DevOps 文化。這種合作對於確保可以快速進行配置和部署是必要的，當您的監控指示有問題時，確保您可以快速做出反應也很重要。特別是任何事件管理都需要開發團隊和營運參與，無論是在修復立即問題還是根本原因分析以確保修復潛在問題。

有了這種設置，您就可以準備好使用少數微服務的第一個系統。部署此系統並在生產中使用它，預計會學到很多關於如何保持其健康並確保 DevOps 協作順利進行的知識。給自己時間去做這件事，從中學習，並在增加服務數量之前培養更多能力。

如果您現在沒有這些能力，您應該確保您在將微服務系統投入生產時，已經準備好發展這些能力。事實上，這些也是您真正應該具備的單體系統能力。雖然它們並非普遍存在於軟體組織中，但幾乎沒有地方不將它們視為優先事項。

超越少數服務需要更多。您需要透過多項服務追蹤業務交易，並透過完全採用 持續交付 自動化您的配置和部署。還有轉向 以產品為中心的團隊，需要開始進行。您需要組織您的開發環境，讓開發人員可以輕鬆地在多個儲存庫、函式庫和語言之間切換。我的部分聯絡人認為，可能有一個有用的 成熟度模型，可以在組織採用更多微服務實作時提供協助 - 我們應該在未來幾年看到更多關於此的討論。