第一篇：技改之路：從單塊應(yīng)用到微服務(wù),我的血淚總結(jié)

技改之路：從單塊應(yīng)用到微服務(wù)，我的血淚總結(jié)

2016-05-23張輝清技改是技術(shù)改造的簡稱，是技術(shù)的蛻變。本文指的是在公司技術(shù)發(fā)展的某個(gè)瓶頸階段，按原有開發(fā)和組織方式已經(jīng)無法玩下去，這時(shí)公司希望引進(jìn)架構(gòu)師或技術(shù)牛人，來破解當(dāng)前困局。技術(shù)改造，對于公司和技術(shù)人員而言都非常難得，參與者多，主導(dǎo)者少。我有幸前后主導(dǎo)過3次OTA系統(tǒng)的技改，規(guī)模有大有小，每次環(huán)境和問題雖不一樣，但還是有套路可循。《技改之路》少講技術(shù)多講路，我們不過多的關(guān)注技術(shù)細(xì)節(jié)和中間件的實(shí)現(xiàn)，而重點(diǎn)講述技術(shù)改造的過程和思考，以下是本次分享的Topic： 系統(tǒng)背景 前期工作 技改實(shí)施 總結(jié)

一、系統(tǒng)背景 ?

?

?

?

1、技術(shù)規(guī)模 公司

? 國內(nèi)領(lǐng)先的B2B機(jī)票分銷平臺 資本原始積累，財(cái)務(wù)良好，一直盈利 系統(tǒng)規(guī)模 ?

? 200+應(yīng)用 ? 100+庫，1萬+表 研發(fā)規(guī)模

? 開發(fā)人員200人左右 服務(wù)器有200臺左右

此案例是一個(gè)中等規(guī)模的電子商務(wù)公司，老板白手起家，資本原始積累，現(xiàn)在賺錢的互聯(lián)網(wǎng)公司很少哦。公司從2006年的幾個(gè)研發(fā)人員，到技改前的200個(gè)左右研發(fā)人員，業(yè)務(wù)發(fā)展良好，是國內(nèi)領(lǐng)先的B2B機(jī)票分銷平臺，互聯(lián)網(wǎng)名聲雖不大，但處于悶聲發(fā)大財(cái)?shù)臓顟B(tài)。

公司之前嘗試過2次系統(tǒng)重建，請了一批批的牛人，前后經(jīng)歷過4年。公司消耗大，但都以失敗告終。此案例是我本人的第2次技改，效果不錯(cuò)，整體進(jìn)展順利，團(tuán)隊(duì)技術(shù)水平也有1~2個(gè)檔次的提升，算是比較成功的實(shí)踐。另外，因?yàn)榘咐^于真實(shí)，有些UML會打上馬賽克，請多諒解。

2、單塊應(yīng)用

3、主要問題 ?

? 單塊應(yīng)用，該合并的沒有合并，該拆開的沒有拆開，單個(gè)體量不合理，主平臺體量太大，其它又過??；

技術(shù)過舊：使用7年以前的技術(shù)，主平臺采用單塊應(yīng)用，且體量過大，無法整體更新維護(hù)； ? ? 多版本共存：版本混亂，只敢添加，不敢修改； 整個(gè)系統(tǒng)非常脆弱，問題多，訪問量一大就掛；

管理問題：發(fā)布困難、測試?yán)щy、修改困難、排錯(cuò)困難。

二、前期工作 ?

?

1、架構(gòu)部組建 成立架構(gòu)部：

內(nèi)招幾名老程序員，外招幾個(gè)架構(gòu)師 培養(yǎng)：

內(nèi)部走出去，提高眼界；外部牛人請進(jìn)來，落地了解歷史和業(yè)務(wù) 制度：

項(xiàng)目管理+知識分享： JIRA+WIKI 團(tuán)隊(duì)建設(shè)、技術(shù)分享、工程師文化

2、總體規(guī)劃

架構(gòu)是演化出來的還是設(shè)計(jì)出來的？對于創(chuàng)業(yè)場景，創(chuàng)業(yè)本身就是在未知中尋找機(jī)會，將不清楚變?yōu)榍宄?，系統(tǒng)的架構(gòu)自然是演化出來的，而對于技術(shù)改造或Google搜索等復(fù)雜工程場景，系統(tǒng)的架構(gòu)當(dāng)然要精心策劃。?

?

?

? 公司電商系統(tǒng)總體架構(gòu)，我們整整花了1個(gè)多月的時(shí)間，對項(xiàng)目做了總體的規(guī)劃，然后對內(nèi)宣講推廣，讓每一個(gè)參與者了解自已的目標(biāo)和價(jià)值。不手握地圖，你怎知站對了位置！、中間件構(gòu)建 我們構(gòu)建的中間件有：

job/redis/center Log/業(yè)務(wù)監(jiān)控metrics/dashboad/調(diào)試工具windbg/rabbitMQ/ORM工具dapper/MongoDB/jetermclient/公共類庫jFX/zookeeper/openTSDB/HBase/searcher工具solr/元數(shù)據(jù)管理DDM/DLL管理nuget/自動發(fā)布Jenkins/微服務(wù)架構(gòu)JSOA/ 中間件是應(yīng)用系統(tǒng)的基礎(chǔ)設(shè)施，是應(yīng)用的裝備和工具。農(nóng)村建住房是一塊磚一塊磚的往上壘，城市建大house則是先打地基，然后再建主框架，最后才是壘磚，所以中間件的建設(shè)是大中型系統(tǒng)建設(shè)的前提。

以上中件間的構(gòu)建過程貫穿于整個(gè)技改的生命周期，每一個(gè)中間件可能需要花1~2個(gè)月，它們大部分都基于開源。請關(guān)注上面的順序，直面當(dāng)前的問題，按需快速構(gòu)建和推動。雖然使用開源，但中件間的引進(jìn)和改造有自已的一套流程：調(diào)查 =>試用 =>選型 =>深入研究 => demo => wiki =>分享推廣 =>業(yè)務(wù)系統(tǒng)試用 =>改進(jìn)完善 =>大規(guī)模推廣。

中間件的構(gòu)建和增加，不僅對當(dāng)前業(yè)務(wù)系統(tǒng)影響較小，還可以解決一部分業(yè)務(wù)難題，減輕數(shù)據(jù)庫的壓力。同時(shí)它還有利于建立技術(shù)氛圍和分享機(jī)制。一支有激情、愛技術(shù)的研發(fā)團(tuán)隊(duì)，對技改的具體實(shí)施是非常重要的。

三、技改實(shí)施

1、數(shù)據(jù)庫改造

當(dāng)面對100個(gè)多庫時(shí)，我認(rèn)為系統(tǒng)架構(gòu)師關(guān)注到數(shù)據(jù)庫級別即可，建庫拆庫。數(shù)據(jù)庫按模塊整體遷移，其實(shí)并沒有想象中那么難，理想情況下只需修改數(shù)據(jù)庫的鏈接，而對于表和字段的優(yōu)化，可由應(yīng)用架構(gòu)師或技術(shù)主管，以SOA收口或應(yīng)用重構(gòu)來實(shí)現(xiàn)。

數(shù)據(jù)庫如何做到可伸縮，可大可小方便拆分呢，思考如下：

1.上圖從內(nèi)往外看，一個(gè)框即可以是一個(gè)庫，也可以是一個(gè)模塊，還可以是一個(gè)表，根據(jù)當(dāng)前業(yè)務(wù)規(guī)模和系統(tǒng)復(fù)雜度來實(shí)現(xiàn)；

2.我們的大實(shí)體關(guān)系圖具體為：產(chǎn)品、用戶、訂單、結(jié)算、基礎(chǔ)設(shè)施。它們早期可以是一個(gè)庫，里面有5個(gè)模塊，中期可以分為5個(gè)庫，后期則可以更底級別分為更多的庫；

3.命名規(guī)范：數(shù)據(jù)庫名：業(yè)務(wù)線縮寫+庫名；模塊名：參考大E-R圖+專業(yè)詞匯縮寫；表名：模塊縮寫+表名；自增編號：表名+ID； 4.模塊內(nèi)可多表聯(lián)接，模塊間減少聯(lián)接，數(shù)據(jù)庫間不允許聯(lián)接；

5.每一個(gè)數(shù)據(jù)庫有且僅有一個(gè)Owner組，原則上只允許一個(gè)團(tuán)隊(duì)才能Create，其它團(tuán)隊(duì)訪問需要分級控制，L1為接口，L2為只讀庫，L3為直接讀寫“寫庫”。數(shù)據(jù)庫規(guī)劃

