文章帶有強(qiáng)烈的個(gè)人觀點(diǎn)和成長(zhǎng)經(jīng)歷，針對(duì)的是政務(wù)項(xiàng)目，而非互聯(lián)網(wǎng)，參考即可。

背景介紹

一直網(wǎng)上查找相關(guān)的學(xué)習(xí)資料用于實(shí)踐并落地服務(wù)化，分布式，美好的資料與真正落地實(shí)踐是兩個(gè)一樣的層次，真正能落地的資料較少，這過(guò)程中有很多的問(wèn)題，能不能解決，團(tuán)隊(duì)、個(gè)人能不能支撐這個(gè)過(guò)程，都是一個(gè)問(wèn)號(hào)。其中很多討論的就是Dubbo和Cloud的選型的問(wèn)題，這里表達(dá)一下自己的實(shí)踐經(jīng)驗(yàn)的感受與選型，我有我思。

微服務(wù)是一種架構(gòu)設(shè)計(jì)，但是我這里說(shuō)的更多的是服務(wù)化，主要針對(duì)的是傳統(tǒng)項(xiàng)目轉(zhuǎn)過(guò)來(lái)的過(guò)程，所以，以下文以服務(wù)化來(lái)代替微服務(wù)。此處針對(duì)的是政務(wù)型項(xiàng)目，而非互聯(lián)網(wǎng)項(xiàng)目，自己在政務(wù)項(xiàng)目經(jīng)驗(yàn)較多，而互聯(lián)網(wǎng)項(xiàng)目項(xiàng)目經(jīng)驗(yàn)、管理經(jīng)驗(yàn)較為缺乏，比如團(tuán)隊(duì)管理政務(wù)項(xiàng)目更偏向于人才培養(yǎng)，技術(shù)積累，可以使用信息化項(xiàng)目管理體系管理項(xiàng)目，但是互聯(lián)網(wǎng)項(xiàng)目可能有些并沒(méi)有這個(gè)條件，比如一個(gè)項(xiàng)目周期2至4個(gè)星期，項(xiàng)目管理體系還沒(méi)有起來(lái)就可能結(jié)束了。

為什么擁抱Dubbo而排斥Cloud體系，并不是因?yàn)榧夹g(shù)不好，也不是因?yàn)榧夹g(shù)過(guò)分崇拜，更不是因?yàn)閲?guó)內(nèi)外，或者阿里系，Spring系之類(lèi)的，而是自己在建立個(gè)人學(xué)習(xí)開(kāi)發(fā)平臺(tái)的過(guò)程中，

自己建立的個(gè)人學(xué)習(xí)開(kāi)發(fā)平臺(tái)（http://cloud.linesno.com)

自己的經(jīng)驗(yàn)和體會(huì)表達(dá)，原開(kāi)始使用的是Cloud技術(shù)，后來(lái)轉(zhuǎn)變成Dubbo技術(shù)，這一過(guò)程中的體會(huì)，分以下幾個(gè)點(diǎn)闡述：

團(tuán)隊(duì)和人才市場(chǎng)有一定的局限

從大一點(diǎn)的來(lái)說(shuō)，Java的工程師培養(yǎng)一直以來(lái)都是SSH或者SSM體系入門(mén)，同時(shí)MVC層次更是深入Java開(kāi)發(fā)人員思維，這些幾乎是每個(gè)Java都是非常熟悉，接觸的項(xiàng)目最多架構(gòu)。大量的培訓(xùn)機(jī)構(gòu)，都是這幾套，幾乎是這10多年Java軟件培育的結(jié)果，這為在后期招聘，運(yùn)維，團(tuán)隊(duì)組件上規(guī)避了極大的招聘風(fēng)險(xiǎn)，團(tuán)隊(duì)風(fēng)險(xiǎn)。

