一、前言

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

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

二、AKF 拆分原則

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

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

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

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

圖片

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

2.1  Y  軸（功能）

Y 軸擴(kuò)展會(huì)將龐大的整體應(yīng)用拆分為多個(gè)服務(wù)。每個(gè)服務(wù)實(shí)現(xiàn)一組相關(guān)的功能，如訂單管理、客戶管理等。在工程上常見的方案是  服務(wù)化架構(gòu)(SOA) 。比如對(duì)于一個(gè)電子商務(wù)平臺(tái)，我們可以拆分成不同的服務(wù)，組成下面這樣的架構(gòu)：

圖片

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

圖片

2.2 X 軸(水平擴(kuò)展)

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

圖片

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

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

工程領(lǐng)域常見的 Z  軸擴(kuò)展有以下兩種方案：

1.單元化架構(gòu)

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

圖片

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

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

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

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

三、前后端分離原則

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

圖片

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

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

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

圖片

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

這種分離方式有幾個(gè)好處：

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

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

什么是狀態(tài)？

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

圖片

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

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

五、RestFul通訊風(fēng)格

作為一個(gè)原則來講本來應(yīng)該是個(gè)“無狀態(tài)通信原則”，在這里我們直接推薦一個(gè)實(shí)踐優(yōu)選的 Restful 通信風(fēng)格 ，因?yàn)樗泻芏嗪锰帲?/span>

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