數(shù)據(jù)庫是整個(gè)信息系統(tǒng)中生命周期最長、最難修改的部分。所以讓時(shí)間來解決時(shí)間的問題，要加強(qiáng)設(shè)計(jì)，具體實(shí)施過程如下：

1.在地圖即總體架構(gòu)文檔推廣后，我們就新建立了一批庫，這在早期還遭到DBA的抱怨；

2.新增相關(guān)庫后，新表按新規(guī)則創(chuàng)建，特殊情況走特珠審批； 3.去SP去關(guān)聯(lián)，讓數(shù)據(jù)庫減少計(jì)算，回歸存儲本質(zhì)； 4.數(shù)據(jù)庫拆分，改表改字段，采用模塊整體遷移或應(yīng)用重構(gòu)；

5.一年后，再去看數(shù)據(jù)庫，發(fā)現(xiàn)在沒有特別立項(xiàng)和驅(qū)動的情況下，已接近一半的表在新庫中。數(shù)據(jù)變遷

狀態(tài)圖是數(shù)據(jù)的變遷，是數(shù)據(jù)與行為的互動，數(shù)據(jù)的變化會引起行為的變化，行為的變化會產(chǎn)生數(shù)據(jù)的不同。上圖是國內(nèi)的訂單狀態(tài)變遷圖，它的價(jià)值不僅屬于數(shù)據(jù)庫層，還在于SOA服務(wù)化和核心業(yè)務(wù)流程。

2、服務(wù)改造

服務(wù)是動詞，是行為或活動的抽象，它的價(jià)值在于業(yè)務(wù)邏輯或行為的重用，具體實(shí)施過程如下：

1.服務(wù)列表和服務(wù)協(xié)議，在設(shè)計(jì)階段使用Excel表格； 2.統(tǒng)一Request/Response規(guī)范； 3.服務(wù)實(shí)現(xiàn)，因沒有直接可見的業(yè)務(wù)價(jià)值輸出，最好以工單或項(xiàng)目來落地； 4.服務(wù)治理，早期沒有工具時(shí)，使用WIKI做簡單管理，后期使用專業(yè)的服務(wù)治理工具。領(lǐng)域模型

沒有領(lǐng)域圖的架構(gòu)設(shè)計(jì)都是耍流氓，我們畫領(lǐng)域圖的架構(gòu)師是2位老員工，沒有多少高大上，甚至于他們之前沒有畫過UML，但我們的狀態(tài)圖和領(lǐng)域模型都是出自他們之手。其實(shí)畫領(lǐng)域圖的關(guān)鍵是懂事物本身，并知道它們的關(guān)系。我們的領(lǐng)域圖與業(yè)務(wù)模型中的5大業(yè)務(wù)流程一一對應(yīng)，包括：預(yù)訂流程，訂單處理流程，產(chǎn)品供應(yīng)流程，財(cái)務(wù)結(jié)算流程，賬戶管理流程。微服務(wù)

我們的微服務(wù)JSOA V2.0是基于ServiceStack當(dāng)時(shí)最新的版本號4.0.50實(shí)現(xiàn)的，它本身支持輕量級協(xié)議和Metadata，以及Swagger，是微服務(wù)的一種架構(gòu)實(shí)現(xiàn)。另外，它還可以再擴(kuò)展以API Gateway的方式實(shí)現(xiàn)Open API。

微服務(wù)MSA與我們之前的SOA、ESB有什么區(qū)別呢？ ESB有總線和聰明的管道管理能力；

SOA弱化了中間的管道和總線，強(qiáng)化了兩端；

微服務(wù)MSA使用通用的輕量級協(xié)議和更加web化（RESTFUL）。?

?

?

3、應(yīng)用架構(gòu)改造

系統(tǒng)是什么？系統(tǒng)=元素+關(guān)系。應(yīng)用架構(gòu)是什么？應(yīng)用架構(gòu)=應(yīng)用+架構(gòu)。應(yīng)用就是系統(tǒng)的最小單元，應(yīng)用分級和應(yīng)用編號則構(gòu)成了應(yīng)用關(guān)系即應(yīng)用的架構(gòu)，它有利于應(yīng)用的管理、交互和追蹤。應(yīng)用分為產(chǎn)品線，子系統(tǒng)和應(yīng)用3級，每一級編號為2位，如100206。應(yīng)用要從用戶的視角出發(fā)，先有用戶，然后有應(yīng)用功能，這樣才是以用戶為中心去構(gòu)建系統(tǒng)。

4、組織架構(gòu)微調(diào)

組織架構(gòu)沒有最佳實(shí)踐，只有適合于自已當(dāng)前的選擇，以下是組織架構(gòu)與技術(shù)架構(gòu)對齊方面的思考： 1.藝術(shù)與工程相關(guān)分離：UED； 2.軟件開發(fā)與硬件相分離：運(yùn)維； 3.技術(shù)研發(fā)與業(yè)務(wù)研發(fā)相分離：架構(gòu)部；

4.需求，實(shí)施，驗(yàn)收相分離：每業(yè)務(wù)線分產(chǎn)品組、開發(fā)組、測試組； 5.開發(fā)按業(yè)務(wù)職責(zé)相分離：預(yù)訂組、產(chǎn)品組、訂單組；

6.專業(yè)技術(shù)委員會制：測試、產(chǎn)品、開發(fā)、輪流主持，設(shè)委員長；

四、總結(jié)

1、過程總結(jié)

第一步總體規(guī)劃：手握地圖，明確路線； 第二步數(shù)據(jù)庫：建庫拆庫，去join去SP； 第三步中間件：按需構(gòu)建，先增加常用； 第四步服務(wù)：技改=工單，有業(yè)務(wù)價(jià)值輸出； 第五步應(yīng)用：拆應(yīng)用，建門戶Portal，重構(gòu)應(yīng)用；

第六步組織架構(gòu)微調(diào)：組架技術(shù)與組織架構(gòu)對齊，技改之后調(diào)整； 第七步固化：框架化，自動化，管理過程工具化如DevOps。

2、經(jīng)驗(yàn)感悟

? 從服務(wù)入手是錯(cuò)的，從數(shù)據(jù)庫或中間件入手是正確的。服務(wù)屬于高級階段，方便行為的重用，是深層次優(yōu)化，但太慢了；

從當(dāng)前問題或故障入手，要先滅火，逆向分析dump工具很重要； 歷史要尊重，早期不可做大的改動，不能過多地影響現(xiàn)有業(yè)務(wù)。建議只做加法，建新庫和新中間件，這樣就不會有太多阻力和負(fù)擔(dān)；

一般不能全部重建，除非系統(tǒng)較小，系統(tǒng)規(guī)模大時(shí)只能拆分后分步重構(gòu)； 技術(shù)并不是技改過程中最復(fù)雜的，人和事及關(guān)系才是麻煩的部分，歷史問題的后面是人；

每次環(huán)境和問題都不一樣，要有準(zhǔn)備脫一層皮的心態(tài)。

3、通盤無妙招

技改是大折騰，于公司于個(gè)人而言都是，小改怡情，大改傷身，我們應(yīng)該避免大的技術(shù)改造，但此現(xiàn)象又比較常見，特別是業(yè)務(wù)發(fā)展快的創(chuàng)業(yè)公司。?

?

?

?

? 所以真正高手下棋，應(yīng)該是通盤無妙招，讓正確的事情很容易發(fā)生，基于自然的演化來實(shí)現(xiàn)技術(shù)的演進(jìn)。

怎樣才能通盤無妙招，系統(tǒng)良性長久的發(fā)展？我們需要兩個(gè)力量，一個(gè)是技術(shù)，一個(gè)是業(yè)務(wù)，如果只重視業(yè)務(wù)，而很容易在技術(shù)上積勞成疾，如果完全技術(shù)驅(qū)動，則又容易忘記業(yè)務(wù)目標(biāo)。所以它們應(yīng)該相伴相生，共同發(fā)展，在大的技術(shù)改造實(shí)施之后，在框架和流程相對固化后，小的技術(shù)重構(gòu)項(xiàng)目應(yīng)該長期存在，這樣才能良性循環(huán)，讓系統(tǒng)進(jìn)入自然演進(jìn)的狀態(tài)。

互動問答