從小的來(lái)說(shuō)，目前接觸的團(tuán)隊(duì)，幾乎都是單體項(xiàng)目轉(zhuǎn)過(guò)來(lái)，開(kāi)發(fā)過(guò)程，不管是異常處理，問(wèn)題處理，都有極大的經(jīng)驗(yàn)值，還有習(xí)慣，思維，這些都有極大的促進(jìn)項(xiàng)目的開(kāi)發(fā)效率，而這些都是建立在【習(xí)慣】的思維上，在服務(wù)化的路線上，如果選型得當(dāng)，幾乎可以省去很多的培養(yǎng)成本，適應(yīng)成本。

這點(diǎn)不能站在開(kāi)發(fā)者的角度，常常聽(tīng)開(kāi)發(fā)者說(shuō)這個(gè)技術(shù)沒(méi)問(wèn)題，但是團(tuán)隊(duì)來(lái)說(shuō)，團(tuán)隊(duì)的角度考慮，服務(wù)化一個(gè)人開(kāi)發(fā)跟一群人開(kāi)發(fā)是天與地的區(qū)別

怎么使用舊的資源，更低成本的實(shí)現(xiàn)服務(wù)化，服務(wù)化之后是否能提高研發(fā)效率，解決業(yè)務(wù)問(wèn)題，解決項(xiàng)目管理問(wèn)題，解決團(tuán)隊(duì)開(kāi)發(fā)效率問(wèn)題，怎么引入新的技術(shù)，怎么引入DevOps，又要團(tuán)隊(duì)能接受，成本能接受，同時(shí)又要降低抵觸情緒等，才是需要思考的，相對(duì)而言，技術(shù)點(diǎn)就比較容易考慮了。

回到我們的技術(shù)點(diǎn)上，我們來(lái)看一個(gè)技術(shù)例子，Dubbo技術(shù)幾乎是無(wú)縫切入MVC工程，或者SSM工程，這幾乎是歸功于Dubbo的傳輸方式，相對(duì)而言，Cloud的HTTP+JSON傳輸，在這過(guò)程工程之間的交互幾乎是災(zāi)難，復(fù)雜的數(shù)據(jù)不能傳輸，傳輸效率過(guò)低，接口管理困難，而在Dubbo這塊，利用JavaAPI的特點(diǎn)，接口調(diào)整便直接提示異常，一目了然（也有弊端，這靠規(guī)范來(lái)管理），也規(guī)避了這部分風(fēng)險(xiǎn)，省去成本較高的接口管理（并不是不需要管理，更多的建議是規(guī)范）。

在之前實(shí)踐的過(guò)程中，這步做得倒還是比較成功，技術(shù)上遮蔽了注冊(cè)這塊（即這些都已經(jīng)配置好），前期融合的Java工程，Dubbo技術(shù)還是比較容易，有些項(xiàng)目組成員開(kāi)發(fā)了近半年，依然感覺(jué)在做單體應(yīng)用，甚至沒(méi)有體會(huì)到這個(gè)是在分布式應(yīng)用或者微服務(wù)。更有甚的，服務(wù)化項(xiàng)目已經(jīng)準(zhǔn)備上線了，有開(kāi)發(fā)拿著一篇PPT說(shuō)，”你看這樣的技術(shù)架構(gòu)，我們是不是也考慮一下“，而他說(shuō)的那個(gè)PPT的架構(gòu)，已經(jīng)是兩年前做的設(shè)計(jì)，并且實(shí)踐成功落地。

業(yè)務(wù)場(chǎng)景限制和資源限制

業(yè)務(wù)場(chǎng)景是設(shè)計(jì)人員必須要做的考慮，團(tuán)隊(duì)不管是技術(shù)能力強(qiáng)還是資源充足也好，但是結(jié)果是否能實(shí)際的完成業(yè)務(wù)開(kāi)發(fā)，服務(wù)于業(yè)務(wù)這才是價(jià)值體現(xiàn)。業(yè)務(wù)場(chǎng)景有哪些？

