微服務架構并無標準架構，不然什么架構師大會也不會各個系統(tǒng)架構百花齊放了。雖然沒有固定的套路，卻有一些經(jīng)驗，今天就來做一個總結。

基于角色拆分

這種拆分方式常見于基礎設施以及其PaaS層的架構，比如服務治理、k8s、kafka。所謂基礎組件的PaaS層是說，基礎設施本身主要作為基礎設施使用，是IaaS層。但是基礎設施本身需要維護功能，需要增刪改查等運維操作。業(yè)界基于開源做的二次開發(fā)也著重在做這方面的工作。

下面以kafka做說明。因為要上升到PaaS層，下圖基于美團對kafka的二次開發(fā)封裝，產(chǎn)品名叫mafka。

咱們直接看★標注的部分mafka-manager，這個就是運維操作統(tǒng)一管理端。充當?shù)木褪枪芾碚叩慕巧?。再看看kafka其他組件的名稱：生產(chǎn)者( producer )、消費者( consumer )、經(jīng)紀人( broker )。核查員( monitor )。架構的組織都是根據(jù)角色來來劃分的。

為什么我要將mafka-manager用★標注呢。因為不管是基礎設施還是別的，以產(chǎn)品化的觀點，需要對外提供一個完整的產(chǎn)品體驗。完整的產(chǎn)品包含什么呢？統(tǒng)一的產(chǎn)品外觀、統(tǒng)一的接口定義、統(tǒng)一的服務運營。

我們要接入mafka，雖然最終程序里要用的是生產(chǎn)者、消費者這些，但是第一步都要在mafka-manager對應的界面上申請。mafka-manager類似于網(wǎng)關入口的角色。業(yè)界有專門把這些接口服務抽象出來叫做api網(wǎng)關。

在k8s架構中，api網(wǎng)關這個概念更加明顯一些。

kubectl是k8s的控制臺命令交互界面、web UI是瀏覽器交互界面，不同的交互界面會走統(tǒng)一的api server。這里api server就是api網(wǎng)關服務。

基于可擴展性拆分

首先來了解一下AKF擴展立方體。

AKF擴展立方體（Scalability Cube），是《架構即未來》一書中提出的可擴展模型，這個立方體有三個軸線，每個軸線描述擴展性的一個維度：

X軸 —— 代表無差別的克隆服務和數(shù)據(jù)，工作可以很均勻的分散在不同的服務實例上；

Y軸 —— 關注應用中職責的劃分，比如數(shù)據(jù)類型，交易執(zhí)行類型的劃分；

Z軸 —— 關注服務和數(shù)據(jù)的優(yōu)先級劃分，如分地域劃分。

白話來說：X軸拆分就是通過加機器水平拆分；Y軸拆分就是按業(yè)務邏輯垂直拆分；Z軸拆分就是按照算法進行分片，這個算法比如按地域，不同地域訪問不同的分片或者服務。

舉個例子，比如一般公司的redis集群會有一個團隊來進行統(tǒng)一維護。redis集群有主有從，數(shù)據(jù)都是一樣的，多副本容災，這是X軸水平的拆分。一個公司很多業(yè)務，redis團隊會對不同的業(yè)務提供不同的集群，這是Y軸垂直拆分；集群內(nèi)部數(shù)據(jù)會通過sharding做分片，這是Z軸算法拆分。

基于穩(wěn)定性拆分

在業(yè)務架構中，通常會通過核心模塊的劃分或者主次鏈路的劃分來進行微服務拆分。

在《三平面分離架構》中，我提到過分離出控制平面、數(shù)據(jù)平面和管理平面。這本質上也是通過核心模塊劃分來進行拆分的一種方式?？刂破脚_一般是核心鏈路，核心數(shù)據(jù)作為控制邏輯的一部分可以通過本地緩存等措施弱依賴于數(shù)據(jù)平面。管理平臺是后臺管理等，用于增刪改查，人工操作時才用，其他時間掛掉都沒關系。

基于資源需求拆分

根據(jù)性能需求來進行拆分。簡單來說就是訪問量特別大，訪問頻率特別高的業(yè)務，又要保證高效的響應能力，這些業(yè)務對性能的要求特別高。比如積分競拍、低價秒殺、限量搶購。

我們要識別出某些超高并發(fā)量的業(yè)務，盡可能把這部分業(yè)務獨立拆分出來。這么做的原因非常簡單，一個保證滿足高性能業(yè)務需求，另一個保證業(yè)務的獨立性，不互相影響。 

類似積分競拍、超低價秒殺、限量搶購，對瞬間峰值和計算性能要求是非常高的。這部分的業(yè)務如果跟其他通用業(yè)務放在一塊，一個是可能互相影響，比如某個鏈路阻塞，會導致雪崩沿調(diào)用鏈向上傳遞。

另外一個是如果多個業(yè)務耦合在一塊，發(fā)布頻率變高、服務擴縮容變難、維護復雜度變高。如下圖例子所示，訂單服務是一個性能要求高的服務，一般會單獨拆分。

總結

咱們實際工作中，通常會發(fā)現(xiàn)一種拆分方式和另一種拆分方式并不沖突。一個完整的架構也不只使用了一種拆分方式。《領域驅動設計(DDD)中簡單易用的10種技巧》也可以配合來使用。

本文提到的api網(wǎng)關嚴格上不是業(yè)務劃分時的一個模塊。業(yè)界通常把api網(wǎng)關作為一個基礎設施。如果在架構圖中包含了api網(wǎng)關通常是下圖所示：

上圖中的架構既包含了業(yè)務邏輯的業(yè)務劃分，也有配置中心、注冊中心這樣的技術劃分?？傮w上來說是一個技術架構圖。而api網(wǎng)關本身也更多被歸為是技術概念，而不是業(yè)務概念。

在《尤娜系統(tǒng)的第一次飛行中換引擎的架構垂直拆分改造》中，首先就拆分出來了api網(wǎng)關層，這說明尤娜要下一盤大棋，最終對外會提供一個統(tǒng)一的產(chǎn)品。