問題：請問張老師如果再來一次技改你會怎么做？在你做過的技改過程中你覺得你最大的收獲是什么？覺得做的不好的又是什么？

這個(gè)問題非常好，為了更好回答您的問題，我簡單介紹一下本人的3次技改經(jīng)歷。我的第1次技改是重建，項(xiàng)目從10月份到第二年8月，歷史10個(gè)月，可以說是技術(shù)成功項(xiàng)目失敗。第2次技改是重構(gòu)，只管技術(shù)，少管人和業(yè)務(wù)，整體效果好，可以歸結(jié)為成功。第3次技改還是重構(gòu)，既管技術(shù)又管人，且業(yè)務(wù)處于高速發(fā)展期，資源少，可以總結(jié)為技術(shù)與業(yè)務(wù)相伴相生，技術(shù)效果一般。

如果以后還有機(jī)會，自已就不再直接負(fù)責(zé)了，實(shí)在是太累，從內(nèi)外各招幾個(gè)架構(gòu)師，并按上面的工作流程和方式，然后把握好技術(shù)與業(yè)務(wù)的關(guān)系和資源占用即可?；氐骄唧w問題：

如果再來一次，我會多參考第2次技改經(jīng)驗(yàn)，即PPT分享的過程總結(jié)； 技改后的收獲是脫胎換骨，技術(shù)和管理都有很大提升； ? ? ? 不好的地方：要更多的關(guān)注業(yè)務(wù)，以及平衡好業(yè)務(wù)與技術(shù)的關(guān)系。問題：單塊應(yīng)用向微服務(wù)遷移時(shí)，平滑過渡有什么技巧？如何解決分布式事務(wù)一致性呢？還有關(guān)于微服務(wù)持續(xù)交付、測試、監(jiān)控（語義監(jiān)控）方面有落地工具嗎？

1.平滑過渡的技術(shù)：直面當(dāng)前系統(tǒng)的問題，不斷有價(jià)值輸出，然后參考上面的過程總結(jié)，先規(guī)劃，然后中間件和數(shù)據(jù)庫，最后是服務(wù)和應(yīng)用； 2.分布式事務(wù)一致性：使用替代方案，如最終一致； 3.落地工具：MSA與SOA的治理沒有本質(zhì)差別，還是DevOps/Trace/Metrics/，我們使用的是ServiceStack/JMetrics/CenterLog/Jenkins/。

問題：如果舊有模塊關(guān)聯(lián)復(fù)雜，又影響現(xiàn)有系統(tǒng)性能，相關(guān)開發(fā)人員流失，不好梳理，改造有風(fēng)險(xiǎn)，重寫老板不答應(yīng)，該如何取舍呢?

? 舊有模塊關(guān)聯(lián)復(fù)雜，又影響現(xiàn)有系統(tǒng)性能：先滅火解決當(dāng)前故障, 逆向分析dump工具；

相關(guān)開發(fā)人員流失：引進(jìn)中件間，建立分享機(jī)制和學(xué)習(xí)型團(tuán)隊(duì)，講技改總體規(guī)劃，讓每個(gè)人了解自已的價(jià)值和目標(biāo)；

不好梳理，改造有風(fēng)險(xiǎn)：內(nèi)招幾個(gè)老員工成為應(yīng)用架構(gòu)師；

重寫老板不答應(yīng)：有業(yè)務(wù)價(jià)值輸入，技改==工單或項(xiàng)目，借助業(yè)務(wù)項(xiàng)目來實(shí)現(xiàn)技改。

嘉賓介紹 ?

?

? 張輝清，中青易游CTO，曾先后就職于廣之旅、攜程商旅架構(gòu)、古大集團(tuán)，在古大集團(tuán)主導(dǎo)了從單塊應(yīng)用到微服務(wù)的技術(shù)改造，任首席架構(gòu)師和高級技術(shù)總監(jiān)，目前就職于中青實(shí)業(yè)下屬公司中青易游，任職CTO。國家系統(tǒng)分析師和高級項(xiàng)目管理師，12年的互聯(lián)網(wǎng)分布式系統(tǒng)研發(fā)和架構(gòu)經(jīng)驗(yàn)，10年的OTA旅游行業(yè)經(jīng)歷，是一枚技術(shù)愛好者和旅游愛好者。

你可以在這里找到作者

張輝清將在InfoQ組織的CNUTCon全球容器技術(shù)大會上詳細(xì)剖析整個(gè)技改之路上的幾個(gè)關(guān)鍵點(diǎn)，如果你的公司也在考慮從單體應(yīng)用向微服務(wù)遷移，那一定不要錯(cuò)過。下面是CNUTCon微服務(wù)專題的介紹。

容器與微服務(wù)架構(gòu)是近幾年來開發(fā)者社區(qū)的技術(shù)熱點(diǎn)，在與容器結(jié)合使用后，微服務(wù)架構(gòu)的優(yōu)點(diǎn)得到了進(jìn)一步的放大。有很多的文章都在討論微服務(wù)和單體式架構(gòu)的區(qū)別，到現(xiàn)在，整個(gè)社區(qū)也開始理性起來，單體式架構(gòu)和微服務(wù)架構(gòu)并非相互替代的關(guān)系，單體式的架構(gòu)更適合輕量級的簡單應(yīng)用，微服務(wù)架構(gòu)相對復(fù)雜，對比起來，并不容易落地。

本專題不談概念，只講實(shí)踐。比如企業(yè)如何使用Spring Boot框架構(gòu)建微服務(wù)應(yīng)用，從SOA轉(zhuǎn)型微服務(wù)，有哪些難點(diǎn)和痛點(diǎn)，在此之前應(yīng)該做好哪些準(zhǔn)備等。簡單來說，在內(nèi)容策劃上，微服務(wù)專題希望能和參會者分享微服務(wù)架構(gòu)應(yīng)該如何落地，更加偏重案例分享。點(diǎn)擊閱讀原文，了解詳情。

第二篇：《從單體應(yīng)用到微服務(wù)》讀后感

《從單體應(yīng)用到微服務(wù)》讀后感

目標(biāo)：共同學(xué)習(xí)、共同進(jìn)步、告別碼農(nóng)，成為受人敬仰的、有態(tài)度的程序猿。拒絕不知其所以然的復(fù)制粘貼、拒絕人云亦云。用最嚴(yán)謹(jǐn)?shù)膽B(tài)度、最專業(yè)的方法、最可靠的知識來源，探究技術(shù)內(nèi)幕，死磕到底??！

內(nèi)容簡介

原書名字是《Monolith To Microservices》，是大神Sam Newman的新書，目前還沒有中文版本。原本是想寫一個(gè)簡短的讀后感的，但是寫著寫著，發(fā)現(xiàn)書中的內(nèi)容真的是太經(jīng)典了，淺嘗輒止的描述完全不能體現(xiàn)本書的價(jià)值。于是就改成了用我自己的語言對書中每一章的內(nèi)容進(jìn)行了精煉。因此這個(gè)讀后感也可以作為原書的精簡版來看，只不過用的是我自己的語言總結(jié)的。也是由于這個(gè)原因，這篇文章越寫字?jǐn)?shù)越多，最后接近三萬字，花費(fèi)的時(shí)間也很多。為了便于閱讀，分成4部分來發(fā)。

注：本文中的圖片截自原書

第一章、微服務(wù)介紹

什么是微服務(wù)應(yīng)用?

微服務(wù)是圍繞一個(gè)業(yè)務(wù)領(lǐng)域建模的可獨(dú)立部署的服務(wù)。通過網(wǎng)絡(luò)彼此交互。微服務(wù)是一種SOA架構(gòu)，并且它是技術(shù)不可知論的，即：微服務(wù)并不要求使用特定的技術(shù)。這點(diǎn)需要重點(diǎn)強(qiáng)強(qiáng)調(diào)下，因?yàn)楹芏嗳瞬捎梦⒎?wù)都是技術(shù)驅(qū)動的，這種認(rèn)識不是非常合適。微服務(wù)通過網(wǎng)絡(luò)端點(diǎn)互相訪問，這讓微服務(wù)具有分布式系統(tǒng)的特點(diǎn)。下面羅列一些微服務(wù)的核心思想：

獨(dú)立可部署性

這本書認(rèn)為微服務(wù)最重要的特性就是獨(dú)立可部署性。這要求微服務(wù)在部署自身的時(shí)候，不依賴任何其它服務(wù)。為了保證獨(dú)立可部署性，因此需要服務(wù)之間松耦合、服務(wù)之間使用穩(wěn)定的協(xié)議交互數(shù)據(jù)。