需要考慮怎么樣的場(chǎng)景，這需要針對(duì)具體的業(yè)務(wù)實(shí)現(xiàn)，而往往針對(duì)于企業(yè)來(lái)說(shuō)，至少軟件公司來(lái)說(shuō)，同步也要考慮實(shí)際團(tuán)隊(duì)的場(chǎng)景，能力，能產(chǎn)生的價(jià)值，而不是團(tuán)隊(duì)都是初級(jí)工程師，偏偏要規(guī)劃出高級(jí)產(chǎn)品設(shè)計(jì)，更不要項(xiàng)目周期短，卻規(guī)劃出一個(gè)N多組件的微服務(wù)項(xiàng)目，服務(wù)組件全套用上。項(xiàng)目開(kāi)發(fā)最終的目標(biāo)不是為了微服務(wù)那套治理，更不是那整套的監(jiān)控，也是不是那一個(gè)個(gè)組件，更多的為了業(yè)務(wù)服務(wù)，為了提供更高的生產(chǎn)力，本質(zhì)是產(chǎn)生價(jià)值。

服務(wù)化組件設(shè)計(jì)

項(xiàng)目經(jīng)費(fèi)，周期，團(tuán)隊(duì)，硬件等資源限制，怎么能更好的在有限的場(chǎng)景里面服務(wù)好業(yè)務(wù)，又能落地好技術(shù)的規(guī)劃，服務(wù)化組件的抽取，共用，同時(shí)還要能完成指定的指標(biāo)，這是需要考慮的。

Cloud研發(fā)過(guò)程太多的組件和概念，相對(duì)來(lái)說(shuō)，可能【完善】，但是反面來(lái)，卻可能成了開(kāi)發(fā)的壁壘，畢竟，不是每個(gè)項(xiàng)目都是一上來(lái)就有十幾或者上百臺(tái)服務(wù)器的資源，幾千萬(wàn)的項(xiàng)目經(jīng)費(fèi)，更多的可能是幾百萬(wàn)，幾十萬(wàn)，只提供幾臺(tái)16G內(nèi)存，硬盤(pán)暫時(shí)考慮都滿足，一個(gè)Oracle或者M(jìn)ySQL數(shù)據(jù)資源。 整個(gè)服務(wù)化過(guò)程中，項(xiàng)目只需要一個(gè)穩(wěn)定的，功能完善的RPC服務(wù)，來(lái)完成SOA，需要治理，也需要監(jiān)控，但是這個(gè)并不是必須， 需要的是完成項(xiàng)目，快速研發(fā)并提供服務(wù)，消費(fèi)服務(wù)。

而正是Dubbo精簡(jiǎn)化，針對(duì)性，有監(jiān)控（Dubbo-Admin）等的情況下，服務(wù)化項(xiàng)目考慮，經(jīng)過(guò)多年國(guó)內(nèi)實(shí)踐，有大量現(xiàn)成的文檔和解決方案，滿足實(shí)踐項(xiàng)目開(kāi)發(fā)的需求，反面變成輕量級(jí)的服務(wù)化工具，更加合適團(tuán)隊(duì)，一個(gè)問(wèn)題，你確定你的項(xiàng)目真的一定需要分布式配置中心么？

技術(shù)過(guò)分冗余，軟件價(jià)值考慮

所謂的冗余，有點(diǎn)類(lèi)似于雞肋的說(shuō)法，丟了又覺(jué)得可惜，使用又覺(jué)得用不上，或者使用的場(chǎng)景很少之類(lèi)的，剛剛上文也提到，分布式配置中心是否真的工程需要的（安裝一個(gè)Apollo需要多少服務(wù)器資源？）；再比如是否真的需要鏈接跟蹤，業(yè)務(wù)真的有那么大的訪問(wèn)量，再或者這訪問(wèn)過(guò)程是否是可能通過(guò)日志手段排查；再比如ELK，還有容器化，消息中間件之類(lèi)的。以下的場(chǎng)景針對(duì)于一般性項(xiàng)目（幾十萬(wàn)至幾百萬(wàn)政務(wù)系統(tǒng)）來(lái)說(shuō)，相信這類(lèi)型項(xiàng)目在政務(wù)來(lái)說(shuō)，比較常見(jiàn)，而這類(lèi)型項(xiàng)目的服務(wù)器資源，項(xiàng)目資源（硬件，軟件）往往很少 。

