背景

微服務(wù)在最近幾年大行其道，很多公司的研發(fā)人員都在考慮微服務(wù)架構(gòu)，同時，隨著 Docker 容器技術(shù)和自動化運維等相關(guān)技術(shù)發(fā)展，微服務(wù)變得更容易管理，這給了微服務(wù)架構(gòu)良好的發(fā)展機會。

在做微服務(wù)的路上，拆分服務(wù)是個很熱的話題。我們應(yīng)該按照什么原則將現(xiàn)有的業(yè)務(wù)進行拆分？是否拆分得越細就越好？接下來一起談?wù)劮?wù)拆分的策略和堅持的原則。

拆分目的是什么？

在介紹如何拆分之前，我們需要了解下拆分的目的是什么，這樣才不會在后續(xù)的拆分過程中忘了最初的目的。

拆分的本質(zhì)是為了將復(fù)雜的問題簡單化，那么我們在單體架構(gòu)階段遇到了哪些復(fù)雜性問題呢？首先來回想下當初為什么選用了單體架構(gòu)，在電商項目剛啟動的時候，我們只希望能盡快地將項目搭建起來，方便將產(chǎn)品更早的投放市場進行快速驗證。在開發(fā)初期，這種架構(gòu)確實給開發(fā)和運維帶來了很大的便捷，主要體現(xiàn)在：

開發(fā)簡單直接，代碼和項目集中式管理
排查問題時只需要排查這個應(yīng)用就可以了，更有針對性
只需要維護一個工程，節(jié)省維護系統(tǒng)運行的人力成本
但是隨著功能越來越多，開發(fā)團隊的規(guī)模越來越大，單體架構(gòu)的缺陷慢慢體現(xiàn)出來，主要有以下幾個方面。

在技術(shù)層面，數(shù)據(jù)庫的連接數(shù)成為應(yīng)用服務(wù)器擴容的瓶頸，因為連接 MySQL 的客戶端數(shù)量是有限制的。

除此之外，單體架構(gòu)增加了研發(fā)的成本抑制了研發(fā)效率的提升。比如公司的垂直電商系統(tǒng)團隊會被按業(yè)務(wù)線拆分為不同的組。當如此多的小團隊共同維護一套代碼和一個系統(tǒng)時，在配合的過程中就會出現(xiàn)問題。不同的團隊之間溝通少，假如一個團隊需要一個發(fā)送短信的功能，那么有的研發(fā)同學(xué)會認為最快的方式不是詢問其他團隊是否有現(xiàn)成的而是自己寫一套，但是這種想法是不合適的，會造成功能服務(wù)的重復(fù)開發(fā)。由于代碼部署在一起，每個人都向同一個代碼庫提交代碼，代碼沖突無法避免；同時功能之間耦合嚴重，可能你只是更改了很小的邏輯卻導(dǎo)致其它功能不可用，從而在測試時需要對整體功能回歸，延長了交付時間。模塊之間互相依賴，一個小團隊中的成員犯了一個錯誤，就可能會影響到其它團隊維護的服務(wù)，對于整體系統(tǒng)穩(wěn)定性影響很大。

最后，單體架構(gòu)對于系統(tǒng)的運維也會有很大的影響。想象一下，在項目初期你的代碼可能只有幾千行，構(gòu)建一次只需要一分鐘，那么你可以很敏捷靈活地頻繁上線變更修復(fù)問題。但是當你的系統(tǒng)擴充到幾十萬行甚至上百萬行代碼的時候，一次構(gòu)建的過程包括編譯、單元測試、打包和上傳到正式環(huán)境，花費的時間可能達到十幾分鐘，并且任何小的修改，都需要構(gòu)建整個項目，上線變更的過程非常不靈活。

而這些問題都可以通過微服務(wù)化拆分來解決。

為了方便你更好的理解這塊，我這邊附上一份表格（內(nèi)容來源：《持續(xù)演進的 Cloud Native：云原生架構(gòu)下微服務(wù)最佳》一書），可以更直觀地幫助你認識拆分的目的。

拆分時機應(yīng)該如何決策？

