實施微服務架構前，你得想明白這幾件事

對於任何一家技術企業來說，敏捷性都是至關重要的。面對不斷變化的技術和行業環境，如果一家公司需要花很長時間才能對變革做出反應，那麼結果很可能是將市場份額拱手讓給更敏捷的公司。

而微服務將應用拆分成小業務單元進行開發和部署，使用輕量級協議通訊，通過協同工作實現應用邏輯的架構模式，給予了應用更高的敏捷性、可伸縮性和可用性，而這也正是公司在擴大和推出新業務時所急需的。

聽起來很有價值，事實上微服務架構也的確稱為了眾多前沿公司的可行選擇，但在實施之前，你得想明白這幾件事：

業務是否足夠大

你的業務是否足夠大，有必要讓開發團隊在複雜專案上分頭工作？如果沒有，你可能暫時並不需要微服務架構。就像Martin Fowler所說，微服務架構的生產力成本只適用於大型複雜的軟體專案。

是否需要獨立部署元件

如果你部署的軟體專案有至少兩個domain，每個domain代表完全獨立的業務能力或流程，那麼實施微服務架構將是一個適合的選項。這樣做可以使應用的各個元件開生命週期獨立開來，在更新或部署應用程式時，不會影響其他元件。此外，可以讓每個元件採用不同的編碼語言。當然，微服務架構同時會需求單一元件由專門的開發團隊動態管理，因此你需要確保有足夠的人才和預算來這麼做。

團隊是否有足夠能力

微服務架構意味著，你需要建立專門從事某些專業領域的小型開發團隊，提高新功能開發和增強競爭優勢的能力。

因此團隊是否成熟，是否可以實現CI/CD，是否理解DevOps？如果答案是否定的，著手建立更強大的工程師團隊，或找到可以幫助補充團隊能力的外部資源，例如像Heroku、好雨雲這樣的提供開發、運維、應用交付支援的雲平臺。

公司的roadmap是否實際

指數級的擴張能力讓一些巨頭公司發展成了現在的樣子。例如Airbnb，在不到10年的時間裡，從床位租賃網站發展成為了300億美元規模的資料驅動型marketplace。對於成長型公司來說敏捷十分重要，但不是所有公司都有很大的擴張需求。如果你不需要面對複雜性的問題，那麼其實是沒必要實施微服務架構的。

因此要對公司的發展有一個客觀的判斷，至少是短時間內的成長判斷，最好不要讓開發流程在不需要複雜的時候過於複雜。

最後，當你確定要實施微服務架構，以下幾點經驗值得留意：

• 實施微服務架構後，一定要廣泛使用一旦實現了微服務架構，一定要廣泛使用領域驅動設計（DDD，Domain Driven Design），特別是bounded contexts
• 對於bounded contexts的定義沒有特別的規定，這取決於你使用的domain，當然一般情況下，context map是不錯的選擇
• 每個微服務應代表一個業務能力的，你應該專注於把元件做好，獨立於其他服務
• 確保你的團隊結構跟定製的bounded contexts保持一致。為了更好的享受微服務架構的優勢，你的團隊應該圍繞業務能力建立，而不是建立會增加額外負擔的“橫向”團隊