一、前言

微服務是一種架構風格。一個大型的復雜軟件應用，由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好的完成該任務。那么關于微服務的設計原則有哪些呢？如下:

• 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）
• 數據熱度（如：用戶活躍度，商品熱度）
• 按讀寫分（如：商品描述，商品庫存）

舉個例子:比如美團，滴滴遍布全國，各個城市的業務進展不太一樣，所以可以根據城市來進行數據分區。

三、前后端分離原則

這個我們應該很常見，前端做前端的事情，后端做后端的業務模塊，分工更加明確。

圖片

何為前后端分離？前后端本來不就分離么？分工精細化從來都是蛋糕做大的原則，多個領域工程師最好在不需要接觸其他領域知識的情況下合作，才可能使效率越來越高，維護也會變得簡單。

前后端分離原則，簡單來講就是前端和后端的代碼分離，我們推薦的模式是最好采用物

理分離的方式部署，進一步促使更徹底的分離。如果繼續直接使用服務端模板技術，如：jsp，把 java、js、html、css 都堆到一個頁面里，稍微復雜一點的頁面就無法維護了。

圖片

那么前后段分離有什么好處呢?

這種分離方式有幾個好處：

• 前后端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前段的用戶體驗優化效果更好。
• 分離模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口簡潔明了，更容易維護。
• 前端多渠道集成場景更容易實現，后端服務無需變更，采用統一的數據和模型，可以支持多個前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。

四、無狀態服務

什么是狀態？

如果一個數據需要被多個服務共享，才能完成一筆交易，那么這個數據被稱為狀態。進而依賴這個“狀態”數據的服務被稱為有狀態服務，反之稱為無狀態服務。更好的說明見下圖：

圖片

場景說明：例如我們以前在本地內存中建立的數據緩存、Session 緩存，到現在的微服務架構中就應該把這些數據遷移到分布式緩存中存儲，讓業務服務變成一個無狀態的計算節點。

遷移后，就可以做到按需動態伸縮，微服務應用在運行時動態增刪節點，就不再需要考慮緩存數據如何同步的問題。這樣對于業務的拓展起到了至關重要的作用

五、RestFul通訊風格

作為一個原則來講本來應該是個“無狀態通信原則”，在這里我們直接推薦一個實踐優選的 Restful 通信風格 ，因為他有很多好處：

• 無狀態協議 HTTP，具備先天優勢，擴展能力很強。例如需要安全加密，有現成的成熟方案 HTTPS 即可。
• JSON 報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜索引擎友好。
• 語言無關，各大熱門語言都提供成熟的 Restful API 框架，相對其他的一些RPC 框架生態更完善。