最近有不少企業(yè)都不約而同的在關(guān)注原有應(yīng)用的遷移上云和應(yīng)用改造的事情，都在糾結(jié)一個(gè)問題，那就是是否有必要把單體應(yīng)用做微服務(wù)拆分和架構(gòu)改造。大家所處行業(yè)不同、自身情況不同、業(yè)務(wù)對(duì)IT的訴求也不同、對(duì)技術(shù)的理解和擁有成本也不一樣，所以說，這個(gè)問題沒有標(biāo)準(zhǔn)答案，也不會(huì)有標(biāo)準(zhǔn)答案。但是有一些共性的原則是可以梳理借鑒的。

一、單體應(yīng)用不是過街老鼠，微服務(wù)也不一定是濟(jì)世良方

首先我們來(lái)看單體應(yīng)用和微服務(wù)的基本特征：

• 微服務(wù)架構(gòu)是采用化整為零的架構(gòu)原則，將應(yīng)用程序表示為細(xì)粒度的、松散耦合的服務(wù)集合。由于整體的復(fù)雜性從整體的功能耦合被轉(zhuǎn)移到了服務(wù)的協(xié)調(diào)級(jí)別上，因此每個(gè)服務(wù)都代表了一種業(yè)務(wù)細(xì)粒度的功能，可以更加容易地去做管理和協(xié)同。
• 而單體架構(gòu)是在統(tǒng)一的功能框架下，將離散的功能點(diǎn)用一定的流程編排到一起，形成一個(gè)不可拆分單元，作為一個(gè)整體進(jìn)行測(cè)試、部署和擴(kuò)展。由于所有組件都有較強(qiáng)的依存關(guān)系，各個(gè)組件很難單獨(dú)運(yùn)行，形成了一榮俱榮一損俱損的格局。

單體應(yīng)用是長(zhǎng)期以來(lái)，在豎井式IT的大格局下，我們所形成的的程式化思維的產(chǎn)物，在現(xiàn)在微服務(wù)大行其道的形勢(shì)下，我們依然很難說單體應(yīng)用一無(wú)是處。比如單體應(yīng)用部署、運(yùn)維、測(cè)試都很簡(jiǎn)便，在業(yè)務(wù)功能邏輯和性能要求沒有高到一定程度的時(shí)候，單體應(yīng)用幫我解決了很多問題。當(dāng)然，隨著后互聯(lián)網(wǎng)時(shí)代的到來(lái)，單體應(yīng)用越來(lái)越不適應(yīng)敏捷快速的需求變化，越來(lái)越難以承接大流量和大并發(fā)的考驗(yàn)。

從傳統(tǒng)的經(jīng)驗(yàn)來(lái)看，單體應(yīng)用適合用于簡(jiǎn)單業(yè)務(wù)場(chǎng)景簡(jiǎn)單，功能不復(fù)雜，研發(fā)易于管理，還有一些對(duì)性能苛刻的場(chǎng)景也同樣適合用單體應(yīng)用，這可能會(huì)顛覆一部分人的認(rèn)知。另外，如果業(yè)務(wù)的需求非常穩(wěn)定，基本不會(huì)變化，也同樣可以繼續(xù)沿用單體應(yīng)用架構(gòu)。

再來(lái)說微服務(wù)，在現(xiàn)在的需求格局下（所處背景很重要，在單體應(yīng)用大行其道的時(shí)候，沒人會(huì)懷疑它的正確性），微服務(wù)很顯然易于擴(kuò)展，而且應(yīng)用組件相互獨(dú)立，有清晰的邊界，通訊方式更便捷，對(duì)多種語(yǔ)言都很友好，還有，開發(fā)過程可以被分開管理，實(shí)現(xiàn)多團(tuán)隊(duì)協(xié)同，服務(wù)組件之間獨(dú)立部署，易于獨(dú)立部署和維護(hù)。但是隨著微服務(wù)的廣泛應(yīng)用，短板也隨之暴露，比如技術(shù)成本畸高、服務(wù)管理、調(diào)度、測(cè)試、部署、監(jiān)控、排障都變得比較復(fù)雜，就像肥皂一樣，看似簡(jiǎn)單，其實(shí)很難以握持。

什么時(shí)候需要考慮引入微服務(wù)呢？

如果用單體應(yīng)用能輕松解決的問題就沒必要用微服務(wù)架構(gòu)。一般來(lái)說，如果發(fā)生以下情況，就可以考慮引入微服務(wù)了：

