微服務(wù)近年來可謂炙手可熱，合理的使用微服務(wù)架構(gòu)可以解耦系統(tǒng)引有、提供更好的軟件伸縮性以及提高組織的敏捷性。然而現(xiàn)實中較少有項目一開始就會選擇使用微服務(wù)架構(gòu)，絕大多數(shù)新項目在最初都會務(wù)實地從更容易掌控的單體架構(gòu)起步構(gòu)建蜂桶，如果最終發(fā)現(xiàn)單體架構(gòu)復(fù)雜到影響了團隊的開發(fā)效率及軟件的伸縮性等方面時，才會開始考慮逐步將系統(tǒng)往微服務(wù)架構(gòu)做演進(jìn)也切。

現(xiàn)實中任何軟件架構(gòu)都是諸多trade-off的結(jié)果，想要獲得微服務(wù)架構(gòu)所帶來的好處也就意味著有能力承擔(dān)它所帶來的的副作用。Martin Fowler就曾在MicroservicePrerequisites一文中指出實施微服務(wù)所需要的先決條件箕昭，他用“個子是否夠高”形象地比喻了微服務(wù)所需的技能門檻尾序。

而對于既有系統(tǒng)，還需要一種務(wù)實的演進(jìn)方法和實施策略贫贝，使得能夠伴隨著恰當(dāng)?shù)拇a重構(gòu)，逐步積累能力和完善基礎(chǔ)設(shè)施，最終平穩(wěn)的將其演進(jìn)到微服務(wù)架構(gòu)附井。

本文總結(jié)了一些從既有系統(tǒng)到微服務(wù)演進(jìn)之路上會遇到的問題和解決策略。文中使用“既有系統(tǒng)”而非“遺留系統(tǒng)”两残，是因為遺留系統(tǒng)給人一種即將退出生命周期永毅、行將就木的感覺，而我們則希望把精力投入到還有長遠(yuǎn)商業(yè)價值的系統(tǒng)上人弓，通過合理的微服務(wù)演進(jìn)讓其具有持續(xù)的生命力沼死。

演進(jìn)策略

本文推薦的從既有系統(tǒng)到微服務(wù)的一種務(wù)實安全的演進(jìn)策略是：自上向下分析，自下向上重構(gòu)崔赌，逐步完善配套意蛀。

所謂“自上向下分析”，主要包含以下步驟：

• 整體演進(jìn)路線規(guī)劃：

  • 梳理既有系統(tǒng)的領(lǐng)域模型健芭，設(shè)計合理的內(nèi)部服務(wù)邊界县钥，按照優(yōu)先級和依賴關(guān)系規(guī)劃演進(jìn)路線；

• 服務(wù)治理方案設(shè)計：

  • 按照優(yōu)先級吟榴，為新服務(wù)定義職責(zé)魁蒜，接口，與既有系統(tǒng)的交互方式以及跨服務(wù)的集成測試方案吩翻；
  • 定義新服務(wù)的打包兜看、測試、發(fā)布狭瞎、部署细移、集成方式，目標(biāo)是能夠為其構(gòu)建獨立的代碼庫和持續(xù)交付流水線熊锭；

• 代碼解耦設(shè)計和重構(gòu)：

  • 分析屬于新服務(wù)的獨立代碼以及和既有系統(tǒng)耦合的代碼弧轧，從物理打包和邏輯代碼重構(gòu)兩層面解決耦合問題；
  • 針對不同的解耦策略碗殷，制定不同的測試策略精绎，完善自動化測試以支撐對應(yīng)的代碼重構(gòu)工作。

所謂“自下向上重構(gòu)”锌妻，指的是按照前面的分析設(shè)計結(jié)果代乃，從代碼重構(gòu)開始，自下向上按照優(yōu)先級和一定節(jié)奏持續(xù)進(jìn)行服務(wù)化改造。

而“逐步完善配套”搁吓，指的是隨著服務(wù)化的開展原茅，逐步完善代碼庫管理，多流水線集成堕仔，并逐步按需引入服務(wù)治理框架擂橘，積累微服務(wù)需要的技術(shù)和工具能力。

上述過程是一個迭代的過程：通過適度的分析和設(shè)計摩骨，規(guī)劃出具體的落地工作通贞，然后通過小步增量的實踐迅速獲得成果和反饋，在過程中逐步培養(yǎng)人的能力恼五、完善支撐微服務(wù)架構(gòu)的工程實踐滑频。

自上向下設(shè)計

明確目標(biāo)和約束