圍繞一個(gè)業(yè)務(wù)領(lǐng)域建模

傳統(tǒng)的單體應(yīng)用中，我們最常用的架構(gòu)是分層架構(gòu)，如將系統(tǒng)分為展示層、業(yè)務(wù)層和數(shù)據(jù)層。根據(jù)康威定律：任何設(shè)計(jì)系統(tǒng)的組織，都會產(chǎn)生這樣一個(gè)設(shè)計(jì)，即該設(shè)計(jì)的結(jié)構(gòu)與該組織的溝通結(jié)構(gòu)相一致。因此在分層架構(gòu)中，不同技術(shù)角色的人員被分配在一起工作，如前端組、后端組和DBA組等。這是一種以技術(shù)視角設(shè)計(jì)的架構(gòu)。在微服務(wù)中，則是圍繞業(yè)務(wù)領(lǐng)域的，將一個(gè)大的業(yè)務(wù)領(lǐng)域劃分成若干盡可能獨(dú)立的子域，每個(gè)子域自己可以是分層架構(gòu)的。根據(jù)康威逆定律，這樣的架構(gòu)勢必也會影響到組織的溝通方式的變化。

擁有自己數(shù)據(jù)的所有權(quán)

微服務(wù)的核心思想之一是不使用共享的數(shù)據(jù)庫，每個(gè)服務(wù)唯一的擁有自身數(shù)據(jù)的控制權(quán)。這可以讓服務(wù)決定公開哪些數(shù)據(jù)和隱藏哪些數(shù)據(jù)。這進(jìn)一步要求了微服務(wù)之間需要維護(hù)穩(wěn)定的接口協(xié)議。對數(shù)據(jù)的控制會促進(jìn)服務(wù)做到高內(nèi)聚，而通過隱藏自身數(shù)據(jù)又可以促進(jìn)服務(wù)間的松耦合。

微服務(wù)帶來的優(yōu)勢

微服務(wù)帶來的優(yōu)勢很多。天生的可獨(dú)立部署性可以促進(jìn)系統(tǒng)的伸縮性和魯棒性，并且可以混合使用多種技術(shù)。通過服務(wù)和團(tuán)隊(duì)的劃分，每個(gè)服務(wù)都是獨(dú)立演進(jìn)的，也就是說，所有的服務(wù)都可以并行開發(fā)，服務(wù)的開發(fā)團(tuán)隊(duì)也將專注于一個(gè)特定的業(yè)務(wù)領(lǐng)域，不受其它業(yè)務(wù)領(lǐng)域的影響。

雖然微服務(wù)帶來了很多優(yōu)勢，但是這并不代表可以免費(fèi)的使用微服務(wù)。另一方面，微服務(wù)的優(yōu)勢中，針對某個(gè)方面可能還有其它替代方面，而并非只能使用微服務(wù)來獲得。因此在應(yīng)用微服務(wù)架構(gòu)時(shí)，非常重要的一點(diǎn)是需要明確自身想從微服務(wù)中獲得哪些好處。

微服務(wù)帶來的問題

計(jì)算機(jī)的價(jià)格越來越低，這讓SOA架構(gòu)廣泛的被應(yīng)用。使用SOA可以將系統(tǒng)分布在多臺計(jì)算機(jī)上。但這帶來的挑戰(zhàn)是服務(wù)之間的網(wǎng)絡(luò)通信問題。網(wǎng)絡(luò)連接是不穩(wěn)定的，尤其是考慮延遲的時(shí)候，延遲會讓整個(gè)系統(tǒng)變得不可預(yù)測，除此之外，還需要額外處理網(wǎng)絡(luò)錯(cuò)誤的情況。分布式的部署結(jié)構(gòu)會讓一切變得復(fù)雜起來。某種意義上說，單體應(yīng)用也存在一些分布式的場景，例如：數(shù)據(jù)庫在一臺服務(wù)器上，另一臺服務(wù)器上的程序從數(shù)據(jù)庫服務(wù)器讀取數(shù)據(jù)，而客戶端使用一臺電腦訪問程序獲取數(shù)據(jù)。在這個(gè)場景中已經(jīng)出現(xiàn)了3臺電腦間的網(wǎng)絡(luò)通信。單體應(yīng)用和微服務(wù)在分布式上的差別主要在分布的程度上，微服務(wù)會使用更多的主機(jī)、更多的網(wǎng)絡(luò)通信。開始的時(shí)候，微服務(wù)的規(guī)模較小，問題可能看起來并不十分嚴(yán)重，但隨著微服務(wù)規(guī)模的逐漸增多，出現(xiàn)問題的頻率和難度也會逐步上升。為了解決微服務(wù)帶來的分布式問題，將會花費(fèi)很多的真金白銀。這也是在打算使用微服務(wù)架構(gòu)時(shí)需要考慮的一點(diǎn)：是否值得?

用戶界面

使用微服務(wù)架構(gòu)的一個(gè)誤區(qū)是只對服務(wù)端程序進(jìn)行微服務(wù)架構(gòu)，而依然采用單體應(yīng)用來作為展示層提供UI訪問。單體的展示層使得從用戶視角來看，服務(wù)無法獨(dú)立的發(fā)布，這是不正確的。根據(jù)上面圍繞業(yè)務(wù)領(lǐng)域建模中講述的，每個(gè)微服務(wù)都應(yīng)該負(fù)責(zé)自身業(yè)務(wù)領(lǐng)域的所有分層，包括：UI層、業(yè)務(wù)層和數(shù)據(jù)層。因此在用戶界面上也應(yīng)和微服務(wù)的拆分保持一致。這可能需要一些專門的技術(shù)來實(shí)現(xiàn)，如：微前端。

技術(shù)

微服務(wù)是一個(gè)技術(shù)不可知論的架構(gòu)，因此，如何實(shí)現(xiàn)微服務(wù)并沒有技術(shù)上的要求。只要服務(wù)間基于網(wǎng)絡(luò)可以互相通信就可以了，不必使用K8S、Docker、公有云等也可以實(shí)現(xiàn)微服務(wù)。在編程語言上也可以使用任何一種語言進(jìn)行實(shí)現(xiàn)。但是微服務(wù)是非常復(fù)雜的，主要是因?yàn)樗鼛淼姆植际絾栴}，這些問題可能是之前使用單體應(yīng)用從來沒遇到過的問題。因此，不應(yīng)盲目的跟風(fēng)新技術(shù)，應(yīng)該使用自己最熟悉的技術(shù)來實(shí)現(xiàn)微服務(wù)應(yīng)用。

大小

微服務(wù)應(yīng)該有多大，這應(yīng)該是最常被討論的問題。要解答這個(gè)問題，首先需要定義大小的衡量標(biāo)準(zhǔn)。常用的衡量標(biāo)準(zhǔn)如代碼行數(shù)，但這在微服務(wù)中是沒有意義的，因?yàn)槲⒎?wù)是技術(shù)不可知論的，而使用不同的編程語言實(shí)現(xiàn)同樣的邏輯，代碼行數(shù)差別是非常大的。書中引述了一位微服務(wù)專家對微服務(wù)大小的建議是：“盡可能小的接口”。實(shí)際上，微服務(wù)的大小在不同的上下文和人群中的感受是不一樣的，因此不必過于糾結(jié)微服務(wù)大小的問題。在考慮大小的時(shí)候，最應(yīng)該考慮的是以下兩個(gè)問題：1）你可以處理多少個(gè)服務(wù)。隨著服務(wù)的增多，系統(tǒng)也會變得更加復(fù)雜，需要團(tuán)隊(duì)學(xué)習(xí)更多的知識來應(yīng)對；2）服務(wù)的邊界如何定義。不合適的邊界劃分最終可能會導(dǎo)致恐怖的耦合混亂。

所有權(quán)

傳統(tǒng)的IT企業(yè)采用職能型的組織架構(gòu)，軟件的生命周期分別由不同的部門負(fù)責(zé)，如需求部門負(fù)責(zé)采集用戶需求，開發(fā)部門收到需求部門輸出的需求文檔后進(jìn)行軟件開發(fā)。這種方式如下圖所示：

圖片

