1 微服務遷移準備
1、需對業務充分了解，這是服務拆分，通信設計，資源整合的必要前提。
2、適應微服務架構設計原則：小版本，高速疊代。
3、快速的環境提供能力：依賴於雲計算、容器技術，快速交付環境。
4、服務合理拆分：需符合團隊結構或能逆向影響，能對組織架構進行微調並劃分職責。（康威定律和逆康威定律）
5、基本的監控能力：包括基礎的技術監控和業務監控。
6、快速的應用部署能力：需要部署管道提供快速的部署能力。
7、DevOps 自動化運維能力：需要具有良好的持續集成和持續交付能力，還需要對問題、故障的快速響應能力，開發、測試和運維能協同工作。
2 微服務顆粒的拆分策略
前面兩篇文章我們學習了What & Why（什麼是微服務和為什麼需要做微服務架構），這一章我們就來探討如何做微服務架構的拆分（How）。
微服務拆分沒有一個絕對的標準答案，服務拆分的粒度需要根據業務場景來規劃，而隨著業務的發展，原先的架構方案也需要做調整。
雖然沒有固定的套路，但是我們在業務實踐過程中總結的一些經驗，以做參考。
2.1 基於業務邏輯拆分
基於業務邏輯拆分相對好理解一點，典型的單一職責原則，我們將功能相近的業務整合到一個服務顆粒上。比如一個辦公領域系統，考勤、工作流、音視頻會議是是三個截然不同的業務領域，這可能就是我們拆分的一個入手點。
2.1.1 領域模型拆分
領域驅動設計DDD（Domain-Driven Design 領域驅動設計）是一個很簡單的概念，表示我們對系統的劃分是基於領域的，也即是基於業務方向去思考的。
舉一個典型的電商業務例子。電商的業務體系龐大，涉及各方面的細節。但是我們大概能夠根據業務的職能做一個拆分，比如阿里的電商中台業務，包含 用戶帳號子系統、商品子系統、訂單子系統、客戶子系統、物流子系統 等。
因為職能不同，這些領域之間包含清晰的界限，所以我們可以按照這個方向將服務於不同領域（商品域和訂單域）的子系統拆成獨立的服務顆粒。如下圖：
2.1.2 用戶群體拆分
根據用戶群體做拆分，我們首先要了解自己的系統業務里的用戶角色領域是否沒有功能耦合，有清晰的領域界限。
比如教育信息化系統，教師的業務場景和學生的業務場景，基本比較獨立，而且拆分後流量上有明顯的削弱，這時候結合具體的業務分析，看是否有價值。如下圖所示：
2.2 基於可擴展拆分
這個需要區分系統中變與不變的部分，不變的部分一般是成熟的、通用的服務功能，變的部分一般是改動比較多、滿足業務疊代擴展性需要的功能，我們可以將不變的部分拆分出來，作為共用的服務，將變的部分獨立出來滿足個性化擴展需要。
同時根據二八原則，系統中經常變動的部分大約只占 20%，而剩下的 80% 基本不變或極少變化，這樣的拆分也解決了發布頻率過多而影響成熟服務穩定性的問題。
比如一個電商領域的系統，用戶信息、基本商品信息、物流信息 等模塊的管理能力和視圖界面，一般是比較穩定的；而類似運營活動的功能和頁面一般是經常變化的（520、618、雙11），會有不同的活動策略和視圖界面，需要經常疊代發布。如下圖所示
2.3 基於可靠性拆分
2.3.1 核心模塊拆分
我們團隊在做MySQL資料庫和Redis集群拆分的時候，總會把一些重要的模塊獨立放在一個集群上，不與其他模塊混用，而這個獨立的集群，服務機性能要是最好的。這樣做的目的是，當重要度較低的模塊發生故障時，不會影響重要度高的模塊。
同要的道理，我們會將 帳號信息、登錄信息、服務中心等重要度最高的要害模塊單獨拆分在一個服務顆粒上（因為這類模塊不可用之後，整個系統基本完全癱瘓），再做成服務集群，來保障它的高可用。 如下圖所示：
2.3.2 主次鏈路拆分
在各個業務系統中，其實都會有主次業務鏈路。主業務鏈條，完成了業務系統中最核心的那部分工作。而次鏈路是保證其他基礎功能的穩定運行。
以電商為例子：商品搜索->商品詳情頁->購物車模塊->訂單結算->支付業務，就是一條最簡單的主鏈路。主鏈路是整個系統的核心主戰場，最好的資源跟火力都要放在這裡，保證不失守。
一個系統一般有多條核心鏈路和多條次鏈路，互相支持構成一個完整的系統。而我們將主次鏈路進行拆分，主要為了以下幾個目標。
異常容錯
為主鏈路建立層次化的降級策略（多級降級），以及合理的熔斷策略，這部分我們將在Hystrix服務容錯降級的文章中詳細解釋。
計算資源分配
主鏈路通常來講都是高頻場景，自然需要更多的計算資源，最主要的體現就是集群里分配的虛機數量多。比如電商場景中特惠專場搶購等。
但是無論是虛機的分配，還是kubernetes的動態擴縮容，應該都需要單獨優待，如資源分配傾斜，獨立治理等。
服務隔離
主鏈路是高頻且核心的主業務模塊，把主鏈路的服務與其他起輔助作用的業務服務隔離開來，避免次鏈路服務的異常情況影響到主鏈路服務。
2.4 基於性能需求拆分
根據性能需求來進行拆分。簡單來說就是訪問量特別大，訪問頻率特別高的業務，又要保證高效的響應能力，這些業務對性能的要求特別高。比如積分競拍、低價秒殺、限量搶購。
我們要識別出某些超高並發量的業務，儘可能把這部分業務獨立拆分出來。這麼做的原因非常簡單，一個保證滿足高性能業務需求，另一個保證業務的獨立性，不互相影響。
類似積分競拍、超低價秒殺、限量搶購，對瞬間峰值和計算性能要求是非常高的。這部分的業務如果跟其他通用業務放在一塊，一個是可能互相影響，比如某個鏈路阻塞，會導致雪崩沿調用鏈向上傳遞。
另外一個是如果多個業務耦合在一塊，發布頻率變高、服務擴縮容變難、維護複雜度變高。
3 總結拆分原則
- 先少後多（微服務數量）、先粗後細(粒度)
- 基於業務邏輯進行拆分（用戶群體、業務領域等模型）
- 基於可靠性（核心模塊獨立化、主次鏈路隔離）
- 基於性能拆分（獨立拆分高性能場景）
- 接口需保證冪等
- 接口數據定義嚴禁內嵌，透傳
- 規範化工程結構，符合微服務風格
- 不止對計算服務記性拆分，服務層 -> 緩存層 -> 數據層 的逐步拆解，才能發揮最大功效。