對既有系統(tǒng)做微服務(wù)化解耦，需要對不同解耦方向能獲得的收益和存在的約束做到心中有數(shù)唤冈。見過一些組織在做微服務(wù)拆分時只強調(diào)可以獲得的片面好處峡迷，忽略了對組織更有益的其它潛在價值，或者低估了微服務(wù)化帶來的問題你虹。這往往會導(dǎo)致不合理的服務(wù)邊界劃分或者錯誤的優(yōu)先級排序绘搞。

沿著不同的邊界劃分，目的是為了不同的價值目標(biāo)：

• 沿著系統(tǒng)內(nèi)不同的變化原因和變化頻率做服務(wù)劃分
  通過隔離不同的變化方向傅物，減少特性開發(fā)之間的干擾夯辖，使能小的獨立交付團隊。通過獨立代碼庫董饰、獨立流水線蒿褂，獨立的開發(fā)、測試卒暂、交付和運維過程啄栓，提高交付效率和響應(yīng)速度。

• 沿著不同的資源使用邊界做服務(wù)劃分
  通過將不同資源占用特征的服務(wù)進(jìn)行隔離也祠，使能獨立的水平彈縮昙楚，優(yōu)化資源使用效率和提升業(yè)務(wù)響應(yīng)能力。

• 沿著不同性能路徑邊界做服務(wù)劃分
  通過將性能核心路徑作為獨立服務(wù)進(jìn)行隔離诈嘿，可以為性能核心路徑使用不同的技術(shù)棧以及做各種極致的性能優(yōu)化堪旧；另一方面避免各種改動影響到關(guān)鍵路徑的性能下降（例如被動引入更多的異步交互等）。

由于服務(wù)劃分會為系統(tǒng)引入新內(nèi)部邊界奖亚，所以必須考慮如下的約束：

• 數(shù)據(jù)一致性約束：服務(wù)劃分后可能帶來數(shù)據(jù)一致性變?nèi)醯膯栴}淳梦，需要考慮是否可以接受；

• 性能約束：服務(wù)劃分后帶來的潛在性能下降昔字，需要考慮如何度量以及承受程度爆袍；

• 容錯性約束：服務(wù)劃分為系統(tǒng)內(nèi)部引入更多的分布式故障點，需要能夠為其找到可接受的容錯設(shè)計；

• 耦合關(guān)系約束：服務(wù)劃分會放大系統(tǒng)的耦合問題螃宙，所以需要考慮沿著系統(tǒng)的松耦合邊界進(jìn)行服務(wù)劃分，避免服務(wù)間復(fù)雜的交互或者聯(lián)動修改所坯。

在開始可以按照理想的價值目標(biāo)去劃分微服務(wù)邊界谆扎，然后再接受每一項約束的挑戰(zhàn)，最終的服務(wù)劃分方案往往是一個在目標(biāo)和約束之間逐漸平衡后的結(jié)果芹助。

避免過度設(shè)計陷阱

對既有系統(tǒng)的微服務(wù)改造設(shè)計往往會陷入“架構(gòu)設(shè)計陷阱”堂湖。過于詳盡的分析和設(shè)計反而常常會阻礙微服務(wù)的拆分，經(jīng)常得到一個“成本很大状土，困難很多”的論證无蜂。

對于這種情況，建議采用 快速啟動蒙谓、增量交付斥季、大膽實驗、小心求證 的原則累驮。即快速構(gòu)建目標(biāo)酣倾，通過敏捷和精益軟件開發(fā)的方式快速實踐，通過反饋進(jìn)行快速學(xué)習(xí)谤专，在行動中解決各種問題躁锡。

具體的實踐過程中：

• 有了基本的分析后，快速成立試點團隊作為探索者進(jìn)行解耦驗證置侍，盡早獲得反饋映之；
• 雖然快速啟動，但是短期目標(biāo)要明確蜡坊，通過迭代的增量交付來規(guī)避風(fēng)險杠输；
• 在實踐過程中逐步按需對修改影響較大的特性補充和完善自動化測試；
• 對有較大風(fēng)險的代碼修改秕衙，可以先拷貝一份在新的服務(wù)內(nèi)做實驗抬伺，獲得足夠反饋后再擇機合入原代碼庫；
• 可以借助工具分析代碼的依賴關(guān)系灾梦。曾經(jīng)在一個項目我們通過部署doxygen和graphviz來可視化代碼的依賴關(guān)系和解耦進(jìn)展峡钓，取得了不錯的效果。

微服務(wù)設(shè)計