產(chǎn)品初期，應(yīng)該以單體架構(gòu)優(yōu)先。因為面對一個新的領(lǐng)域，對業(yè)務(wù)的理解很難在開始階段就比較清晰，往往是經(jīng)過一段時間之后，才能逐步穩(wěn)定，如果拆分過早，導(dǎo)致邊界拆分不合理或者拆的過細，反而會影響生產(chǎn)力。很多時候，從一個已有的單體架構(gòu)中逐步劃分服務(wù)，要比一開始就構(gòu)建微服務(wù)簡單得多。同時公司的產(chǎn)品并沒有被市場驗證過，有可能會失敗，所以這個投入的風險也會比較高。

另外，在資源受限的情況下，采用微服務(wù)架構(gòu)很多優(yōu)勢無法體現(xiàn)，性能上的劣勢反而會比較明顯。如下圖所示。當業(yè)務(wù)復(fù)雜度達到一定程度后，微服務(wù)架構(gòu)消耗的成本才會體現(xiàn)優(yōu)勢，并不是所有的場景都適合采用微服務(wù)架構(gòu)，服務(wù)的劃分應(yīng)逐步進行，持續(xù)演進。產(chǎn)品初期，業(yè)務(wù)復(fù)雜度不高的時候，應(yīng)該盡量采用單體架構(gòu)。

隨著公司的商業(yè)模式逐漸得到驗證，且產(chǎn)品獲得了市場的認可，為了能加快產(chǎn)品的迭代效率快速占領(lǐng)市場，公司開始引進更多的開發(fā)同學(xué)，這時系統(tǒng)的復(fù)雜度會變得越來越高，就出現(xiàn)單體應(yīng)用和團隊規(guī)模之間出現(xiàn)矛盾，研發(fā)效率不升反降。上圖中的交叉點表明，業(yè)務(wù)已經(jīng)達到了一定的復(fù)雜度，單體應(yīng)用已經(jīng)無法滿足業(yè)務(wù)增長的需求，研發(fā)效率開始下降，而這時就是需要考慮進行服務(wù)拆分的時機點。這個點需要架構(gòu)師去權(quán)衡。筆者所在的公司，是當團隊規(guī)模達到百人的時候，才考慮進行服務(wù)化。

當我們清楚了什么時候進行拆分，就可以直接落地了嗎？不是的，微服務(wù)拆分的落地還要提前準備好配套的基礎(chǔ)設(shè)施，如服務(wù)描述、注冊中心、服務(wù)框架、服務(wù)監(jiān)控、服務(wù)追蹤、服務(wù)治理等幾大基本組件，以上每個組件缺一不可，每個組件展開又包括很多技術(shù)門檻，比如，容器技術(shù)、持續(xù)部署、DevOps 等相關(guān)概念，以及人才的儲備和觀念的變化，微服務(wù)不僅僅是技術(shù)的升級，更是開發(fā)方式、組織架構(gòu)、開發(fā)觀念的轉(zhuǎn)變。

至此，何時進行微服務(wù)的拆分，整體總結(jié)如下：

業(yè)務(wù)規(guī)模：業(yè)務(wù)模式得到市場的驗證，需要進一步加快腳步快速占領(lǐng)市場，這時業(yè)務(wù)的規(guī)模變得越來越大，按產(chǎn)品生命周期來劃分（導(dǎo)入期、成長期、成熟期、衰退期）這時一般在成長期階段。如果是導(dǎo)入期，盡量采用單體架構(gòu)。
團隊規(guī)模：一般是團隊達到百人的時候。
技術(shù)儲備：領(lǐng)域驅(qū)動設(shè)計、注冊中心、配置中心、日志系統(tǒng)、持續(xù)交付、監(jiān)控系統(tǒng)、分布式定時任務(wù)、CAP 理論、分布式調(diào)用鏈、API 網(wǎng)關(guān)等等。
人才儲備：精通微服務(wù)落地經(jīng)驗的架構(gòu)師及相應(yīng)開發(fā)同學(xué)。
研發(fā)效率：研發(fā)效率大幅下降，具體問題參加上面拆分目的里提到的。

拆分時應(yīng)該堅守哪些指導(dǎo)原則？

1. 單一服務(wù)內(nèi)部功能高內(nèi)聚低耦合

也就是說每個服務(wù)只完成自己職責內(nèi)的任務(wù)，對于不是自己職責的功能交給其它服務(wù)來完成。

2. 閉包原則（CCP）

微服務(wù)的閉包原則就是當我們需要改變一個微服務(wù)的時候，所有依賴都在這個微服務(wù)的組件內(nèi)，不需要修改其他微服務(wù)。

3. 服務(wù)自治、接口隔離原則

