微服務架構的運維問題，主要是相對于單體架構來說的。因為實施微服務架構后，整個系統的模塊一下子比原來多了很多，模塊變多后，部署和維護的工作量都會變大。所以，解決運維難的問題，可以先從“自動化”的角度來解決。

更進一步，如果希望更好地發揮微服務架構的優勢，規避缺點，則建議準備一個可靠的基礎設施，包含自動構建、自動部署、日志中心、健康檢查、性能監控等功能。

否則，很有可能會因為微服務架構的缺點導致我們的團隊喪失對微服務架構的信心，從而回到單體架構的老路上去。工欲善其事，必先利其器，這一點真的很重要。

    何謂微服務架構的簡單模式？相對于大型互聯網平臺動輒幾萬并發的訪問量，或者每天多次的在線版本發布，絕大多數企業和項目并沒有這樣的需求。他們關注的是如何更好地提高開發效率，如何更快地實現新需求，如何更便利地運維，等等。

微服務架構的簡單模式就是可以滿足以上需求的軟件架構方案。相對于“完美”的微服務架構方案，微服務架構簡單模式可以暫且不用關注保障數據一致性的分布式事務技術、方便程序包在環境間（開發、測試、生產）遷移的配置中心組件、監控 API 調用情況的調用鏈組件、避免系統超載的斷路器組件、方便 API 管理和測試的 API 文檔框架、Zookeeper、Redis，以及各種 MQ。只需要關注常常談到的 注冊中心、服務發現、負載均衡 和 服務網關 即可。

近年來，Spring Cloud 儼然已經成為微服務開發的主流技術棧，在國內開發者社區非常火爆。

基于我長期以來在一線互聯網公司（攜程，拍拍貸等）開展微服務架構的實踐經驗以及平時對 Spring Cloud 的調研，我認為 Spring Cloud 技術棧中的一部分組件離生產級開發尚有一定距離。

比方說 Spring Cloud Config 和 Spring Cloud Sleuth 都是 Pivotal 自研產品，尚未得到大規模企業級生產應用，很多企業級特性缺失，另外 Spring Cloud 體系還缺失一些關鍵的微服務基礎組件，比如 Metrics 監控，健康檢查和告警等。

這些情況導致了開發人員在實際工作中無法高效、快速地構建出適用于企業生產環境的微服務架構，而是要花不少時間和精力走很多彎路，同時也對部分工程師通過實踐的方式來學習微服務架構相關知識帶來了一定的障礙。

紅帽公司中間件部門工程副總裁Mark Little博士也曾說過：“我在微服務架構方面擔心的問題之一就是，你有一個整體式單體架構應用，假設你隨意把它分解成多個服務，到頭來就會分解得過細，最后會有10個、100個甚至1000個微服務。但是這些微服務又彼此高度依賴，以至于如果某一個服務出現故障，其余服務很有可能也會出現故障。這種情況下，你將一無所獲。你有999個服務就在那里干等著另一個服務恢復正常運行之后才能工作。”