關(guān)于微服務(wù)設(shè)計的方方面面已經(jīng)有很多優(yōu)秀的書和文章了若河，例如《微服務(wù)設(shè)計》就是一本不錯的教材能岩。即便如此到任何一個具體的領(lǐng)域，仍有很多困難和挑戰(zhàn)萧福，需要領(lǐng)域?qū)＜液蛙浖こ處焸兠芮信浜先ソ鉀Q拉鹃。

使用領(lǐng)域驅(qū)動設(shè)計（DDD）方法可以幫助所有參與者重新梳理業(yè)務(wù)并達(dá)成共識。通過識別業(yè)務(wù)的界定上下文和聚合根，可以為如何劃分服務(wù)提供參考膏燕≡壳可以嘗試組織DDD Workshop，但是要清楚這只是一項工具坝辫，而且有時成本并不小篷就。DDD是一個演進(jìn)式的過程，更多的工作需要隨著深入業(yè)務(wù)和代碼近忙，通過實踐收集反饋迭代式的進(jìn)行竭业。

現(xiàn)實情況中，負(fù)責(zé)系統(tǒng)架構(gòu)演進(jìn)的人員都是對業(yè)務(wù)和設(shè)計現(xiàn)狀比較熟悉的專家及舍，一種高效的做法是從當(dāng)前的數(shù)據(jù)模型直接入手未辆。分析每一張表和每項字段所支撐的業(yè)務(wù)，將業(yè)務(wù)按照數(shù)據(jù)的內(nèi)聚性進(jìn)行分類锯玛，然后以此作為服務(wù)劃分的起點咐柜。可以假設(shè)已經(jīng)將數(shù)據(jù)按照新的服務(wù)邊界重新分庫分表攘残，然后嘗試基于此重新構(gòu)建每條業(yè)務(wù)流程炕桨，并在過程中解決由于數(shù)據(jù)拆分而出現(xiàn)的各種問題。該做法適合對微服務(wù)架構(gòu)有經(jīng)驗的人和領(lǐng)域?qū)＜液献魍瓿煽贤螅@樣能夠?qū)Τ霈F(xiàn)的各種問題找到不偏頗的解決方案献宫。

天下沒有免費的午餐，有時為了得到微服務(wù)的好處实撒，是需要做一些妥協(xié)的姊途。例如數(shù)據(jù)模型中某一實體的不同屬性具有不同的業(yè)務(wù)內(nèi)聚度，所以同一概念的不同屬性數(shù)據(jù)被分到了不同服務(wù)中知态，但是這些數(shù)據(jù)在某些場景下要保持同步（例如需要被整體刪除或修改等）捷兰。最常見的解決方案是選擇一個穩(wěn)定的服務(wù)作為對該實體的權(quán)威擁有者，其它服務(wù)通過某種手段（例如消息隊列）和該服務(wù)對齊各種實例操作负敏。這意味著業(yè)務(wù)要能接受最終一致性贡茅，還得接受在某些異常場景下數(shù)據(jù)一直沒有同步成功而上報的告警。

在設(shè)計服務(wù)的集成方式時其做，需要站在業(yè)務(wù)角度去識別誰是更穩(wěn)定的服務(wù)顶考。依據(jù)“向穩(wěn)定方向依賴”的原則，我們只會讓不穩(wěn)定的服務(wù)去調(diào)用穩(wěn)定服務(wù)的API妖泄，而反過來穩(wěn)定的服務(wù)最好通過消息隊列發(fā)布事件驹沿。那些需要跨越多個服務(wù)去獲取數(shù)據(jù)的服務(wù)，一般可以通過監(jiān)聽事件和緩存與系統(tǒng)解耦蹈胡，但這并非適合所有場景渊季。在某些場景下由于業(yè)務(wù)的一致性和性能限制朋蔫，我們確實需要往回退，把某些服務(wù)進(jìn)行合并却汉。這就是個不斷的頭腦風(fēng)暴驯妄，然后再在各種選擇中做trade-off，最終獲得平衡的過程合砂。

對于缺乏經(jīng)驗的團隊可以從較容易拆分的服務(wù)做起青扔。例如一個web服務(wù)端可以先把路由和基本鑒權(quán)拆分出來，交給API Gateway負(fù)責(zé)既穆；然后再把各種報表和統(tǒng)計等一致性與性能要求相對低的拆分出來，最后再嘗試切分其它業(yè)務(wù)處理雀鹃。