現(xiàn)在越來越多的企業(yè)將組織方式調(diào)整為矩陣型，提高溝通效率，加快開發(fā)速度。而微服務(wù)架構(gòu)是圍繞業(yè)務(wù)領(lǐng)域建模的，這非常適合矩陣型組織的溝通方式。組織可以使用微服務(wù)所代表的業(yè)務(wù)領(lǐng)域?qū)M織進(jìn)行劃分，根據(jù)微服務(wù)的特性，團(tuán)隊(duì)之間也會減少跨團(tuán)隊(duì)的共享、最小化發(fā)布時(shí)的競爭。如下圖所示：

單體應(yīng)用

什么是單體應(yīng)用呢?單體應(yīng)用的特征是系統(tǒng)的所有功能共同組成一個(gè)唯一的部署單元。通常單體應(yīng)用分為三類：

單進(jìn)程單體應(yīng)用

模塊化的單體應(yīng)用

分布式的單體應(yīng)用：分布式的單體應(yīng)用由多個(gè)服務(wù)組成，但是這些服務(wù)必須同時(shí)部署。這種方式擁有分布式系統(tǒng)和單體系統(tǒng)的所有缺點(diǎn)，并且對于單純的分布式系統(tǒng)和單體系統(tǒng)而言沒有任何優(yōu)勢。所有的服務(wù)都混亂的耦合在一起。一個(gè)服務(wù)的變更就可能導(dǎo)致系統(tǒng)不可用。

第三方黑盒系統(tǒng)：我們可以將第三方的系統(tǒng)都視為單體應(yīng)用。

單體系統(tǒng)的挑戰(zhàn)

單體應(yīng)用由于實(shí)現(xiàn)和部署耦合，更加的脆弱。如果有很多人在一起工作，可能會引發(fā)混亂。一些開發(fā)人員可能同時(shí)修改同一段代碼，團(tuán)隊(duì)之間的工作互相依賴。微服務(wù)提供的概念邊界會更加容易地解決這些問題。

單體系統(tǒng)的優(yōu)勢

單體應(yīng)用的部署拓?fù)浔确植际较到y(tǒng)簡單的多，這樣會讓開發(fā)流程更加簡單；并且在監(jiān)控、排錯(cuò)和系統(tǒng)測試方面也要簡單許多；單體系統(tǒng)內(nèi)部的代碼可以更簡單的復(fù)用，這在微服務(wù)中，可能意味著代碼拷貝或者共享代碼等權(quán)衡。很多人將單體系統(tǒng)視作老土的架構(gòu)，視為應(yīng)該被拋棄的架構(gòu)，這是絕對是不正確的觀點(diǎn)。

內(nèi)聚和耦合內(nèi)聚的目的是將相關(guān)的代碼放在一起，一起應(yīng)對變更；而耦合則表示對一個(gè)部分的修改會對其它部分造成影響。高內(nèi)聚、低耦合會讓架構(gòu)保持穩(wěn)定。單體應(yīng)用通常是高耦合、低內(nèi)聚的，各種不相關(guān)的代碼都耦合在一起。當(dāng)需要代碼調(diào)整的時(shí)候，通常很困難。同時(shí)，松耦合在單體應(yīng)用中實(shí)際并不存在，因?yàn)槿魏巫儎佣夹枰獙⒄麄€(gè)應(yīng)用一起打包部署。在微服務(wù)中，如果要想做的松耦合，一方面是保證自身的修改不需要改變其它部分，另一方面是保證接口的穩(wěn)定。

我們需要謹(jǐn)慎的考慮系統(tǒng)中的耦合，耦合可分為以下4類：

實(shí)現(xiàn)耦合：這是一種危害最大的耦合類型，但通常比較容易處理。例如A服務(wù)的實(shí)現(xiàn)依賴于B服務(wù)如何實(shí)現(xiàn)，當(dāng)B服務(wù)需要修改時(shí)，A服務(wù)需要同時(shí)修改。典型的例子是共享數(shù)據(jù)庫，當(dāng)A和B共享同一個(gè)數(shù)據(jù)庫時(shí)，A對數(shù)據(jù)庫的變更會直接影響B(tài)。

臨時(shí)耦合：這種耦合發(fā)生在運(yùn)行時(shí)，一般發(fā)生在分布式環(huán)境中的同步調(diào)用時(shí)。例如A服務(wù)要同步地調(diào)用B服務(wù)獲取信息，而B服務(wù)此時(shí)又需要同步地調(diào)用C服務(wù)，這就構(gòu)成一個(gè)臨時(shí)耦合。這里問題是，請求若要成功，這三個(gè)服務(wù)必須都正常運(yùn)行并且可以相互調(diào)用。解決時(shí)可以考慮使用緩存或者異步消息。

部署耦合：不管代碼是不是模塊化的，如果在發(fā)布的時(shí)候需要打成一個(gè)包統(tǒng)一部署，這時(shí)就是部署耦合。部署耦合帶來的問題一方面是需要協(xié)調(diào)各個(gè)團(tuán)隊(duì)的發(fā)布計(jì)劃，另一方面，每次部署都會有風(fēng)險(xiǎn)，越大的部署范圍風(fēng)險(xiǎn)也會越大。并且少量的代碼更容易實(shí)現(xiàn)自動發(fā)布。

領(lǐng)域耦合：每個(gè)微服務(wù)都處在一個(gè)領(lǐng)域限界上下文中，當(dāng)它們之間的概念有交互時(shí)，就形成了領(lǐng)域耦合。例如服務(wù)A中需要理解服務(wù)B中的一個(gè)領(lǐng)域概念。實(shí)際上，服務(wù)A中所需要的概念可能與服務(wù)B中的不一樣，例如倉庫服務(wù)需要訪問訂單服務(wù)中的訂單信息，實(shí)際上倉庫服務(wù)需要的訂單信息可能只是訂單編號，它不需要理解訂單服務(wù)中訂單信息的全部業(yè)務(wù)概念。因此，倉庫服務(wù)應(yīng)該維護(hù)一個(gè)在自己限界上下文內(nèi)的訂單信息實(shí)體。

領(lǐng)域驅(qū)動設(shè)計(jì)

前面介紹了我們?yōu)槭裁匆獓@業(yè)務(wù)領(lǐng)域建模。那么具體如何做呢?這就是領(lǐng)域驅(qū)動設(shè)計(jì)（DDD）解決的問題。DDD介紹了一系列的思想來在程序中表示問題域。設(shè)計(jì)微服務(wù)的重要概念有：

聚合：聚合是一個(gè)自包含的單元，表達(dá)了一個(gè)實(shí)際的業(yè)務(wù)概念。通常聚合擁有一個(gè)生命周期，這會讓聚合的實(shí)現(xiàn)類似一個(gè)狀態(tài)機(jī)。我們需要保證一個(gè)業(yè)務(wù)概念的狀態(tài)轉(zhuǎn)移完全被包含在一個(gè)聚合之中。一個(gè)微服務(wù)會處理一個(gè)或多個(gè)聚合的生命周期和數(shù)據(jù)存儲。將一個(gè)系統(tǒng)劃分成聚合可能需要考慮眾多因素，例如：性能問題、實(shí)現(xiàn)的難易程度等。這也意味著聚合可能會對聚合進(jìn)行重新劃分。在實(shí)際中，事件風(fēng)暴非常有用。

限界上下文：限界上下文通常代表了組織中的一個(gè)較大范圍的邊界。這個(gè)邊界內(nèi)有單一的職責(zé)。從實(shí)現(xiàn)角度來看，一個(gè)限界上下文中有一個(gè)或多個(gè)聚合。這些聚合中的一些可能會對外暴露，另一些則被內(nèi)部隱藏。

將聚合和限界上下文映射成服務(wù)

聚合和限界上下文都提供了高內(nèi)聚的單元，并且提供設(shè)計(jì)良好的接口。聚合涉及一個(gè)單一領(lǐng)域概念的自包含狀態(tài)機(jī)，而限界上下文則代表一組相關(guān)的聚合。聚合和限界上下文都可以作為微服務(wù)的邊界?？紤]到初期盡量減少服務(wù)的數(shù)量，建議使用范圍更大的限界上下文來作為微服務(wù)邊界，熟悉后，可以進(jìn)一步使用聚合拆分。

第二章、規(guī)劃遷移

是否應(yīng)該使用微服務(wù)?

微服務(wù)不應(yīng)作為一個(gè)目標(biāo)，使用微服務(wù)也不會讓你獲得勝利。采用微服務(wù)的決定一定是經(jīng)過深思熟慮的。從單體應(yīng)用遷移到微服務(wù)應(yīng)用應(yīng)該有充分的理由，例如獲得當(dāng)前單體應(yīng)用不具備的能力。在考慮想微服務(wù)架構(gòu)遷移之前，需要明確三個(gè)問題：

