一、AKF拆分原則

　　業界對于可擴展系統架構設計有一個樸素的理念：通過加機器就可以解決容量和可用性問題。

　　這一理念在云計算概念瘋狂流行的今天，得到了廣泛的認可，對于一個規模迅速增長的系統而言，容量和性能問題當然是首當其沖的。但隨著時間的向前，系統規模的增長，除了面對性能與容量的問題外，還要面對功能與模塊數量上的增長帶來的系統復雜性問題以及業務的變化帶來的提供差異化服務的問題。

　　然而許多系統在架構設計時為充分考慮這些問題，導致系統重構成為常態，而影響業務交付能力，還浪費人力財力。對此《可擴展藝術》一書提出了一個系統可擴展模型--AKF可擴展立方（Scalability Cube）。

1，Y軸（功能）關注應用中功能劃分，基于不同的業務拆分

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

、

　　但通過上圖可以發現，當服務數量增多時，服務調用關系變得復雜，為系統添加一個新功能，要調用的服務數變得不可控，由此引發了服務管理上的混亂，所以一般情況下，需要采用服務注冊的機制形成服務網關來進行服務治理

2，X軸（水平擴展）關注水平擴展，也就是“加速器解決問題”

　　X軸擴展與我們前面樸素理念是一致的，通過絕對平等的復制服務與數據，以解決容量與可用性的問題，其實就是將微服務運行多個實例，做集群加負載均衡的模式。

　　為了提升單個服務的可用性與容量，對每一個服務進行X軸擴展劃分。

3，Z軸（數據分區）關注服務與數據的優先級劃分，如按地域劃分

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

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

1，單元化架構

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

2，數據分區

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

　　數據類型：如業務類型

　　數據范圍：如時間段、用戶ID

　　數據熱度：如用戶活躍度、商品熱度

　　按讀寫分：如商品描述、商品庫存

二、前后端分離原則

　　何為前后端分離？前后端本來不就是分離的嗎？這要從jsp開始講起。分工精細化從來都是蛋糕做大的原則，多個領域工程師最好在不需要接觸其他領域知識的情況下合作，才能使效率越來越高，維護也會變得簡單。jsp的模板技術融合了html和java代碼，使得傳統MVC開發中的前后端如膠似漆，前端做好頁面，后端轉成模板，發現問題再找前端，前端又看不懂java代碼，前后端分離的目的就是打破這尷尬的局面，我們需要的是一個全能的團隊，而不是一個個全能的人。

　　前后端分離原則，簡單的將就是前端和后端的代碼分離，我們推薦的模式是最好采用物理分離的方式部署，進一步促使更徹底的分離。如果繼續使用服務端模板技術，如jsp，把java、js、css、html都堆到一個頁面里，稍微復雜一點的頁面就無法維護了。

這種前后端分離有幾個好處：

1，前后端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前端的用戶體驗會更好。

2，分離模式下，前后端交互界面更清晰，就剩下接口模型，后端接口簡介明了，更易于維護。

3，前端多渠道繼承場景更容易實現，后端服務無需變更，采用統一的數據和模型，可以支持多個前端，例如：微信h5前端、PC前端、安卓前端、IOS前端。

三、無狀態服務

　　對于無狀態服務，首先說一下什么是狀態：如果一個數據需要被多個服務共享，才能完成一筆交易，那么這個數據被稱為狀態。進而依賴這個狀態的服務被稱為有狀態的服務，反之成為無狀態服務。

　　這個無狀態服務原則并不是說在微服務架構里不允許存在狀態，表達的真實意思就是要把有狀態的業務服務改變為無狀態的計算類服務，那么狀態數據也就相應的遷移到對應的“有狀態數據服務”中。

　　場景說明：例如我們從前在本地內存中建立的數據緩存、Session緩存，到現在微服務架構中就應該把數據遷移到分布式緩存中存儲，讓業務服務變成一個無狀態的計算節點。遷移后，就可以做到按需動態伸縮，微服務應用在運行時動態增刪節點，就不再需要考慮緩存數據如何同步的問題。

四、RestFul通訊風格

　　這里介紹一個“無狀態通訊原則”-Restful通訊風格，它有許多優點：

1，無狀態協議HTTP，具備先天優勢，擴展能力強，例如安全加密有成熟的https。

2，JSON報文序列化，輕量簡單，人與機均可讀，學習成本低，搜索引擎友好。

3，語言無關，各大熱門語言都提供成熟的Restful API框架，相對一些其他RPC框架生態更加完善。

轉載于:https://www.cnblogs.com/guanghe/p/10978349.html

總結

以上是生活随笔為你收集整理的微服务设计、拆分原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。