一旦服務(wù)拆分出來幻工，就可以根據(jù)業(yè)務(wù)特征重新優(yōu)化數(shù)據(jù)模型并選擇更適合的數(shù)據(jù)庫。另外服務(wù)的API設(shè)計也是有技巧的：應(yīng)用接口隔離原則黎茎，需要API能獨立完成功能囊颅，又要粒度相對小可以靈活組合。這方面亞馬遜各種AWS服務(wù)的API設(shè)計就是不錯的樣例傅瞻。

自下向上重構(gòu)

得到了可行的服務(wù)劃分方案踢代，接下來就需要實際操作代碼，將新服務(wù)的代碼與既有系統(tǒng)進(jìn)行解耦嗅骄，為獨立的服務(wù)代碼庫和流水線做好準(zhǔn)備胳挎。

目錄/包結(jié)構(gòu)調(diào)整

軟件的包結(jié)構(gòu)一般和構(gòu)建軟件的組織結(jié)構(gòu)以及建模方式有關(guān)。一般復(fù)雜系統(tǒng)同時存在著兩個大的變化方向：技術(shù)維度和業(yè)務(wù)維度溺森，而軟件的包結(jié)構(gòu)往往只能反映其中的一個維度慕爬。當(dāng)組織結(jié)構(gòu)以軟件的技術(shù)維度進(jìn)行劃分，那么系統(tǒng)的包結(jié)構(gòu)也基本上會以此劃分屏积，這時業(yè)務(wù)維度的變化往往會映射到系統(tǒng)的每一個包上医窿。反過來也是一樣！衡量哪種包結(jié)構(gòu)合理炊林，往往是看當(dāng)前哪個是主要的變化方向姥卢。對主要的變化方向進(jìn)行拆包隔離，可以降低代碼變化之間的互相影響程度渣聚。

如果按照變化方向進(jìn)行包的拆分独榴，就會發(fā)現(xiàn)系統(tǒng)中應(yīng)該存在很多小的包，最后每個服務(wù)是一堆原子的小包組合奕枝。這本質(zhì)上是將系統(tǒng)重新進(jìn)行合理模塊化的過程括眠。Adam Drake在文章Enough with the microservices中就直接指出微服務(wù)架構(gòu)應(yīng)該先從良好的模塊化重構(gòu)做起，大多數(shù)時候當(dāng)模塊化做好了甚至?xí)l(fā)現(xiàn)很多問題已經(jīng)得到解決了倍权。

然而既有系統(tǒng)的模塊合理化調(diào)整很難僅通過重新拆包達(dá)成掷豺！因為代碼是有邏輯的捞烟，模塊化的邏輯邊界不可能剛剛好落在代碼文件邊界。大多數(shù)情況下都需要先對某一個代碼文件進(jìn)行拆分当船，對某一個類或者函數(shù)進(jìn)行重構(gòu)题画，對某一段邏輯進(jìn)行重新設(shè)計，然后才能重新得到一個一致的邏輯和物理邊界德频，支撐繼續(xù)的拆包工作苍息。

之前見過一個組織通過拆包進(jìn)行系統(tǒng)解耦，他們把新服務(wù)和既有系統(tǒng)共享的所有代碼拆分成很多小的共享包壹置。這樣做后看似每個服務(wù)在構(gòu)建和流水線是獨立性的竞思，但是問題在于那些共享包的代碼量并不小而且包含很多耦合的業(yè)務(wù)邏輯，新的修改經(jīng)常導(dǎo)致新服務(wù)和既有系統(tǒng)一起升級更新钞护。

可以先對新服務(wù)建立獨立的目錄盖喷，然后嘗試把屬于新服務(wù)的代碼逐漸往獨立目錄中遷移，在這一過程中識別出新服務(wù)和既有系統(tǒng)耦合的代碼难咕，然后一邊重構(gòu)课梳，再一邊繼續(xù)調(diào)整目錄和包結(jié)構(gòu)，最后使得新服務(wù)和既有系統(tǒng)在物理和邏輯上同時解耦余佃。

代碼重構(gòu)

軟件重構(gòu)目的是為了解耦新服務(wù)和既有系統(tǒng)之間的共享代碼暮刃。共享代碼一般分為如下幾種形式：

