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

更進一步，如果希望更好地發(fā)揮微服務(wù)架構(gòu)的優(yōu)勢，規(guī)避缺點，則建議準備一個可靠的基礎(chǔ)設(shè)施，包含自動構(gòu)建、自動部署、日志中心、健康檢查、性能監(jiān)控等功能。

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

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

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

近年來，Spring Cloud 儼然已經(jīng)成為微服務(wù)開發(fā)的主流技術(shù)棧，在國內(nèi)開發(fā)者社區(qū)非常火爆。

基于我長期以來在一線互聯(lián)網(wǎng)公司（攜程，拍拍貸等）開展微服務(wù)架構(gòu)的實踐經(jīng)驗以及平時對 Spring Cloud 的調(diào)研，我認為 Spring Cloud 技術(shù)棧中的一部分組件離生產(chǎn)級開發(fā)尚有一定距離。

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

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

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