一、前言

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

• AKF 拆分原則
• 前后端分離原則
• 無狀態(tài)服務
• RestFul 的通信風格

二、AKF 拆分原則

業(yè)界對于可擴展的系統(tǒng)架構設計有一個樸素的理念,就是：通過加機器就可以解決容量和可用性問題。(如果一臺不行那就兩臺)。

我是個段子：（世界上沒有什么事是一頓燒烤不能解決的。如果有，那就兩頓。）

這跟我們之前設計可擴展的系統(tǒng)架構的理念很相像，通過加機器就可以解決容量和可用性問題 。( 如果一臺不行那就兩臺) 。這個理念在當前也得到了廣泛的認可！對于一個規(guī)模迅速增長的系統(tǒng)而言，容量和性能問題當然是首當其沖的。

但是隨著現(xiàn)在業(yè)務的更迭不窮以及功能模塊的不斷拓展，許多系統(tǒng)在設計的時候并沒有充分考慮到這一點，所以如果架構重設，必然會導致財力跟人力的浪費。對此，《可擴展的藝術》一書提出了一個更加系統(tǒng)的可擴展模型—— AKF  可擴展立方（Scalability Cube）。這個立方體中沿著三個坐標軸設置分別為：X、Y、Z。

圖片

• Y 軸(功能) —— 關注應用中功能劃分，基于不同的業(yè)務拆分
• X 軸(水平擴展) —— 關注水平擴展，也就是”加機器解決問題”
• Z 軸(數(shù)據(jù)分區(qū)) —— 關注服務和數(shù)據(jù)的優(yōu)先級劃分，如按地域劃分

2.1  Y  軸（功能）

Y 軸擴展會將龐大的整體應用拆分為多個服務。每個服務實現(xiàn)一組相關的功能，如訂單管理、客戶管理等。在工程上常見的方案是  服務化架構(SOA) 。比如對于一個電子商務平臺，我們可以拆分成不同的服務，組成下面這樣的架構：

圖片

但通過觀察上圖容易發(fā)現(xiàn)，當服務數(shù)量增多時，服務調用關系變得復雜。為系統(tǒng)添加一個新功能，要調用的服務數(shù)也變得不可控，由此引發(fā)了服務管理上的混亂。所以，一般情況下，需要采用服務注冊的機制形成服務網(wǎng)關來進行服務治理。系統(tǒng)的架構將變成下圖所示：

圖片

2.2 X 軸(水平擴展)

X 軸擴展與我們前面樸素理念是一致的，通過絕對平等地復制服務與數(shù)據(jù)，以解決容量和可用性的問題。其實就是將微服務運行多個實例，做集群加負載均衡的模式。為了提升單個服務的可用性和容量，  對每一個服務進行 X  軸擴展劃分

圖片

2.3  Z  軸( 數(shù)據(jù)分區(qū))

Z 軸擴展通常是指基于請求者或用戶獨特的需求，進行系統(tǒng)劃分，并使得劃分出來的子系統(tǒng)是相互隔離但又是完整的。以生產汽車的工廠來舉例：福特公司為了發(fā)展在中國的業(yè)務，或者利用中國的廉價勞動力，在中國建立一個完整的子工廠，與美國工廠一樣，負責完整的汽車生產。這就是一種 Z 軸擴展。

工程領域常見的 Z  軸擴展有以下兩種方案：

1.單元化架構

在分布式服務設計領域，一個單元（Cell）就是滿足某個分區(qū)所有業(yè)務操作的自包含閉環(huán)。如上面我們說到的 Y 軸擴展的 SOA 架構，客戶端對服務端節(jié)點的選擇一般是隨機的，但是，如果在此加上 Z 軸擴展，那服務節(jié)點的選擇將不再是隨機的了，而是每個單元自成一體。如下圖：

圖片

2.數(shù)據(jù)分區(qū)

為了性能數(shù)據(jù)安全上的考慮，我們將一個完整的數(shù)據(jù)集按一定的維度劃分出不同的子集。一個分區(qū)（Shard），就是是整體數(shù)據(jù)集的一個子集。比如用尾號來劃分用戶，那同樣尾號的那部分用戶就可以認為是一個分區(qū)。數(shù)據(jù)分區(qū)為一般包括以下幾種數(shù)據(jù)劃分的方式：

• 數(shù)據(jù)類型（如：業(yè)務類型）
• 數(shù)據(jù)范圍（如：時間段，用戶 ID）
• 數(shù)據(jù)熱度（如：用戶活躍度，商品熱度）
• 按讀寫分（如：商品描述，商品庫存）

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

三、前后端分離原則

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

圖片

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

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

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

圖片

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

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

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

四、無狀態(tài)服務

什么是狀態(tài)？

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

圖片

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

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

五、RestFul通訊風格

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

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