微服務架構的優勢

微服務可通過分布式部署，大幅提公升您的團隊和日常工作效率。您還可以並行開發多個微服務。這意味著更多開發人員可以同時開發同乙個應用，進而縮短開發所需的時間。

由於開發周期縮短，微服務架構有助於實現更加敏捷的部署和更新。

隨著某些服務的不斷擴充套件，您可以跨多個伺服器和基礎架構進行部署，充分滿足自身需求。

只要確保正確構建，這些獨立的服務就不會彼此影響。這意味著，乙個服務出現故障不會導致整個應用下線，這一點與單體式應用模型不同。

相對於傳統的單體式應用，基於微服務的應用更加模組化且小巧，所以您無需為它們的部署操心。雖然對部署時的協作要求更高，但之後能獲得巨大回報。

由於大型應用被拆分成了多個小型服務，所以開發人員能夠更加輕鬆地理解、更新和增強這些服務，從而縮短開發周期（尤其是在搭配使用敏捷的開發方法時）。

由於使用了多語言 api，所以開發人員可以根據需要實現的功能，自由選用最適合的語言和技術。

如果您的企業正在考慮遷移到微服務架構，那麼不僅是應用要變，相關人員的工作方式也會隨之而變。在某種意義上，改變企業和文化並不容易，因為每個團隊都有自己的部署節奏和所負責的服務，而且這些服務都擁有自己的客戶群。這些可能並不是開發人員通常要擔心的問題，但是這些問題卻決定了微服務架構能否取得成功。

除了文化和流程之外，複雜性和效率問題是基於微服務的架構所面臨的另外兩大挑戰。以下八類挑戰：

構建：您必須花時間明確各個服務間的依賴關係。要知道，由於存在這些依賴關係，當您完成乙個構建時，可能會觸發多個其他構建。您還需要考慮微服務對於資料的影響。

測試：整合測試和端到端測試可能會前所未有的難以實施，但卻更加重要。根據您在架構相互支撐的服務時所採用的不同方式，架構中的乙個部分出現故障，很可能會導致其他部分也隨之出現故障。

版本管理：在更新到新版本時，請記住：向後相容性可能會因更新操作而失效。要解決這一問題，您可以利用條件邏輯來進行構建，但是構建會變得繁複、難以控制且快速。或者，您也可以為不同的客戶端維護多個活躍版本，但是相關的維護和管理工作會變得更加龐雜。

部署：沒錯，這也是一大挑戰，至少是首次設定時所要面臨的一大挑戰。為了簡化部署，您必須先大量投資自動化，因為人工部署無法應對微服務的複雜性。請好好思考您要以何種方式以及怎樣的順序來部署各項服務。

監控：您必須通過乙個集中式檢視來了解整個系統的情況，以便找出問題的根源。

除錯：無法進行遠端除錯，因為這種方式無法涵蓋數十個或數百個服務。不幸的是，關於應該如何進行除錯，目前還沒有標準答案。

連線：請考慮使用服務探索功能，無論是集中式的還是整合式。