盡量消除對其他服務(wù)的強依賴，這樣可以降低溝通成本，提升服務(wù)穩(wěn)定性。服務(wù)通過標準的接口隔離，隱藏內(nèi)部實現(xiàn)細節(jié)。這使得服務(wù)可以獨立開發(fā)、測試、部署、運行，以服務(wù)為單位持續(xù)交付。

4. 持續(xù)演進原則

在服務(wù)拆分的初期，你其實很難確定服務(wù)究竟要拆成什么樣。從微服務(wù)這幾個字來看，服務(wù)的粒度貌似應(yīng)該足夠小，但是服務(wù)多了也會帶來問題，服務(wù)數(shù)量快速增長會帶來架構(gòu)復(fù)雜度急劇升高，開發(fā)、測試、運維等環(huán)節(jié)很難快速適應(yīng)，會導(dǎo)致故障率大幅增加，可用性降低，非必要情況，應(yīng)逐步劃分，持續(xù)演進，避免服務(wù)數(shù)量的爆炸性增長，這等同于灰度發(fā)布的效果，先拿出幾個不太重要的功能拆分出一個服務(wù)做試驗，如果出現(xiàn)故障，則可以減少故障的影響范圍。

5. 拆分的過程盡量避免影響產(chǎn)品的日常功能迭代

也就是說要一邊做產(chǎn)品功能迭代，一邊完成服務(wù)化拆分。比如優(yōu)先剝離比較獨立的邊界服務(wù)（如短信服務(wù)等），從非核心的服務(wù)出發(fā)減少拆分對現(xiàn)有業(yè)務(wù)的影響，也給團隊一個練習(xí)、試錯的機會。同時當兩個服務(wù)存在依賴關(guān)系時優(yōu)先拆分被依賴的服務(wù)。

6. 服務(wù)接口的定義要具備可擴展性

服務(wù)拆分之后，由于服務(wù)是以獨立進程的方式部署，所以服務(wù)之間通信就不再是進程內(nèi)部的方法調(diào)用而是跨進程的網(wǎng)絡(luò)通信了。在這種通信模型下服務(wù)接口的定義要具備可擴展性，否則在服務(wù)變更時會造成意想不到的錯誤。比如微服務(wù)的接口因為升級把之前的三個參數(shù)改成了四個，上線后導(dǎo)致調(diào)用方大量報錯，推薦做法服務(wù)接口的參數(shù)類型最好是封裝類，這樣如果增加參數(shù)就不必變更接口的簽名，而只需要在類中添加字段就可以了

7. 避免環(huán)形依賴與雙向依賴

盡量不要有服務(wù)之間的環(huán)形依賴或雙向依賴，原因是存在這種情況說明我們的功能邊界沒有劃分清楚或者有通用的功能沒有下沉下來。

8. 階段性合并

隨著你對業(yè)務(wù)領(lǐng)域理解的逐漸深入或者業(yè)務(wù)本身邏輯發(fā)生了比較大的變化，亦或者之前的拆分沒有考慮的很清楚，導(dǎo)致拆分后的服務(wù)邊界變得越來越混亂，這時就要重新梳理領(lǐng)域邊界，不斷糾正拆分的合理性。

拆分的粒度是不是越細越好？

目前很多傳統(tǒng)的單體應(yīng)用再向微服務(wù)架構(gòu)進行升級改造，如果拆分粒度太細會增加運維復(fù)雜度，粒度過大又起不到效果，那么改造過程中如何平衡拆分粒度呢？

弓箭原理

平衡拆分粒度可以從兩方面進行權(quán)衡，一是業(yè)務(wù)發(fā)展的復(fù)雜度，二是團隊規(guī)模的人數(shù)。如上圖，它就像弓箭一樣，只有當業(yè)務(wù)復(fù)雜度和團隊人數(shù)足夠大的時候，射出的服務(wù)拆分粒度這把劍才會飛的更遠，發(fā)揮出最大的威力。

比如說電商的商品服務(wù)，當我們把商品從大的單體里拆分出來的時候，就商品服務(wù)本身來講邏輯并沒有足夠復(fù)雜到 2~3 個人沒法維護的地步，這時我們沒有必要繼續(xù)將商品服務(wù)拆的更細，但是隨著業(yè)務(wù)的發(fā)展，商品的業(yè)務(wù)邏輯變的越來越復(fù)雜，可能同時服務(wù)公司的多個平臺，此時你會發(fā)現(xiàn)商品服務(wù)本身面臨的問題跟單體架構(gòu)階段面臨的問題基本一樣，這個階段就需要我們將商品拆成更細粒度的服務(wù)，比如，庫存服務(wù)、價格服務(wù)、類目服務(wù)、商品基礎(chǔ)信息服務(wù)等等。

