一 前言

微服務(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 拆分原則

有句挺流行的話:沒有什么事是一頓燒烤解決不了的，如果有，那就兩頓....。這跟我們之前設(shè)計(jì)可擴(kuò)展的系統(tǒng)架構(gòu)的理念很相像，通過加機(jī)器就可以解決容量和可用性問題 。( 如果一臺不行那就兩臺) 。這個(gè)理念在當(dāng)前也得到了廣泛的認(rèn)可！對于一個(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)。對此，《可擴(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ù)拆分

Y 軸擴(kuò)展會(huì)將龐大的整體應(yīng)用拆分為多個(gè)服務(wù)。每個(gè)服務(wù)實(shí)現(xiàn)一組相關(guān)的功能，如訂單管理、客戶管理等。在工程上常見的方案是 服務(wù)化架構(gòu)(SOA) 。比如對于一個(gè)電子商務(wù)平臺，我們可以拆分成不同的服務(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ù)注冊的機(jī)制形成服務(wù)網(wǎng)關(guān)來進(jìn)行服務(wù)治理。系統(tǒng)的架構(gòu)將變成下圖所示：

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

Z 軸擴(kuò)展通常是指基于請求者或用戶獨(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)，客戶端對服務(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è)子集。比如用尾號來劃分用戶，那同樣尾號的那部分用戶就可以認(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ù)模塊，分工更加明確。

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

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

• 前后端技術(shù)分離，可以由各自的專家來對各自的領(lǐng)域進(jìn)行優(yōu)化，這樣前段的用戶體驗(yàn)優(yōu)化效果更好。

• 分離模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口簡潔明了，更容易維護(hù)。

• 前端多渠道集成場景更容易實(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ù)。更好的說明見下圖：

場景說明：例如我們以前在本地內(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ù)如何同步的問題。這樣對于業(yè)務(wù)的拓展起到了至關(guān)重要的作用

五 RestFul通訊風(fēng)格

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

• 無狀態(tài)協(xié)議 HTTP，具備先天優(yōu)勢，擴(kuò)展能力很強(qiáng)。例如需要安全加密，有現(xiàn)成的成熟方案 HTTPS 即可。

• JSON 報(bào)文序列化，輕量簡單，人與機(jī)器均可讀，學(xué)習(xí)成本低，搜索引擎友好。

• 語言無關(guān)，各大熱門語言都提供成熟的 Restful API 框架，相對其他的一些 RPC 框架生態(tài)更完善。