你希望從微服務(wù)中獲得什么?

除了微服務(wù)，還有什么其它的解決方案?

你怎么衡量微服務(wù)帶來的成效?

微服務(wù)不是免費(fèi)的，它可能會引起組織系統(tǒng)性的變化，需要引入更多的運(yùn)維組件，改變現(xiàn)有的開發(fā)方式等等。因此需要充分考慮ROI，以判斷一個(gè)遷移是否值得。

微服務(wù)帶來的好處主要有以下幾點(diǎn)，但請注意，帶來的這些好處大部分都可以通過其它方式獲得。

提升團(tuán)隊(duì)自治性

非常多的企業(yè)證明了團(tuán)隊(duì)自治帶來的好處。自治的團(tuán)隊(duì)通常不會很大，確保團(tuán)隊(duì)內(nèi)成員彼此都非常熟悉，自治團(tuán)隊(duì)在一個(gè)較小的范圍內(nèi)工作。業(yè)界有一些關(guān)于團(tuán)隊(duì)規(guī)模的范例，如亞馬遜的“兩個(gè)披薩”模型。如果正確使用團(tuán)隊(duì)自治性，會激發(fā)團(tuán)隊(duì)成員成長并提升效率。當(dāng)團(tuán)隊(duì)擁有微服務(wù)的全部控制權(quán)，就會提升團(tuán)隊(duì)在整個(gè)組織中的自治性。

自治性不是微服務(wù)獨(dú)有的，有很多方式可以獲得自治。團(tuán)隊(duì)的自治主要涉及分配給團(tuán)隊(duì)的職責(zé)，而與使用什么樣的架構(gòu)關(guān)系不大。比如可以通過將代碼倉庫中的一部分授權(quán)給一個(gè)團(tuán)隊(duì)來促進(jìn)團(tuán)隊(duì)的自治。

加快上市時(shí)間

將變更的執(zhí)行和部署聚焦到各自獨(dú)立的微服務(wù)中，可以做到不用和其它服務(wù)協(xié)調(diào)發(fā)布時(shí)間，同時(shí)多個(gè)團(tuán)隊(duì)可以并行的處理待辦任務(wù)列表，這讓功能面世的時(shí)間大幅度加快。

當(dāng)然，不使用微服務(wù)也可以做到加快上市時(shí)間。如“優(yōu)化上線流程”等也會起到一定的效果。通過對現(xiàn)有上線流程的分析，判斷是否可以通過調(diào)整任務(wù)執(zhí)行的順序，或者采用并行的方式來加快流程執(zhí)行的速度。

為負(fù)載更有效的擴(kuò)縮

每個(gè)微服務(wù)都可以獨(dú)立的進(jìn)行擴(kuò)縮，這樣會更加有效。因?yàn)槲覀冎恍枰獢U(kuò)展對處理當(dāng)前復(fù)雜有瓶頸的部分。當(dāng)負(fù)載降低，可以對這部分再進(jìn)行縮容。

如果不使用微服務(wù)，有很多方法可以應(yīng)對負(fù)載升高的情況。最簡單的就是使用配置更高的機(jī)器。另外，傳統(tǒng)的通過多個(gè)單體應(yīng)用的拷貝來進(jìn)行水平擴(kuò)展的方案也是非常有效的，雖然它對于數(shù)據(jù)庫的瓶頸沒有幫助。

提升魯棒性

例如多租戶的SaaS系統(tǒng)，這類系統(tǒng)對可用性的要求很高，一旦出現(xiàn)宕機(jī)，影響范圍將會非常廣泛。通過使用微服務(wù)，將一個(gè)系統(tǒng)根據(jù)功能解耦成若干個(gè)獨(dú)立的服務(wù)，也就是說，當(dāng)一個(gè)功能出現(xiàn)問題時(shí)，不會影響其它服務(wù)的功能。這里需要注意的是，微服務(wù)提供的魯棒性不是免費(fèi)的，并且由于服務(wù)部署在不同的機(jī)器上，這也會增加調(diào)用失敗的風(fēng)險(xiǎn)。

如果不使用微服務(wù)，通過拷貝多個(gè)單體應(yīng)用進(jìn)行負(fù)載均衡也可以有效的提升系統(tǒng)的魯棒性。另一方面，系統(tǒng)的不穩(wěn)定通常都是人為的，如果系統(tǒng)存在很多人工的操作，則使用自動化的手段在很大程度上解決問題。

擴(kuò)展開發(fā)人員的數(shù)量

《人月神話》中提到，只有將工作分割成互不影響的小塊，才能夠通過增加人數(shù)來加快發(fā)布進(jìn)度。微服務(wù)通過明確的邊界，限制了其自身的范圍和對其它服務(wù)的依賴。因此可以支持大量的開發(fā)人員。僅僅使用微服務(wù)通常是不夠的，還需要結(jié)合團(tuán)隊(duì)自治和服務(wù)所有權(quán)。

另一種不使用微服務(wù)的方法是實(shí)現(xiàn)模塊化的單體應(yīng)用，不同的團(tuán)隊(duì)擁有單體中的不同模塊。只要它們對外暴露的接口是穩(wěn)定的，那么就可以獨(dú)自的演化。

擁抱新技術(shù)

單體應(yīng)用限制了新技術(shù)的使用，因?yàn)橥ǔＫ皇褂靡环N開發(fā)語言，使用特定的部署平臺、運(yùn)維系統(tǒng)和一種數(shù)據(jù)庫。而微服務(wù)中的每一個(gè)獨(dú)立的服務(wù)都可以根據(jù)自身的特點(diǎn)進(jìn)行技術(shù)選型。成熟的微服務(wù)組織通常會限制可使用的技術(shù)棧。

在這一點(diǎn)上，單體應(yīng)用沒有太好的辦法。

什么時(shí)候不應(yīng)該使用微服務(wù)?

在一些場景中是不適合使用微服務(wù)的，如下：

不了解的領(lǐng)域：服務(wù)邊界如果劃分有誤，則帶來的代價(jià)可能是非常高昂的，可能會導(dǎo)致服務(wù)間的高度耦合，則要比單體應(yīng)用更加糟糕。如果對業(yè)務(wù)領(lǐng)域尚不了解，不應(yīng)盲目的進(jìn)行服務(wù)拆分，而是應(yīng)該先學(xué)習(xí)領(lǐng)域知識。

初創(chuàng)系統(tǒng)：很多企業(yè)在系統(tǒng)初始階段就會考慮使用微服務(wù)架構(gòu)，但在實(shí)際實(shí)現(xiàn)時(shí)，都會先采用單體應(yīng)用。微服務(wù)對于擴(kuò)張來說是一個(gè)很好的選擇，但在初始階段，功能尚處于試驗(yàn)階段，會根據(jù)用戶的需求不斷調(diào)整。一些功能可能會重寫，另一些功能可能會刪掉。另一方面，初始階段的資金有限，應(yīng)該將關(guān)注點(diǎn)放在產(chǎn)品本身上，單體應(yīng)用易于開發(fā)和測試，部署拓?fù)湟卜浅：唵?，相比微服?wù)不需要花費(fèi)太多的資源和精力。通常來說，一個(gè)已經(jīng)存在的“棕域”系統(tǒng)相比一個(gè)新的“綠域”系統(tǒng)來說，更加容易拆分。

客戶自己安裝和管理的軟件：如果軟件打包后分發(fā)給客戶自行安裝和管理，那么不應(yīng)該使用微服務(wù)。因?yàn)槲⒎?wù)的安裝和運(yùn)維非常復(fù)雜，客戶可能沒有安裝和管理微服務(wù)架構(gòu)應(yīng)用的能力。

沒有充分理由的情況下：這個(gè)前面也提到過，微服務(wù)作為一個(gè)分布式系統(tǒng)，使用起來將會面臨非常多的挑戰(zhàn)，因此，一定是在經(jīng)過深思熟慮后，確定微服務(wù)帶來的優(yōu)點(diǎn)大于缺點(diǎn)時(shí)，才可以使用。

如何開始微服務(wù)?

要在組織中推廣微服務(wù)，首先要做的是讓其他人清楚的明白你希望從微服務(wù)中獲得什么，當(dāng)他們認(rèn)同之后，要做的就是探討如何實(shí)現(xiàn)。通常需要先引入一些成熟的模型來幫助組織變革。下面介紹John Kotter的“組織變革八步法”，整個(gè)過程如下圖所示：