雖然業(yè)務(wù)復(fù)雜度已經(jīng)滿足了，如果公司此時沒有足夠的人力（招聘不及時或員工異動比較多），服務(wù)最好也不要拆分，拆分會因為人力的不足導(dǎo)致更多的問題，如研發(fā)效率大幅下降（一個開發(fā)負責與其不匹配數(shù)量的服務(wù)）。這里引申另外一個問題，一個微服務(wù)究竟需要幾個開發(fā)維護是比較理性的？我引用下李云華老師在"從零開始學(xué)架構(gòu)“ 中的一段經(jīng)典論述，可以解決此問題。

三個火槍手原則

為什么說是三個人分配一個服務(wù)是比較理性的？而不是 4 個，也不是 2 個呢？

首先，從系統(tǒng)規(guī)模來講，3 個人負責開發(fā)一個系統(tǒng)，系統(tǒng)的復(fù)雜度剛好達到每個人都能全面理解整個系統(tǒng)，又能夠進行分工的粒度；如果是 2 個人開發(fā)一個系統(tǒng)，系統(tǒng)的復(fù)雜度不夠，開發(fā)人員可能覺得無法體現(xiàn)自己的技術(shù)實力；如果是 4 個甚至更多人開發(fā)一個系統(tǒng)，系統(tǒng)復(fù)雜度又會無法讓開發(fā)人員對系統(tǒng)的細節(jié)都了解很深。

其次，從團隊管理來說，3 個人可以形成一個穩(wěn)定的備份，即使 1 個人休假或者調(diào)配到其他系統(tǒng)，剩余 2 個人還可以支撐；如果是 2 個人，抽調(diào) 1 個后剩余的 1 個人壓力很大；如果是 1 個人，這就是單點了，團隊沒有備份，某些情況下是很危險的，假如這個人休假了，系統(tǒng)出問題了怎么辦？

最后，從技術(shù)提升的角度來講，3 個人的技術(shù)小組既能夠形成有效的討論，又能夠快速達成一致意見；如果是 2 個人，可能會出現(xiàn)互相堅持自己的意見，或者 2 個人經(jīng)驗都不足導(dǎo)致設(shè)計缺陷；如果是 1 個人，由于沒有人跟他進行技術(shù)討論，很可能陷入思維盲區(qū)導(dǎo)致重大問題；如果是 4 個人或者更多，可能有的參與的人員并沒有認真參與，只是完成任務(wù)而已。

“三個火槍手”的原則主要應(yīng)用于微服務(wù)設(shè)計和開發(fā)階段，如果微服務(wù)經(jīng)過一段時間發(fā)展后已經(jīng)比較穩(wěn)定，處于維護期了，無須太多的開發(fā)，那么平均 1 個人維護 1 個微服務(wù)甚至幾個微服務(wù)都可以。當然考慮到人員備份問題，每個微服務(wù)最好都安排 2 個人維護，每個人都可以維護多個微服務(wù)。

綜上所述，拆分粒度不是越細越好，粒度需要符合弓箭原理及三個火槍手原則。

拆分策略有哪些？

拆分策略可以按功能和非功能維度進行考慮，功能維度主要是劃分清楚業(yè)務(wù)的邊界，非功能維度主要考慮六點包括擴展性、復(fù)用性、高性能、高可用、安全性、異構(gòu)性。接下來詳細介紹下。

功能維度

功能維度主要是劃分清楚業(yè)務(wù)邊界，采用的主要設(shè)計方法可以利用 DDD（關(guān)于 DDD 的理論知識可以參考網(wǎng)上其它資料），DDD 的戰(zhàn)略設(shè)計會建立領(lǐng)域模型，可以通過領(lǐng)域模型指導(dǎo)微服務(wù)的拆分，主要分四步進行：

