最近有不少企業都不約而同的在關注原有應用的遷移上云和應用改造的事情，都在糾結一個問題，那就是是否有必要把單體應用做微服務拆分和架構改造。大家所處行業不同、自身情況不同、業務對IT的訴求也不同、對技術的理解和擁有成本也不一樣，所以說，這個問題沒有標準答案，也不會有標準答案。但是有一些共性的原則是可以梳理借鑒的。

一、單體應用不是過街老鼠，微服務也不一定是濟世良方

首先我們來看單體應用和微服務的基本特征：

• 微服務架構是采用化整為零的架構原則，將應用程序表示為細粒度的、松散耦合的服務集合。由于整體的復雜性從整體的功能耦合被轉移到了服務的協調級別上，因此每個服務都代表了一種業務細粒度的功能，可以更加容易地去做管理和協同。
• 而單體架構是在統一的功能框架下，將離散的功能點用一定的流程編排到一起，形成一個不可拆分單元，作為一個整體進行測試、部署和擴展。由于所有組件都有較強的依存關系，各個組件很難單獨運行，形成了一榮俱榮一損俱損的格局。

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

從傳統的經驗來看，單體應用適合用于簡單業務場景簡單，功能不復雜，研發易于管理，還有一些對性能苛刻的場景也同樣適合用單體應用，這可能會顛覆一部分人的認知。另外，如果業務的需求非常穩定，基本不會變化，也同樣可以繼續沿用單體應用架構。

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

什么時候需要考慮引入微服務呢？

如果用單體應用能輕松解決的問題就沒必要用微服務架構。一般來說，如果發生以下情況，就可以考慮引入微服務了：

• 業務需求開始頻繁變化，功能或者系統交付速度遠遠跟不上需求變化；
• 代碼變得非常臃腫，非常龐大，測試、維護和修改都變得小心翼翼；
• 訪問量激增，對分布式和彈性擴展有較強需求；
• 有大量單體應用同時提供服務，通過簡單集成封裝已經無法實現調度和管理；
• 原有單體應用系統生命周期結束，需要重新開發。

由于微服務架系需要眾多的基礎設施平臺和基礎組件支撐，才能發揮微服務架構的優勢，所以在基礎設施比較落后的情況下，采用微服務可能無法展現其價值，反而使管理任務變得更多、更繁瑣。一定得明白，微服務不是銀彈，這世界上也沒有銀彈。

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

單體應用的上云的難度系數是10，那單體應用的拆分難度就是100。無論什么時候對待微服務拆分都要謹慎，不到萬不得已，不要輕舉妄動。如果一定要動，有一條鐵律要謹記，不能為了拆分而拆分，一定得收益，重要性從低到高，分別是業務上的、IT管理上的和技術實現上的。

微服務的拆分，有兩個前提條件，一是回答為什么拆分，二是做好充分調研。

為什么拆分，可以從業務驅動和技術驅動兩個方面回答。理由，就像世上的路，世上本無路，走得多了就有了路。有了理由，更重要的是準備工作，首先要搜集業務和應用的所有信息，明確工作的整體基線和基本原則。

拆分時機的選擇也是一個重要的問題，隨著業務復雜度的上升單體應用的成本和代價在急劇飆升，但是當業務發展期初期，微服務的整體成本也遠比單體應用高，這個拐點出現在時候，每個客戶的情況都不一樣，需要仔細甄別和判斷。

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

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

1. 單一性原則：單一服務內部功能高內聚低耦合，每個服務只完成自己職責內的任務，對于不是自己職責的功能交給其它服務來完成；

2. 封閉性原則：當我們需要改變一個微服務的時候，所有依賴都在這個微服務的組件內，不需要修改其他微服務；

3. 服務自治原則：盡量消除對其他服務的強依賴，這樣可以降低溝通成本，提升服務穩定性。服務通過標準的接口隔離，隱藏內部實現細節；

4. 粒度適中原則：從微服務這幾個字來看，服務的粒度貌似應該足夠小，但是服務多了也會帶來問題，就像傳統哲學中的中庸之道，又好比東家之子，增之一分則太肥，減之一分則太瘦，好難！！

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

6. 可擴展性原則：服務接口的定義要具備擴展性，凡是要有留余地，又是傳統哲學。

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

三、凡事都有方法

分享幾個跟微服務拆分有關的方法論和原理：

1、AKF可擴展立方體

2、弓箭原理

3、三個火槍手原則