創(chuàng)建變革的緊迫感：組織中的好主意有很多，微服務(wù)可能只是其中之一。因此需要讓大家明白現(xiàn)在就是實(shí)現(xiàn)微服務(wù)的最佳時(shí)機(jī)，要做到這點(diǎn)的最佳實(shí)踐是結(jié)合當(dāng)前組織中的實(shí)際場景，結(jié)合當(dāng)前的痛點(diǎn)，而不是干巴巴的說：“我們要使用微服務(wù)”，任何時(shí)候，微服務(wù)都不是目標(biāo)。

創(chuàng)建一個(gè)有足夠力量的引導(dǎo)聯(lián)盟：要推動一個(gè)變革，一個(gè)人是遠(yuǎn)遠(yuǎn)不夠的。需要在組織中分辨哪些人可以幫助你，這些人可能是同事、領(lǐng)導(dǎo)或者其它部門的相關(guān)方，讓這些人加入到你的隊(duì)伍中，讓他們成為推動變革的一份子。這可能涉及到包含IT崗位的任何崗位。

創(chuàng)建一個(gè)愿景和實(shí)現(xiàn)策略：愿景說明了你想從變更中獲得什么，而策略則說明了你將如何實(shí)現(xiàn)變革。策略可能會不斷調(diào)整，因此微服務(wù)不一定是唯一的方式。

推廣變革愿景：宏大的愿景看起來很棒，但是在推廣的時(shí)候沒人會相信。因此可以在開始的時(shí)候分享一個(gè)小的愿景。在推廣方式上，建議使用面對面的方式，其它方式可以結(jié)合使用。

賦予員工廣泛的行動權(quán)力：當(dāng)你完成了愿景的推廣，大家都滿懷激動的心情后，接下來會怎樣呢?大家可能繼續(xù)忙各自的工作。在使用微服務(wù)的時(shí)候圍繞已存在的基礎(chǔ)設(shè)施的流程可能是一個(gè)非常實(shí)際的問題。例如你需要發(fā)布一個(gè)新的服務(wù)，但是硬件采購的流程非常長。因此需要賦能員工，幫助他們掃清障礙，做他們該做的事情。

創(chuàng)建短期成效：如果實(shí)現(xiàn)的周期太長，人們可能會喪失對愿景的信心，因此需要將整個(gè)周期拆分成很多小的勝利。當(dāng)使用微服務(wù)對功能解耦后，這可能更加容易實(shí)現(xiàn)。

鞏固收益并產(chǎn)生更多變化：當(dāng)取得一些小勝利后，要趁熱打鐵。對流程和策略進(jìn)行繼續(xù)的優(yōu)化，尋找如何能夠驅(qū)動變革繼續(xù)進(jìn)行。例如在微服務(wù)拆分后，接下來可能意味著對數(shù)據(jù)庫的解耦。

將新方式融入文化：隨著變革的深入，以及不斷對成功或失敗經(jīng)驗(yàn)進(jìn)行分享，團(tuán)隊(duì)會越來越熟悉新的工作方式，最終會形成組織特有的文化沉淀下來。

逐步遷移的重要性

逐步的遷移有助于在過程中學(xué)習(xí)微服務(wù)，當(dāng)出現(xiàn)問題的時(shí)候，影響的范圍也是有限的。把遷移分為多個(gè)小步驟，也可以幫助分析每一步的成果，總結(jié)每一步的經(jīng)驗(yàn)教訓(xùn)。也有助于實(shí)現(xiàn)上文提到的快速的小勝利。當(dāng)確定使用微服務(wù)的時(shí)候，可以先挑選一到兩個(gè)業(yè)務(wù)領(lǐng)域，用微服務(wù)實(shí)現(xiàn)它們，并將它們發(fā)布到生產(chǎn)環(huán)境，然后觀察它工作的怎樣。這里列出一些逐步遷移的好處：

只有生產(chǎn)環(huán)境才算數(shù)：只有將拆分好的微服務(wù)發(fā)布到生產(chǎn)環(huán)境在表示這個(gè)服務(wù)實(shí)現(xiàn)完成。因?yàn)槲⒎?wù)解耦后會帶來很多問題，如：排錯(cuò)、調(diào)用鏈、延遲、級聯(lián)錯(cuò)誤等。很多問題只有在生產(chǎn)環(huán)境中才能發(fā)現(xiàn)。如果做錯(cuò)了，逐步遷移會使你能夠快速定位問題和回滾。

變更成本：在向微服務(wù)遷移時(shí)，會犯很多錯(cuò)誤，逐步遷移不會減少犯錯(cuò)誤的可能性，但是當(dāng)錯(cuò)誤發(fā)生，其造成的成本損失是可控的。

可逆和不可逆的決策：有些決策是不可逆的，這意味著一旦它開始執(zhí)行，就再也無法回到起點(diǎn)了。這類決策需要非常謹(jǐn)慎的評估，運(yùn)用方法論，長時(shí)間的論證。而另一類決策在執(zhí)行后，如果發(fā)現(xiàn)不合適，可以回到初始的地方重新來過，這類決策可以快速指定，并且可以授權(quán)給個(gè)人或者小的團(tuán)體。

更容易進(jìn)行實(shí)驗(yàn)：調(diào)整代碼的成本較低，有很多工具可以使用，但是調(diào)整數(shù)據(jù)庫的成本就會非常高。高成本的變更的風(fēng)險(xiǎn)也會是很高的，因此最好的辦法是進(jìn)行一些小的實(shí)驗(yàn)來觀察可能發(fā)生的問題，逐步遷移會讓這些實(shí)驗(yàn)的影響范圍是可控的。

領(lǐng)域驅(qū)動設(shè)計(jì)

接下來我們將討論如何進(jìn)行微服務(wù)的拆分，使用的思想是領(lǐng)域驅(qū)動設(shè)計(jì)。在使用領(lǐng)域驅(qū)動設(shè)計(jì)建立領(lǐng)域模型后，這個(gè)模型可以幫助我們定義服務(wù)邊界，以及引導(dǎo)我們分辨實(shí)現(xiàn)服務(wù)的優(yōu)先級。通過限界上下文之間的依賴關(guān)系，對其它限界上下文依賴越少的服務(wù)在實(shí)現(xiàn)的時(shí)候就會越容易，這些也是我們有限選擇實(shí)現(xiàn)的。實(shí)際上，有一些方法可以幫助我們決策，如下：

打算走多遠(yuǎn)?

開始的時(shí)候，一下子要對系統(tǒng)的整體領(lǐng)域模型都進(jìn)行分析，往往不知道如何入手，也會讓人心生畏懼。其實(shí)，在將單體應(yīng)用解耦的時(shí)候，只需要了解足夠的關(guān)于從什么地方開始解耦的信息就夠了。缺少全局的理解確實(shí)會帶來一些風(fēng)險(xiǎn)，但是開始的時(shí)候并不是非常重要，因?yàn)殚_始的時(shí)候只需要獲取如何進(jìn)行下一步的信息就可以了，在解耦過程中需要不斷結(jié)合新的領(lǐng)域只是對領(lǐng)域模型進(jìn)行重新定義。

事件風(fēng)暴

事件風(fēng)暴可以幫助技術(shù)相關(guān)方和非技術(shù)相關(guān)方共同定義一個(gè)共享的領(lǐng)域模型。事件風(fēng)暴是自下而上的，首先參與者一起定義領(lǐng)域事件——系統(tǒng)中真實(shí)發(fā)生的事件。然后用這些事件組成聚合，再將聚合組成限界上下文。事件風(fēng)暴的輸出不僅僅是領(lǐng)域模型，最終要的是對領(lǐng)域模型的一致性理解。因此需要相關(guān)方在一起工作，這是使用這個(gè)方法最大的挑戰(zhàn)。

使用模型排序優(yōu)先級

通過分析上下游服務(wù)的依賴關(guān)系，就可以明白哪些服務(wù)相對容易拆分，哪些會更加困難。這可以作為服務(wù)實(shí)現(xiàn)順序的排序因素。但需要注意的是，領(lǐng)域模型表達(dá)了系統(tǒng)的邏輯概念，雖然從邏輯上看沒有依賴，但可能在物理層面存在關(guān)系，因此仍然需要在進(jìn)一步的從實(shí)現(xiàn)代碼中分析是否存在依賴。另一個(gè)決定優(yōu)先級的因素是業(yè)務(wù)本身，因?yàn)槲覀冃枰獙?shí)現(xiàn)快速的成功，所以需要選擇能夠?qū)崿F(xiàn)這個(gè)目標(biāo)的恰當(dāng)?shù)臉I(yè)務(wù)。