上面提到的，只是一部分，聽(tīng)起來(lái)好像有點(diǎn)不太可思議，甚至有點(diǎn)沖動(dòng)，

“分布式項(xiàng)目怎么不需要配置中心，不是更簡(jiǎn)便的么？” “ 消息中間件是來(lái)處理日志或者可靠消息，必不可少的“”容器化容易發(fā)布“ 或者說(shuō) ”ELK可以有界面查詢，及時(shí)收集多臺(tái)服務(wù)器的日志”?等等

這些都沒(méi)有錯(cuò)，但是也要考慮一點(diǎn)，但太多的技術(shù)債，維護(hù)成本有可能遠(yuǎn)高于應(yīng)用系統(tǒng)的維護(hù)成本，原本應(yīng)用軟件就一個(gè)運(yùn)維可以搞定的，加上這些不知名（相對(duì)于原運(yùn)維來(lái)說(shuō)），處理起來(lái)更加困難，而往往要求助于開(kāi)發(fā)，這樣，一個(gè)運(yùn)維的成本，還有開(kāi)發(fā)人員的支持，運(yùn)維的成長(zhǎng)周期可能就需要1至2年，而一個(gè)軟件項(xiàng)目的生命周期也僅僅是5~10年（再往上的，穩(wěn)定性也已經(jīng)很強(qiáng)）。而實(shí)際上，這類(lèi)型的項(xiàng)目實(shí)際在測(cè)試過(guò)之后，穩(wěn)定性及可靠性已經(jīng)很強(qiáng)，出現(xiàn)問(wèn)題的往往并不是技術(shù)問(wèn)題，而是業(yè)務(wù)問(wèn)題。

全監(jiān)控化運(yùn)維

即使出了線上問(wèn)題，排查周期一年左右，基本上也趨于平穩(wěn)，而使用大量的技術(shù)冗余，是否確定可以這一年里面運(yùn)維可以正常學(xué)習(xí)到？或者再反問(wèn)，確定運(yùn)維會(huì)去學(xué)么？開(kāi)發(fā)人員的支持一定到位么？中間溝通成本是否有考慮過(guò)？學(xué)習(xí)成本與問(wèn)題消化成本是否等價(jià)？

技術(shù)精簡(jiǎn)化，遮蔽技術(shù)，大道至簡(jiǎn)等這些都是設(shè)計(jì)中需要考慮的，而Cloud大量的技術(shù)引入，是否真的合適這樣的場(chǎng)景，是否讓團(tuán)隊(duì)可以正常消化，并產(chǎn)生價(jià)值，這是我們需要考慮的。沒(méi)錯(cuò)，傳統(tǒng)軟件開(kāi)發(fā)確實(shí)很困難，有弊端，DevOps體系，服務(wù)化架構(gòu)確實(shí)可以做到一定的提升，但是我們?cè)趺醋钌俪杀厩腥?，并提升我們自己的價(jià)值，這不是更重要？也許剛剛上面提到的，人員培養(yǎng)過(guò)程確實(shí)為后期提供了另一種可能，也是企業(yè)所需要考慮的，但是有一定是成本權(quán)衡。

相對(duì)而言，Dubbo這塊的穩(wěn)定性，效率，精簡(jiǎn)，與Spring的無(wú)縫融合，相對(duì)于Cloud的大量的技術(shù)債，確實(shí)有它一定的優(yōu)越性，靈活性。

更靈活的技術(shù)迭代和選型

項(xiàng)目架構(gòu)的設(shè)計(jì)，項(xiàng)目的版本提升，迭代，新技術(shù)怎么快速切入原項(xiàng)目架構(gòu)而不影響，甚至是替代，都是需要考慮的。這不是必須，也可能不會(huì)發(fā)生，或者發(fā)生的機(jī)率比較小，但是它確確實(shí)實(shí)存在。