• 業(yè)務(wù)需求開始頻繁變化，功能或者系統(tǒng)交付速度遠(yuǎn)遠(yuǎn)跟不上需求變化；
• 代碼變得非常臃腫，非常龐大，測(cè)試、維護(hù)和修改都變得小心翼翼；
• 訪問量激增，對(duì)分布式和彈性擴(kuò)展有較強(qiáng)需求；
• 有大量單體應(yīng)用同時(shí)提供服務(wù)，通過簡(jiǎn)單集成封裝已經(jīng)無(wú)法實(shí)現(xiàn)調(diào)度和管理；
• 原有單體應(yīng)用系統(tǒng)生命周期結(jié)束，需要重新開發(fā)。

由于微服務(wù)架系需要眾多的基礎(chǔ)設(shè)施平臺(tái)和基礎(chǔ)組件支撐，才能發(fā)揮微服務(wù)架構(gòu)的優(yōu)勢(shì)，所以在基礎(chǔ)設(shè)施比較落后的情況下，采用微服務(wù)可能無(wú)法展現(xiàn)其價(jià)值，反而使管理任務(wù)變得更多、更繁瑣。一定得明白，微服務(wù)不是銀彈，這世界上也沒有銀彈。

二、微服務(wù)拆分始終都是讓人頭疼的問題

單體應(yīng)用的上云的難度系數(shù)是10，那單體應(yīng)用的拆分難度就是100。無(wú)論什么時(shí)候?qū)Υ⒎?wù)拆分都要謹(jǐn)慎，不到萬(wàn)不得已，不要輕舉妄動(dòng)。如果一定要?jiǎng)?，有一條鐵律要謹(jǐn)記，不能為了拆分而拆分，一定得收益，重要性從低到高，分別是業(yè)務(wù)上的、IT管理上的和技術(shù)實(shí)現(xiàn)上的。

微服務(wù)的拆分，有兩個(gè)前提條件，一是回答為什么拆分，二是做好充分調(diào)研。

為什么拆分，可以從業(yè)務(wù)驅(qū)動(dòng)和技術(shù)驅(qū)動(dòng)兩個(gè)方面回答。理由，就像世上的路，世上本無(wú)路，走得多了就有了路。有了理由，更重要的是準(zhǔn)備工作，首先要搜集業(yè)務(wù)和應(yīng)用的所有信息，明確工作的整體基線和基本原則。

拆分時(shí)機(jī)的選擇也是一個(gè)重要的問題，隨著業(yè)務(wù)復(fù)雜度的上升單體應(yīng)用的成本和代價(jià)在急劇飆升，但是當(dāng)業(yè)務(wù)發(fā)展期初期，微服務(wù)的整體成本也遠(yuǎn)比單體應(yīng)用高，這個(gè)拐點(diǎn)出現(xiàn)在時(shí)候，每個(gè)客戶的情況都不一樣，需要仔細(xì)甄別和判斷。

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

微服務(wù)的拆分需要秉持什么原則呢？

1. 單一性原則：?jiǎn)我环?wù)內(nèi)部功能高內(nèi)聚低耦合，每個(gè)服務(wù)只完成自己職責(zé)內(nèi)的任務(wù)，對(duì)于不是自己職責(zé)的功能交給其它服務(wù)來(lái)完成；

2. 封閉性原則：當(dāng)我們需要改變一個(gè)微服務(wù)的時(shí)候，所有依賴都在這個(gè)微服務(wù)的組件內(nèi)，不需要修改其他微服務(wù)；

3. 服務(wù)自治原則：盡量消除對(duì)其他服務(wù)的強(qiáng)依賴，這樣可以降低溝通成本，提升服務(wù)穩(wěn)定性。服務(wù)通過標(biāo)準(zhǔn)的接口隔離，隱藏內(nèi)部實(shí)現(xiàn)細(xì)節(jié)；

4. 粒度適中原則：從微服務(wù)這幾個(gè)字來(lái)看，服務(wù)的粒度貌似應(yīng)該足夠小，但是服務(wù)多了也會(huì)帶來(lái)問題，就像傳統(tǒng)哲學(xué)中的中庸之道，又好比東家之子，增之一分則太肥，減之一分則太瘦，好難?。?/p>

5. 最小影響性原則：拆分的過程盡量避免影響產(chǎn)品的日常功能迭代。也就是說要一邊做產(chǎn)品功能迭代，一邊完成服務(wù)化拆分；

6. 可擴(kuò)展性原則：服務(wù)接口的定義要具備擴(kuò)展性，凡是要有留余地，又是傳統(tǒng)哲學(xué)。

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

三、凡事都有方法

分享幾個(gè)跟微服務(wù)拆分有關(guān)的方法論和原理：

1、AKF可擴(kuò)展立方體

2、弓箭原理

3、三個(gè)火槍手原則