微服務(wù)架構(gòu)的運(yùn)維問(wèn)題，主要是相對(duì)于單體架構(gòu)來(lái)說(shuō)的。因?yàn)閷?shí)施微服務(wù)架構(gòu)后，整個(gè)系統(tǒng)的模塊一下子比原來(lái)多了很多，模塊變多后，部署和維護(hù)的工作量都會(huì)變大。所以，解決運(yùn)維難的問(wèn)題，可以先從“自動(dòng)化”的角度來(lái)解決。

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

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

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

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

近年來(lái)，Spring Cloud 儼然已經(jīng)成為微服務(wù)開(kāi)發(fā)的主流技術(shù)棧，在國(guó)內(nèi)開(kāi)發(fā)者社區(qū)非?；鸨?/strong>

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

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

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

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