一 前言
微服務是一種架構風格。一個大型的複雜軟體應用，由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好的完成該任務。那麼關于微服務的設計原則有哪些呢？如下:
- AKF 拆分原則
- 前後端分離原則
- 無狀态服務
- RestFul 的通信風格
二 AKF 拆分原則
有句挺流行的話:沒有什麼事是一頓燒烤解決不了的，如果有，那就兩頓....。這跟我們之前設計可擴充的系統架構的理念很相像，
通過加機器就可以解決容量和可用性問題 。( 如果一台不行那就兩台) 。這個理念在目前也得到了廣泛的認可！對于一個規模迅速增長的系統而言，容量和性能問題當然是首當其沖的。但是随着現在業務的更疊不窮以及功能子產品的不斷拓展，許多系統在設計的時候并沒有充分考慮到這一點，是以如果架構重設，必然會導緻财力跟人力的浪費。對此，《可擴充的藝術》一書提出了一
個更加系統的可擴充模型—— AKF 可擴充立方（Scalability Cube）。這個立方體中沿着三個坐标軸設定分别為：X、Y、Z。
- Y 軸(功能) —— 關注應用中功能劃分，基于不同的業務拆分
- X 軸(水準擴充) —— 關注水準擴充，也就是”加機器解決問題”
- Z 軸(資料分區) —— 關注服務和資料的優先級劃分，如按地域劃分
2.1 Y 軸（功能）
Y 軸擴充會将龐大的整體應用拆分為多個服務。每個服務實作一組相關的功能，如訂單管理、客戶管理等。在工程上常見的方案是 服務化架構(SOA) 。比如對于一個電子商務平台，我們可以拆分成不同的服務，組成下面這樣的架構：
但通過觀察上圖容易發現，當服務數量增多時，服務調用關系變得複雜。為系統添加一個新功能，要調用的服務數也變得不可控，由此引發了服務管理上的混亂。是以，一般情況下，需要采用服務注冊的機制形成服務網關來進行服務治理。系統的架構将變成下圖所示：
2.2 X 軸(水準擴充)
X 軸擴充與我們前面樸素理念是一緻的，通過絕對平等地複制服務與資料，以解決容量和可用性的問題。其實就是将微服務運作多個執行個體，做叢集加負載均衡的模式。為了提升單個服務的可用性和容量， 對每一個服務進行 X 軸擴充劃分
2.3 Z 軸( 資料分區)
Z 軸擴充通常是指基于請求者或使用者獨特的需求，進行系統劃分，并使得劃分出來的子系統是互相隔離但又是完整的。以生産汽車的工廠來舉例：福特公司為了發展在中國的業務，或者利用中國的廉價勞動力，在中國建立一個完整的子工廠，與美國工廠一樣，負責完整的汽車生産。這就是一種 Z 軸擴充。
工程領域常見的 Z 軸擴充有以下兩種方案：
1.單元化架構
在分布式服務設計領域，一個單元（Cell）就是滿足某個分區所有業務操作的自包含閉環。如上面我們說到的 Y 軸擴充的 SOA 架構，用戶端對服務端節點的選擇一般是随機的，但是，如果在此加上 Z 軸擴充，那服務節點的選擇将不再是随機的了，而是每個單元自成一體。如下圖：
2 資料分區
為了性能資料安全上的考慮，我們将一個完整的資料集按一定的次元劃分出不同的子集。 一個分區（Shard），就是是整體資料集的一個子集。比如用尾号來劃分使用者，那同樣尾号的那部分使用者就可以認為是一個分區。資料分區為一般包括以下幾種資料劃分的方式：
資料類型（如：業務類型）
資料範圍（如：時間段，使用者 ID）
資料熱度（如：使用者活躍度，商品熱度）
按讀寫分（如：商品描述，商品庫存）
舉個例子:比如美團，滴滴遍布全國，各個城市的業務進展不太一樣，是以可以根據城市來進行資料分區。
三 前後端分離原則
這個我們應該很常見，前端做前端的事情，後端做後端的業務子產品，分工更加明确。
那麼前後段分離有什麼好處呢?
這種分離方式有幾個好處：
- 前後端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前段的使用者體驗優化效果更好。
- 分離模式下，前後端互動界面更清晰，就剩下了接口模型，後端的接口簡潔明了，更容易維護。
- 前端多管道內建場景更容易實作，後端服務無需變更，采用統一的資料和模型，可以支援多個前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。
四 無狀态服務
什麼是狀态？
如果一個資料需要被多個服務共享，才能完成一筆交易，那麼這個資料被稱為狀态。進而依賴這個“狀态”資料的服務被稱為有狀态服務，反之稱為無狀态服務。更好的說明見下圖：
場景說明：例如我們以前在本地記憶體中建立的資料緩存、Session 緩存，到現在的微服務架構中就應該把這些資料遷移到分布式緩存中存儲，讓業務服務變成一個無狀态的計算節點。遷移後，就可以做到按需動态伸縮，微服務應用在運作時動态增删節點，就不再需要考慮緩存資料如何同步的問題。這樣對于業務的拓展起到了至關重要的作用
五 RestFul通訊風格
作為一個原則來講本來應該是個“無狀态通信原則”，在這裡我們直接推薦一個實踐優選的 Restful 通信風格 ，因為他有很多好處：
- 無狀态協定 HTTP，具備先天優勢，擴充能力很強。例如需要安全加密，有現成的成熟方案 HTTPS 即可。
- JSON 封包序列化，輕量簡單，人與機器均可讀，學習成本低，搜尋引擎友好。
- 語言無關，各大熱門語言都提供成熟的 Restful API 架構，相對其他的一些RPC 架構生态更完善。