一般的項(xiàng)目上線，可能在這個(gè)周期內(nèi)不會(huì)變動(dòng)，但服務(wù)化的產(chǎn)生，使得大量的組件產(chǎn)生和成熟，在新的項(xiàng)目中產(chǎn)生迭代，升級(jí)，而這一些的操作過(guò)程，都是盡量原子化，比如替換掉UI，可能一次性替換，比如升級(jí)Dubbo，，升級(jí)Spring，怎么樣快速做到靈活升級(jí)，而且對(duì)開(kāi)發(fā)人員做到無(wú)感無(wú)知（理想狀態(tài)），更或者產(chǎn)是不影響當(dāng)前的版本，這是我們需要考慮的。

再回到Cloud，組件封裝得甚至有些過(guò)渡，我們團(tuán)隊(duì)，也可以說(shuō)你們團(tuán)隊(duì)確定是可以接受它技術(shù)的迭代么？1.5到2的升級(jí)，就有了很多變動(dòng)，甚至要調(diào)整業(yè)務(wù)代碼。為什么？Spring團(tuán)隊(duì)并不是針對(duì)于一個(gè)技術(shù)團(tuán)隊(duì)服務(wù)的，而是針對(duì)于所有的Spring開(kāi)發(fā)者。如果我們自己不能把控，即使能把控，也有可能會(huì)產(chǎn)生大量的維護(hù)成本，人員成本。組件太多，甚至你也不知道他在哪里，而某個(gè)依賴(lài)的升級(jí)，是否會(huì)影響到其它版本的正常運(yùn)維，這更難說(shuō)。

怎么樣有效管理工程迭代，升級(jí)，做到對(duì)開(kāi)發(fā)的無(wú)縫感知，這是我們需要考慮的。

這里就不再細(xì)說(shuō)，Dubbo就只是一個(gè)包，換掉即可，其實(shí)個(gè)人建議是不要換，因?yàn)檫@個(gè)包只是為我們提供了高質(zhì)量的RPC服務(wù)，穩(wěn)定即可，更多的，推薦升級(jí)周邊服務(wù)，比如MyBaties，Spring等。一些場(chǎng)景下可能是一定要做升級(jí)的，比如兼容K8S，目前Dubbo轉(zhuǎn)Apache維護(hù)，升級(jí)官方也出了文檔，Cloud升級(jí)是否可能提供文檔，也許可能，但是太多組件，風(fēng)險(xiǎn)也很大。針對(duì)于Dubbo工程，依賴(lài)包的問(wèn)題會(huì)產(chǎn)生未知包引入，這個(gè)我們是在行政管理和代碼評(píng)審上做的強(qiáng)制管理，這些由規(guī)范做約束。

推薦服務(wù)化技術(shù)實(shí)現(xiàn)方式

與其說(shuō)推薦，更多說(shuō)的是實(shí)踐過(guò)程中積累的實(shí)際場(chǎng)景，學(xué)會(huì)取長(zhǎng)補(bǔ)短，兩者結(jié)合，也未償不可。大概畫(huà)了一個(gè)簡(jiǎn)單的架構(gòu)設(shè)計(jì)圖，對(duì)內(nèi)使用Dubbo的優(yōu)勢(shì)，對(duì)外使用Cloud的概念。

服務(wù)化技術(shù)架構(gòu)，Cloud有一定的優(yōu)勢(shì)，但是我們需要用到的是他的是HTTP+JSON，而這個(gè)，Boot已經(jīng)實(shí)現(xiàn)了，與其說(shuō)使用Cloud，還不如用Boot，可以適當(dāng)引用一些Cloud組件，比如網(wǎng)關(guān)組件，消息組件，分布式鏈路跟蹤組件，熔斷器組件（不過(guò)聽(tīng)說(shuō)不維護(hù)了），做為外部系統(tǒng)對(duì)接，如第三方系統(tǒng)，或者內(nèi)部多系統(tǒng)對(duì)接。對(duì)內(nèi)采用Dubbo提升開(kāi)發(fā)效率和傳輸效率。

技術(shù)本身沒(méi)有對(duì)比性，只能說(shuō)場(chǎng)景符合，針對(duì)合適的場(chǎng)景，團(tuán)隊(duì)，項(xiàng)目，條件等使用合適的技術(shù)實(shí)現(xiàn)。