目錄
一、AKF拆分原則
1，Y軸（功能）關注應用中功能劃分，基于不同的業務拆分
2，X軸（水準擴充）關注水準擴充，也就是“加速器解決問題”
3，Z軸（資料分區）關注服務與資料的優先級劃分，如按地域劃分
二、前後端分離原則
三、無狀态服務原則
四、RestFul 通訊風格
五、現狀思考
一、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架構生态更加完善。
五、現狀思考
目前我們的業務架構中已有幾十種服務，每一種服務之間的調用也是盤根錯雜，雖然已有服務注冊中心，有網關進行路由，但是服務根據業務拆分的比較細，一些根據業務獨立的服務又根據子業務進行Y軸拆分也是比較細，針對X軸的拆分，我們也在嘗試，其實這裡根據X軸的實作，不是拆分了，而是為了高可用，提升性能，進行的一個服務擴充，多執行個體部署；在我們對一些定制化的服務的時候，也是需要Z軸的一個拆分，為定制化的需求，單獨部署一整套的服務來實作，與其他服務完全隔離開來。
在服務越來越多的時候，瓶頸就在于網關，其他的服務都可以部署成非單點的模式，哪怕某個服務執行個體停止了服務，其他執行個體也可以頂上來，但是網關是千萬不能出問題的，包括我們現在用的nginx再最外層還進行了一層網關路由，這裡的nginx和zuul一定是重中之重。