• 共同依賴的組件或者類，這又分為如下幾種情況：

  • 穩(wěn)定的基礎(chǔ)功能代碼爆土。例如編解碼庫椭懊，加解密等等。這些代碼可以按照功能發(fā)布成獨立組件步势，供每個服務(wù)自行決定使用灾搏。
  • 服務(wù)間接口和消息定義。這類代碼可以劃分到獨立的庫中立润，盡量保持向前兼容狂窑，由接口的消費方自由選擇依賴的版本。服務(wù)間的API和消息定義在本質(zhì)上是契約的共享桑腮，可以使用契約描述文件代替共享代碼泉哈，使用時自動從契約描述生成代碼，這對于不同技術(shù)棧的服務(wù)會比較友好破讨。
  • 不合理編碼導(dǎo)致的耦合丛晦。例如耦合了所有功能的大而全的單例類，一般是一些全局配置類或者是“創(chuàng)建一切”的工廠類等提陶。這種情況需要對原有設(shè)計進(jìn)行重構(gòu)烫沙，對大而全的類進(jìn)行拆分，將屬于不同服務(wù)的代碼拆分到不同的類中隙笆，由各個服務(wù)領(lǐng)回屬于自己的代碼锌蓄。

• 共同繼承的接口或者類升筏，這又分為如下幾種情況：

  • 繼承是為了組合：需要將繼承的公共處理重構(gòu)為支撐組件，由不同的服務(wù)根據(jù)需要自行選擇組合和使用方式瘸爽。
  • 繼承是為了面向接口編程您访，這時接口往往是為了配合某些公共業(yè)務(wù)處理而做的抽象。這些公共處理可以按照以下幾種情況進(jìn)行重構(gòu)：
    1. 接口背后的公共處理包含了復(fù)雜的業(yè)務(wù)邏輯剪决，優(yōu)先考慮將該公共處理變?yōu)橐粋€服務(wù)灵汪。這時需要將繼承接口上的同步調(diào)用變?yōu)榉?wù)間的消息接口。
    2. 接口背后的公共處理簡單或者并不穩(wěn)定柑潦，可以考慮按照“Replication Over Reuse”的原則享言，由每個服務(wù)自行實現(xiàn)，減少服務(wù)間的代碼共享渗鬼。
    3. 接口背后的公共處理復(fù)雜览露，但是包含的業(yè)務(wù)邏輯相對穩(wěn)定，如果不能將其獨立為服務(wù)（例如由于性能原因）乍钻，可以將其打包成公共組件肛循，由每個服務(wù)自行組合使用铭腕。

從既有系統(tǒng)到微服務(wù)演進(jìn)银择，在具體的落地中會發(fā)現(xiàn)最基礎(chǔ)的工作主要是代碼重構(gòu)。而能否很好的實施代碼重構(gòu)是一個體現(xiàn)團隊基本軟件技能素質(zhì)的過程累舷，需要團隊提升軟件設(shè)計浩考、代碼重構(gòu)、自動化測試方面的能力被盈。

逐步完善配套

隨著自下向上的重構(gòu)析孽，新服務(wù)的代碼逐漸解耦到獨立的目錄或者包中，這時就可以按需補齊服務(wù)化所欠缺的服務(wù)治理機制和各種工程實踐只怎。在服務(wù)代碼不具備獨立性的時候開始嘗試搭建各種服務(wù)治理機制和工程流水線袜瞬，往往會引入很多偶發(fā)復(fù)雜度，對工具提出一些不切實際的要求身堡。

服務(wù)治理

微服務(wù)作為面向服務(wù)架構(gòu)當(dāng)下能夠流行邓尤，原因之一在于隨著技術(shù)的進(jìn)步各種服務(wù)治理工具都可以廉價獲得。服務(wù)注冊發(fā)現(xiàn)贴谎、API網(wǎng)關(guān)汞扎、消息隊列、負(fù)載均衡擅这、服務(wù)監(jiān)控澈魄、集群運維等每種需求都可以在網(wǎng)絡(luò)上找到一批的開源工具，而團隊則需要根據(jù)自己的現(xiàn)狀進(jìn)行合理的選擇仲翎。有經(jīng)驗的團隊可以把各種不同的治理工作交給最合適的工具去做痹扇，而對于缺乏經(jīng)驗的團隊來說可以先從某一工具入手累積經(jīng)驗铛漓。曾經(jīng)有一個團隊在開始不想引入過多工具復(fù)雜性，先選擇使用redis做緩存和消息隊列帘营，隨后又使用redis做分布式配置以及服務(wù)的注冊與發(fā)現(xiàn)等等票渠。后來隨著能力提升，轉(zhuǎn)而使用etcd替代redis做服務(wù)的注冊發(fā)現(xiàn)芬迄，使用kafka做消息隊列问顷。

