微服務設計的四個原則

業界對於可擴充套件的系統架構設計有一個樸素的理念,就是：通過加機器就可以解決容量和可用性問題。(如果一臺不行那就兩臺)。(世界上沒有什麼事是一頓燒烤不能解決的。如果有，那就兩頓。）

這一理念在“雲端計算”概念瘋狂流行的今天，得到了廣泛的認可！於一個規模迅速增長的系統而言，容量和效能問題當然是首當其衝的。但是隨著時間的向前，系統規模的增長，除了面對效能與容量的問題外，還需要面對功能與模組數量上的增長帶來的系統複雜性問題以及業務的變化帶來的提供差異化服務問題。而許多系統，在架構設計時並未充分考慮到這些問題，導致系統的重構成為常態，從而影響業務交付能力，還浪費人力財力！對此，《可擴充套件的藝術》一書提出了一個更加系統的可擴充套件模型—— AKF 可擴充套件立方 （Scalability Cube）。這個立方體中沿著三個座標軸設定分別為：X、Y、Z。

Y 軸(功能) —— 關注應用中功能劃分，基於不同的業務拆分

X 軸(水平擴充套件) —— 關注水平擴充套件，也就是”加機器解決問題”

Z 軸(資料分割槽) —— 關注服務和資料的優先順序劃分，如按地域劃分

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

但通過觀察上圖容易發現，當服務數量增多時，服務呼叫關係變複雜。為系統新增一個新功能，要呼叫的服務數也變得不可控，由此引發了服務管理上的混亂。所以，一般情況下，需要採用服務註冊的機制形成服務閘道器來進行服務治理。系統的架構將變成下圖所示

X 軸擴充套件與我們前面樸素理念是一致的，通過絕對平等地複製服與資料，以解決容量和可用性的問題。其實就是將微服務執行多個例項，做叢集加負載均衡的模式。為了提升單個服務的可用性和容量， 對每一個服務進行 X 軸擴充套件劃分 。

在分散式服務設計領域，一個單元（Cell）就是滿足某個分割槽所有業務操作的自包含閉環。如上面我們說到的 Y 軸擴充套件的 SOA 架構，客戶端對服務端節點的選擇一般是隨機的，但是，如果在此加上 Z 軸擴充套件，那服務節點的選擇將不再是隨機的了，而是每個單元自成一體。如下圖：

何為前後端分離？前後端本來不就分離麼？這要從尷尬的 jsp 講起。分工精細化從來都是蛋糕做大的原則，多個領域工程師最好在不需要接觸其他領域知識的情況下合作，才可能使效率越來越高，維護也會變得簡單。jsp 的模板技術融合了 html 和 java 程式碼，使得傳統MVC 開發中的前後端在這裡如膠似漆，前端做好頁面，後端轉成模板，發現問題再找前端，前端又看不懂 java 程式碼......前後端分離的目的就是將這尷尬局面打破。前後端分離原則，簡單來講就是前端和後端的程式碼分離，我們推薦的模式是最好採用物理分離的方式部署，進一步促使更徹底的分離。如果繼續直接使用服務端模板技術，如：jsp，把 java、js、html、css 都堆到一個頁面裡，稍微複雜一點的頁面就無法維護了。

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

1) 前後端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前段的使用者體驗優化效果更好。

2) 分離模式下，前後端互動介面更清晰，就剩下了介面模型，後端的介面簡潔明瞭，更容易維護。

3) 前端多渠道整合場景更容易實現，後端服務無需變更，採用統一的資料和模型，可以支援多個前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。