第一步，找出領(lǐng)域?qū)嶓w和值對象等領(lǐng)域?qū)ο蟆?br /> 第二步，找出聚合根，根據(jù)實體、值對象與聚合根的依賴關(guān)系，建立聚合。
第三步，根據(jù)業(yè)務(wù)及語義邊界等因素，定義限界上下文。
第四步，每一個限界上下文可以拆分為一個對應(yīng)的微服務(wù)，但也要考慮一些非功能因素。
以電商的場景為例，交易鏈路劃分的限界上下文如下圖左半部分，根據(jù)一個限界上下文可以設(shè)計一個微服務(wù)，拆解出來的微服務(wù)如下圖右側(cè)部分。

非功能維度

當我們按照功能維度進行拆分后，并不是就萬事大吉了，大部分場景下，我們還需要加入其它維度進一步拆分，才能最終解決單體架構(gòu)帶來的問題。

擴展性：區(qū)分系統(tǒng)中變與不變的部分，不變的部分一般是成熟的、通用的服務(wù)功能，變的部分一般是改動比較多、滿足業(yè)務(wù)迭代擴展性需要的功能，我們可以將不變的部分拆分出來，作為共用的服務(wù)，將變的部分獨立出來滿足個性化擴展需要。同時根據(jù)二八原則，系統(tǒng)中經(jīng)常變動的部分大約只占 20%，而剩下的 80% 基本不變或極少變化，這樣的拆分也解決了發(fā)布頻率過多而影響成熟服務(wù)穩(wěn)定性的問題。
復(fù)用性：不同的業(yè)務(wù)里或服務(wù)里經(jīng)常會出現(xiàn)重復(fù)的功能，比如每個服務(wù)都有鑒權(quán)、限流、安全及日志監(jiān)控等功能，可以將這些通過的功能拆分出來形成獨立的服務(wù)，也就是微服務(wù)里面的 API 網(wǎng)關(guān)。在如，對于滴滴業(yè)務(wù)，有快車和順風車業(yè)務(wù)，其中都涉及到了訂單支付的功能，那么就可以將訂單支付獨立出來，作為通用服務(wù)服務(wù)好上層業(yè)務(wù)。如下圖：

高性能：將性能要求高或者性能壓力大的模塊拆分出來，避免性能壓力大的服務(wù)影響其它服務(wù)。常見的拆分方式和具體的性能瓶頸有關(guān)，例如電商的搶購，性能壓力最大的是入口的排隊功能，可以將排隊功能獨立為一個服務(wù)。同時，我們也可以基于讀寫分離來拆分，比如電商的商品信息，在 App 端主要是商詳有大量的讀取操作，但是寫入端商家中心訪問量確很少。 因此可以對流量較大或較為核心的服務(wù)做讀寫分離，拆分為兩個服務(wù)發(fā)布，一個負責讀，另外一個負責寫。還有數(shù)據(jù)一致性是另一個基于性能維度拆分需要考慮的點，對于強一致的數(shù)據(jù)，屬于強耦合，盡量放在同一個服務(wù)中（但是有時會因為各種原因需要進行拆分，那就需要有響應(yīng)的機制進行保證），弱一致性通?？梢圆鸱譃椴煌姆?wù)。

高可用：將可靠性要求高的核心服務(wù)和可靠性要求低的非核心服務(wù)拆分開來，然后重點保證核心服務(wù)的高可用。具體拆分的時候，核心服務(wù)可以是一個也可以是多個，只要最終的服務(wù)數(shù)量滿足“三個火槍手”的原則就可以。比如針對商家服務(wù)，可以拆分一個核心服務(wù)一個非核心服務(wù)，核心服務(wù)供交易服務(wù)訪問，非核心提供給商家中心訪問。
安全性：不同的服務(wù)可能對信息安全有不同的要求，因此把需要高度安全的服務(wù)拆分出來，進行區(qū)別部署，比如設(shè)置特定的 DMZ 區(qū)域?qū)Ψ?wù)進行分區(qū)部署，可以更有針對性地滿足信息安全的要求，也可以降低對防火墻等安全設(shè)備吞吐量、并發(fā)性等方面的要求，降低成本，提高效率。
異構(gòu)性：對于對開發(fā)語言種類有要求的業(yè)務(wù)場景，可以用不同的語言將其功能獨立出來實現(xiàn)一個獨立服務(wù)。
以上幾種拆分方式不是多選一，而是可以根據(jù)實際情況自由排列組合。同時拆分不僅僅是架構(gòu)上的調(diào)整，也意味著要在組織結(jié)構(gòu)上做出相應(yīng)的適應(yīng)性優(yōu)化，以確保拆分后的服務(wù)由相對獨立的團隊負責維護。