對服務(wù)治理工具的選擇要避免陷入選擇困難癥。每個團隊都會覺得自己的業(yè)務(wù)特殊禀梳，開源工具總是不能滿足自己的所有要求杜窄。帶著這種想法很容易裹足不前，一再浪費架構(gòu)重構(gòu)的合適時機算途。精益的做法是塞耕，先找到業(yè)界普遍使用的工具，一邊使用一邊解決問題嘴瓤，一旦開始了很多問題在實踐中總能迎刃而解扫外。對于一些注重性能的系統(tǒng)，不可避免的需要對開源組件在特定業(yè)務(wù)場景下進(jìn)行優(yōu)化定制廓脆，也最好先開始使用然后在實踐中確定優(yōu)化的方向筛谚。

持續(xù)交付

“服務(wù)有自己獨立代碼庫和交付流水線，可以避免交付過程中的互相干擾停忿，提高交付速度和質(zhì)量”驾讲，遺憾的是上述描述其實是個偽命題！

真正減少團隊干擾席赂、提高交付速度和質(zhì)量的是“正確的解耦”本身吮铭。獨立的代碼庫和流水線會將架構(gòu)約束顯示化，讓團隊成員難以犯錯颅停。但是如果過早的對不成熟或者不穩(wěn)定的架構(gòu)邊界進(jìn)行固化谓晌，反而會降低團隊的效率，讓后續(xù)架構(gòu)調(diào)整變得困難癞揉。另外在系統(tǒng)沒有合理解耦的情況下纸肉，獨立的代碼庫和流水線只會讓交互變得更復(fù)雜，導(dǎo)致對構(gòu)建和發(fā)布工具提出一堆不合理的要求烧董。

但是如果服務(wù)之間確實已經(jīng)正交拆分毁靶，代碼邊界和架構(gòu)邊界一致并且是穩(wěn)定的，這時獨立的代碼庫和流水線就可以降低團隊在交付流水線上的互相干擾和排隊逊移，此時就值得為新的服務(wù)建立獨立的代碼庫和自動化流水線预吆。考慮到服務(wù)之間的集成胳泉，往往需要多級流水線拐叉，這時選擇一款支持pipeline的持續(xù)集成工具是必要的岩遗。Jenkins2.x以及GoCD是此類產(chǎn)品的代表。

適應(yīng)的組織結(jié)構(gòu)和文化

康威定律經(jīng)常被拿來說明組織結(jié)構(gòu)和系統(tǒng)架構(gòu)之間的互相作用關(guān)系凤瘦。在對既有系統(tǒng)的服務(wù)化重構(gòu)中宿礁，軟件架構(gòu)和團隊結(jié)構(gòu)同步進(jìn)行調(diào)整會讓整個過程更加順暢。曾經(jīng)有一個系統(tǒng)最初按照技術(shù)維度劃分團隊蔬芥，后來為了提高響應(yīng)市場的速度把團隊按照不同的業(yè)務(wù)類型進(jìn)行了調(diào)整梆靖。重新劃分后的團隊開始發(fā)現(xiàn)他們會經(jīng)常修改同一公共組件，這時他們自發(fā)的對該組件進(jìn)行了解耦笔诵，將其中和業(yè)務(wù)相關(guān)的邏輯各自領(lǐng)了回去返吻，然后將剩下的穩(wěn)定邏輯下沉到了基礎(chǔ)設(shè)施中。

除了匹配的組織結(jié)構(gòu)乎婿，還需要團隊逐漸調(diào)整自己的文化测僵。專門的測試人員和運維人員在微服務(wù)架構(gòu)下必然成為瓶頸，需要改變傳統(tǒng)的細(xì)分工的文化谢翎。團隊每個成員都要有意愿和能力承擔(dān)起服務(wù)的測試和運維工作捍靠，這需要組織從文化建設(shè)到考核方式做對應(yīng)的調(diào)整。

總結(jié)

對于既有系統(tǒng)做微服務(wù)演進(jìn)森逮，一旦第一個服務(wù)改造成功榨婆，后續(xù)的服務(wù)借助前面的成功經(jīng)驗和已有的基礎(chǔ)實施，會更加的容易拆分吊宋。不過第一個服務(wù)的拆分確實需要投入比較大的決心和精力纲辽，本文給出了一些建議颜武，歸根結(jié)底總結(jié)起來就是：以精益的方式開展璃搜，以代碼解耦為核心，以服務(wù)化技能做武裝鳞上，以組織結(jié)構(gòu)和文化調(diào)整做基礎(chǔ)这吻！