微服務的設計原則
AKF原則
業界對於可擴展的系統架構設計有一個樸素的理念,就是：通過加機器就可以解決容量和可用性問題。(如果一臺不行那就兩臺)。(世界上沒有什麼事是一頓燒烤不能解決的。如果有，那就兩頓。）
這一理念在“雲計算”概念瘋狂流行的今天，得到了廣泛的認可！於一個規模迅速增長的系統而言，容量和性能問題當然是首當其衝的。但是隨着時間的向前，系統規模的增長，除了面對性能與容量的問題外，還需要面對功能與模塊數量上的增長帶來的系統複雜性問題以及業務的變化帶來的提供差異化服務問題。而許多系統，在架構設計時並未充分考慮到這些問題，導致系統的重構成爲常態，從而影響業務交付能力，還浪費人力財力！對此，《可擴展的藝術》一書提出了一個更加系統的可擴展模型—— AKF 可擴展立方 （Scalability Cube）。這個立方體中沿着三個座標軸設置分別爲：X、Y、Z。
Y 軸(功能) —— 關注應用中功能劃分，基於不同的業務拆分
X 軸(水平擴展) —— 關注水平擴展，也就是”加機器解決問題”
Z 軸(數據分區) —— 關注服務和數據的優先級劃分，如按地域劃分
Y軸(功能)
Y 軸擴展會將龐大的整體應用拆分爲多個服務。每個服務實現一組相關的功能，如訂單管理、客戶管理等。在工程上常見的方案是 服務化架構(SOA) 。比如對於一個電子商務平臺，我們可以拆分成不同的服務，組成下面這樣的架構：
但通過觀察上圖容易發現，當服務數量增多時，服務調用關係變複雜。爲系統添加一個新功能，要調用的服務數也變得不可控，由此引發了服務管理上的混亂。所以，一般情況下，需要採用服務註冊的機制形成服務網關來進行服務治理。系統的架構將變成下圖所示
X軸(水平擴展)
X 軸擴展與我們前面樸素理念是一致的，通過絕對平等地複製服與數據，以解決容量和可用性的問題。其實就是將微服務運行多個實例，做集羣加負載均衡的模式。爲了提升單個服務的可用性和容量， 對每一個服務進行 X 軸擴展劃分 。
Z軸數據分區
Z 軸擴展通常是指基於請求者或用戶獨特的需求，進行系統劃分並使得劃分出來的子系統是相互隔離但又是完整的。以生產汽車的工廠來舉例：福特公司爲了發展在中國的業務，或者利用中國的廉價勞動力，在中國建立一個完整的子工廠，與美國工廠一樣，負責完整的汽車生產。這就是一種 Z 軸擴展。
工程領域常見的 Z 軸擴展有以下兩種方案
單元化架構
在分佈式服務設計領域，一個單元（Cell）就是滿足某個分區所有業務操作的自包含閉環。如上面我們說到的 Y 軸擴展的 SOA 架構，客戶端對服務端節點的選擇一般是隨機的，但是，如果在此加上 Z 軸擴展，那服務節點的選擇將不再是隨機的了，而是每個單元自成一體。如下圖：
數據分區
爲了性能數據安全上的考慮，我們將一個完整的數據集按一定的度劃分出不同的子集。一個分區（Shard），就是是整體數據集的一個子集。比如用尾號來劃分用戶，那同樣尾號的那部分用戶就可以認爲是一個分區。數據分區爲一般
包括以下幾種數據劃分的方式
數據類型（如：業務類型）
數據範圍（如：時間段，用戶 ID）
數據熱度（如：用戶活躍度，商品熱度）
按讀寫分（如：商品描述，商品庫存）
前後端分離
何爲前後端分離？前後端本來不就分離麼？這要從尷尬的 jsp 講起。分工精細化從來都是蛋糕做大的原則，多個領域工程師最好在不需要接觸其他領域知識的情況下合作，纔可能使效率越來越高，維護也會變得簡單。jsp 的模板技術融合了 html 和 java 代碼，使得傳統MVC 開發中的前後端在這裏如膠似漆，前端做好頁面，後端轉成模板，發現問題再找前端，前端又看不懂 java 代碼…前後端分離的目的就是將這尷尬局面打破。前後端分離原則，簡單來講就是前端和後端的代碼分離，我們推薦的模式是最好採用物理分離的方式部署，進一步促使更徹底的分離。如果繼續直接使用服務端模板技術，如：jsp，把 java、js、html、css 都堆到一個頁面裏，稍微複雜一點的頁面就無法維護了。
這種分離方式有幾個好處：
前後端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前段的用戶體驗優化效果更好。
分離模式下，前後端交互界面更清晰，就剩下了接口模型，後端的接口簡潔明瞭，更容易維護。
前端多渠道集成場景更容易實現，後端服務無需變更，採用統一的數據和模型，可以支持多個前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。
無狀態服務
對於無狀態服務，首先說一下什麼是狀態：如果一個數據需要被多個服務共享，才能完成一筆交易，那麼這個數據被稱爲狀態。進而依賴這個“狀態”數據的服務被稱爲有狀態服務，反之稱爲無狀態服務。那麼這個無狀態服務原則並不是說在微服務架構裏就不允許存在狀態，表達的真實意思是要把有狀態的業務服務改變爲無狀態的計算類服務，那麼狀態數據也就相應的遷移到對應的“有狀態數據服務”中。場景說明：例如我們以前在本地內存中建立的數據緩存、Session 緩存，到現在的微服務架構中就應該把這些數據遷移到分佈式緩存中存儲，讓業務服務變成一個無狀態的計算節點。遷移後，就可以做到按需動態伸縮，微服務應用在運行時動態增刪節點，就不再需要考慮緩存數據如何同步的問題。
RestFul通訊風格
作爲一個原則來講本來應該是個“無狀態通信原則”，在這裏我們直接推薦一個實踐優選的Restful 通信風格 ，因爲他有很多好處：
無狀態協議HTTP，具備先天優勢，擴展能力很強。例如需要安全加密是，有現成的成熟方案HTTPS可用。
JSON 報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜索引擎友好。
語言無關，各大熱門語言都提供成熟的Restful API框架，相對其他的一些RPC框架生態更完善。
當然在有些特殊業務場景下，也需要採用其他的RPC框架，如thrift、avro-rpc、grpc。但絕大多數情況下Restful就足夠用了。
~將這幾個原則多加理解有助於我們後面對項目的分析與理解
這裏向你推薦這套微服務架構之Spring Cloud Alibaba底層原理實戰，由前萬物雲聯TeamLeader、前先鋒金融技術經理、P8級分佈式系統中間件架構師結合13年一線大廠實踐經驗，打造的《Spring Cloud Alibaba 深度剖析底層原理集訓營》在線課程。3 天時間，三個系統章節、20餘個技術知識點，涵蓋微服務各大組件，深入組件中的底層原理涉及，帶你從業務價值角度，徹底看透微服務底層原理的本質。
名額僅前 100 人有效，先到先得！
3、課程模塊
直播概覽
Day01 縱覽微服務架構體系上帝視角論微服務架構下的解決方案
Day02 抽絲剝繭Spring Cloud Alibaba之註冊中心
Day03 高併發下微服務限流原理
課程大綱：
名額僅前 100 人有效，先到先得！
本文分享自微信公衆號 - JAVA高級架構（gaojijiagou）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。