服務(wù)都拆了為什么還要合并？

古希臘哲學(xué)家赫拉克利特曾經(jīng)說過：“人不能兩次踏進同一條河流。”隨著時間的流逝，任何事物的狀態(tài)都會發(fā)生變化。線上系統(tǒng)同樣如此，即使一個系統(tǒng)在不同時刻的狀況也絕不會一模一樣?，F(xiàn)在拆分出來的服務(wù)粒度也許合適，但誰能保證這個粒度能夠一直正確呢。

服務(wù)都拆了為什么還要合，就是要不斷適應(yīng)新的業(yè)務(wù)發(fā)展階段，我這里做個類比看你是否清晰，拆相當于我們開發(fā)代碼，合相當于重構(gòu)代碼，為什么要重構(gòu)呢，相信你肯定知道。微服務(wù)的合也是一樣的道理，隨著我們對應(yīng)用程序領(lǐng)域的了解越來越深，它們可能會隨著時間的推移而變化。例如，你可能會發(fā)現(xiàn)由于過多的進程間通信而導(dǎo)致特定的分解效率低下，導(dǎo)致你必須把一些服務(wù)組合在一起。

同時因為人員和服務(wù)數(shù)量的不匹配，導(dǎo)致的維護成本增加，也是導(dǎo)致服務(wù)合并的一個重要原因。例如，今年疫情的影響導(dǎo)致很多企業(yè)開始大量裁員，人員流失但是服務(wù)的數(shù)量卻沒有變，造成服務(wù)數(shù)量和人員的不平衡，一個開發(fā)同學(xué)同時要維護至少 5 個服務(wù)的開發(fā)，效率大幅下降。

那么如果微服務(wù)數(shù)量過多和資源不匹配，則可以考慮合并多個微服務(wù)到服務(wù)包，部署到一臺服務(wù)器，這樣可以節(jié)省服務(wù)運行時的基礎(chǔ)資源消耗也降低了維護成本。需要注意的是，雖然服務(wù)包是運行在一個進程中，但是服務(wù)包內(nèi)的服務(wù)依然要滿足微服務(wù)定義，以便在未來某一天要重新拆開的時候可以很快就分離。服務(wù)合并到服務(wù)包示意圖如下：

拆分過程中要注意的風險

1. 不打無準備之仗

開發(fā)團隊是否具備足夠的經(jīng)驗，能否駕馭微服務(wù)的技術(shù)棧，可能是第一個需要考慮的點。這里并不是要求團隊必須具備完善的經(jīng)驗才能啟動服務(wù)拆分，如果團隊中有這方面的專家固然是最好的。如果沒有，那可能就需要事先進行充分的技術(shù)論證和預(yù)演，至少不打無準備之仗。避免哪個簡單就先拆哪個，哪個新業(yè)務(wù)要上線，先起一個服務(wù)再說。否則可能在一些分布式常見的問題上會踩坑，比如服務(wù)器資源不夠、運維困難、服務(wù)之間調(diào)用混亂、調(diào)用重試、超時機制、分布式事務(wù)等等。

2. 不斷糾正

我們需要承認我們的認知是有限的，只能基于目前的業(yè)務(wù)狀態(tài)和有限的對未來的預(yù)測來制定出一個相對合適的拆分方案，而不是所謂的最優(yōu)方案，任何方案都只能保證在當下提供了相對合適的粒度和劃分原則，要時刻做好在未來的末一個時刻會變得不和時宜、需要再次調(diào)整的準備。因此隨著業(yè)務(wù)的演進，需要我們重新審視服務(wù)的劃分是否合理，如服務(wù)拆的太細，導(dǎo)致人員效率反而下降，故障的概率也大大增加，則需要重新劃分好領(lǐng)域邊界。

3. 要做行動派，而不是理論派

在具體怎么拆分上，也不要太糾結(jié)于是否合適，不動手怎么知道合不合適呢？如果拆了之后發(fā)現(xiàn)真的不合適，在重新調(diào)整就好了。你可能會說，重新調(diào)整成本比較高。但實際上這個問題的本質(zhì)是有沒有針對服務(wù)化架構(gòu)搭建起一套完成的能力體系，比如服務(wù)治理平臺、數(shù)據(jù)遷移工具、數(shù)據(jù)雙寫等等，如果有的話，重新調(diào)整的成本是不會太高的。