模型分組

在實(shí)際選擇要實(shí)現(xiàn)的服務(wù)時(shí)，大部分人可能會選擇最容易解耦的部分，但我們的另一個(gè)關(guān)注點(diǎn)是取得快速的成功，這意味著我們應(yīng)該選擇能夠?yàn)橄到y(tǒng)帶來立竿見影效果的部分，而這些部分通常都是核心業(yè)務(wù)，可能并不容易拆分。這時(shí)我們可以按照難易程度和效果將候選服務(wù)進(jìn)行分組，如下圖所示：

X軸表示效果，越向右效果越明顯。Y軸表示實(shí)現(xiàn)的難度，越向上越容易。顯然，我們最終應(yīng)該選擇位于圖的右上方的候選服務(wù)。有時(shí)候我們在實(shí)現(xiàn)的時(shí)候會發(fā)現(xiàn)，原本以為簡單的服務(wù)實(shí)際實(shí)現(xiàn)起來很困難，反之亦然。這是很正常的，這也意味著需要重新對服務(wù)進(jìn)行排序后選擇新的服務(wù)進(jìn)行實(shí)現(xiàn)。

重新組織團(tuán)隊(duì)

使架構(gòu)和組織保持一致是充分發(fā)揮微服務(wù)架構(gòu)優(yōu)勢的關(guān)鍵，但這在組織中通常并不容易。下面提出一些對此有幫助的想法：

轉(zhuǎn)變結(jié)構(gòu)

傳統(tǒng)上，IT組織的結(jié)構(gòu)是圍繞核心能力的。例如Java開發(fā)人員在一起，測試人員在一起，DBA和其它DBA在一起。在開發(fā)系統(tǒng)的時(shí)候，每個(gè)只能團(tuán)隊(duì)中的人只完成系統(tǒng)生命周期中的一部分任務(wù)。這也導(dǎo)致過程中需要各個(gè)部門之間相互協(xié)調(diào)。在微服務(wù)的架構(gòu)中，每個(gè)服務(wù)涉及多個(gè)軟件層次，也會涉及多個(gè)職能。因此當(dāng)今的組織開始向DevOps轉(zhuǎn)變，測試人員不再是一個(gè)單獨(dú)的部門，而是作為發(fā)布團(tuán)隊(duì)中的一員，和開發(fā)團(tuán)隊(duì)更緊密的合作。通過將不同職能的人員放在一個(gè)發(fā)布團(tuán)隊(duì)中，授予他們足夠的權(quán)限，這可以促進(jìn)他們?yōu)榉?wù)的發(fā)布提供各種幫助。

沒有范式

組織方式?jīng)]有一個(gè)范式可以適合所有企業(yè)，它會收到企業(yè)環(huán)境、工作文化以及具體的人的影響。因此，盲目拷貝別的企業(yè)的組織方式是很危險(xiǎn)的。其它企業(yè)的成功經(jīng)驗(yàn)可以用來參考，但是要清楚它可能不會在你的場景中成功。

做出一個(gè)改變

如果你不能拷貝其它企業(yè)的組織結(jié)構(gòu)，那應(yīng)該怎么做呢?首先可以先羅列日常涉及的工作和流程，然后將它們和當(dāng)前企業(yè)的組織結(jié)構(gòu)映射起來。然后分析哪些職能需要跨越組織結(jié)構(gòu)來工作，結(jié)合愿景重新繪制一個(gè)理想的結(jié)構(gòu)圖。將兩個(gè)圖進(jìn)行對比，然后規(guī)劃遷移方案。

改變技能

從單體向微服務(wù)遷移，需要對組織中原有的能力進(jìn)行更新。一個(gè)有效的方法是，首先羅列出所有需要的能力，然后讓員工對自己進(jìn)行評價(jià)，評估自己當(dāng)前的能力。這里需要重點(diǎn)強(qiáng)調(diào)的是，自我評價(jià)是非公開的，只是用于他們的導(dǎo)師了解每個(gè)人的特點(diǎn)。然后根據(jù)員工的興趣愛好針對性的進(jìn)行培訓(xùn)。改變現(xiàn)有人員的技能只是一個(gè)方面，如果追求短期成效，可以在團(tuán)隊(duì)中增加擁有該技能的專業(yè)人員。

怎么衡量遷移是否成功?

如果沒有衡量成功的標(biāo)準(zhǔn)，那么遷移將永無止境。在向微服務(wù)遷移時(shí)，即便做好完全的準(zhǔn)備，也會犯錯(cuò)。那么怎么才能知道遷移工作起作用了呢?基于希望獲得的成效，應(yīng)該指定一些可追蹤的指標(biāo)來回答這個(gè)問題。然后設(shè)置一些檢查點(diǎn)，每到達(dá)一個(gè)檢查點(diǎn)，就檢視一下方向是否正確，使用指標(biāo)衡量是否起到預(yù)期的作用，并且分析是否應(yīng)該嘗試其它方式。下面是一些建議：

設(shè)置定期的檢查點(diǎn)

任何一個(gè)遷移，都需要設(shè)置定期的檢查點(diǎn)，在遷移過程中停下來看看是否正確實(shí)現(xiàn)。檢查點(diǎn)可以是正式的也可以是非正式的，內(nèi)容包括：1）重申希望從微服務(wù)中獲得什么；2）審查定量的指標(biāo)；3）接受定性的反饋——大家是否覺得做了正確的事情；4）確定今后的改進(jìn)方向。

定量衡量

定量的指標(biāo)可以直觀的反映出遷移的情況。例如：部署的次數(shù)、失敗率等。但是要注意數(shù)據(jù)的時(shí)效性，過期的數(shù)據(jù)可能會造成錯(cuò)誤的決策。一些指標(biāo)可能在短期內(nèi)沒有變化，甚至?xí)兊酶?，這更加需要逐步的實(shí)施遷移。

定性衡量

無論定量分析的數(shù)據(jù)如何，都應(yīng)該關(guān)注于當(dāng)事人的感受，他們是否享受這個(gè)過程是非常重要的。如果大家的感受是負(fù)面的，應(yīng)該立即做出調(diào)整。

避免沉沒成本謬誤

沉默成本謬誤發(fā)生在，當(dāng)人們?yōu)橹暗姆椒ㄍ度肓朔浅６嗪?，即使已?jīng)有證據(jù)顯示這個(gè)方法行不通，但因?yàn)橐呀?jīng)投入了很多，仍然繼續(xù)執(zhí)行。有時(shí)情況可能因?yàn)閳?jiān)持而最終得到改善，但另一些時(shí)候只是在浪費(fèi)資源。通常，下注越大，越難以回頭。這又是一個(gè)逐步遷移的好處。

開啟新的方式

在遷移的時(shí)候，有多種選項(xiàng)和路徑。對每一種方式而言，都不會完全平滑，因此可能會在使用一個(gè)方式后發(fā)現(xiàn)這種方式并不是最好的，然后更換另一個(gè)方式實(shí)現(xiàn)。建議嘗試將這種變化融入到文化之中，采用這種不斷進(jìn)取的文化，敢于嘗試新的東西，那么在需要更改方向的時(shí)候會變得更加自然。

總結(jié)

這一章介紹了為什么需要使用微服務(wù)架構(gòu)，以及哪些因素可以用來對實(shí)現(xiàn)順序進(jìn)行排序。當(dāng)企業(yè)在決策是否需要向微服務(wù)遷移時(shí)，需要回答三個(gè)問題：

希望從微服務(wù)中獲得什么?

是否考慮過微服務(wù)之外的其它替代方案?

怎么衡量遷移起到了成效?

遷移過程可能會花費(fèi)很長的時(shí)間，但實(shí)際工作中，客戶不會給我們這么多的時(shí)間。遷移只有在發(fā)布到生產(chǎn)環(huán)境后才能表示一個(gè)階段的結(jié)束。這就需要一系列的技術(shù)手段來讓微服務(wù)應(yīng)用和單體應(yīng)用協(xié)同工作。接下來的內(nèi)容就會對這些技術(shù)進(jìn)行介紹。