背景
對於現在的微服務架構的應用來說，對大量併發的及時響應是一項制勝能力。據用戶行爲分析平臺統計，隨行付的某一款APP產品每日請求就達到上千萬次用戶請求、加解密服務3000萬次/日等等。這些微服務每時每刻在處理如此高強度的請求，對數據層的應對能力要求極高。如果我們把對速度的需求放在複雜的分佈式數據架構背景下，是很難想象如何讓應用應對如此巨大的數據訪問量的。但很幸運，我們有方法做到。即立方體模型。
立方體模型
可擴展的分佈式系統架構設計有一個樸素的理念，就是：通過加機器就可以解決容量和可用性的問題。
對於一個迅速增長的應用而言，容量和性能是首當其衝要面臨的問題。但隨着時間的向前推移、應用規模不斷的快速增長，除了面對性能與容量的問題外，還需要解決功能與模塊數量上增長帶來的系統複雜性問題、業務變化帶來的差異化服務問題等。而多數情況下應用設計之初出於諸多因素的考量，並沒有充分考慮或在設計之初就將此類問題提上日程，導致系統的重構成爲常態，從而影響業務交付能力。對此，「架構即未來」一書中提出了更加系統的可擴展模型，可擴展模型是一個富有啓發性的方法，描述了微服務三個維度的擴展方法，可以通過它來了解微服務架構的擴展維度。
- X軸：橫向擴展模式，關注水平的數據和服務克隆
- Y軸：功能分解模式，關注應用中的職責的劃分
- Z軸：數據分區模式，關注服務和數據的優先級劃分
X軸擴展
X軸擴展是通過絕對平等的複製服務和數據，以解決容量和可用性的問題。以乘坐火車爲例，因春運高峯集中，乘客人數也是平時時的幾倍、甚至幾十倍。12306爲了提高運力都會採用複製的方法：增加火車數量。增加火車數量有效的提高春運運力、提高乘客出行體驗。
對於軟件工程而言，比如加解密微服務的性能峯值1000TPS，通常我們需要提高TPS，會採取複製加解密服務：增加服務提供者。這就是X軸擴展的一個完美示例，說明了X軸擴展的思路，把工作無偏向的分配給「複製品」，各個「複製品」之間不共享任何內容、能獨立提供服務。而對於軟件技術來講，X軸擴展主要有負載均衡和數據複製兩種技術方式。
負載均衡
負載均衡是將用戶的訪問請求通過負載均衡器，均衡分配到由各個「複製品」組成的集羣中去。當某個「複製品」出現故障，也能輕易地將相應「工作」轉移給其它的複製品來「代爲完成」。常用的硬件負載有F5、A10，軟件負載Nginx。
這中間涉及到的技術點包括了反向代理、DNS輪詢、哈希負載均衡算法（一致性哈希）、動態節點負載均衡（如按CPU，I/O）等。它的難點在於要求集羣中的「複製品」是不共享任何內容，也就是我們常說的無狀態。
數據複製
數據複製是指在數據存儲層進行絕對平等地數據遷移，用於解決存儲層I/O瓶頸以及可用性上的問題。有多個「複製品」存儲，使得每個「複製品」提供無差異的數據服務，我們需要在「複製品」之間同步或異步的複製數據。
數據複製的方式包括了主從同步(讀寫分離)、雙主同步等。因爲數據存儲天生就是有狀態的，數據複製的難點在於如何保證一致性。爲保證一致性，衍生了很多複雜的技術和中間件，比如Paxos選舉算法、隨行付Porter數據同步中間件等。
識別熱點服務
多數情況下我們的應用中都會存在熱點模塊，我們可以理解爲越基礎的模塊越容易成爲熱點模塊。熱點模塊更加容易成爲整個平臺的瓶頸點，所以熱點模塊要儘早的採取擴展措施，擴展措施一般都採用X軸擴展方式。
前後端分離
其實在我們開發過程中，經常會給pc端、mobile、app端各自研發一套前端。其實對於這三端來說，大部分端業務邏輯是一樣的。唯一區別就是交互展現邏輯不同。如果controller層在後端手裏，後端爲了這些不同端頁面展示邏輯，分別維護這些controller，徒增和前端溝通端成本、在擴展性上面也不能達到很方便的擴展。前後端分離的好處在於：
- 提升適配性
- 提升響應速度
- 提升性能(分後端可分別優化)
Y軸擴展
Y軸擴展是根據數據的類型或者交易執行的類型（或者兩者都有）來劃分工作職責。一般稱爲面向服務或面向資源的擴展。
我們再以火車來舉例，12306根據起點和終點的不同，劃分了多條火車線路。每條火車線路的週期歸屬運輸，交付着乘客的出行服務。這樣做的好處是明顯的，每條火車線路的任務更簡單，從而能更高效的提供出行服務。
與火車分工類似，爲了降低系統複雜度，Y軸擴展會將龐大的整體應用拆分爲一組服務。每個服務實現一組相關的功能，如核心交易、風險控制等。而在軟件上常見的方案是服務化架構(SOA)、微服務化架構(Micro Service)。
Z軸擴展
Z軸擴展是指基於請求者或用戶獨特的需求，進行系統劃分，並使得劃分出來的子系統是相互隔離但又是完整的。繼續以火車舉例，12306爲了更好發展業務，交付出行體驗。在中國建立N多個鐵路局，各個鐵路局個行其責，分別提供出行服務。這就是一種Z軸擴展。
對於軟件而言，Z軸擴展一般是爲了滿足差異性的需求、安全隔離而採取的擴展措施。比如，爲了提供VIP用戶服務，可以將系統完整地複製一份出來，與普通用戶所使用的系統完全隔離；針對不同的地域用戶，系統自動切換到對應地域的子系統，爲用戶提供服務，都是Z軸擴展。另外，在系統的灰度部署上，我們也通常使用Z軸擴展來完成。
軟件領域常見的Z軸擴展有以下兩種方案：分離化部署和數據分區。
分離化部署
在分佈式服務設計領域，一個煙筒狀就是滿足某個分區所有業務操作的自包含閉環。如上面我們說到的Y軸擴展的微服務架構，客戶端對服務端節點的選擇一般是隨機的，但是，如果在此加上Z軸擴展，那服務節點的選擇將不再是隨機的了，而是每個煙筒狀自成一體。
數據分區
爲了性能及數據安全考慮，我們將一個完整的數據集按一定的維度劃分出不同的子集。 一個分區（Sharding），就是是整體數據集的一個子集。比如用尾號來劃分用戶，那同樣尾號的那部分用戶就可以認爲是一個分區。數據分區爲一般包括以下幾種數據劃分的方式：
- 數據類型（如，業務類型）
- 數據範圍（如，時間段、用戶）
- 數據熱度（如，用戶活躍度）
- 按讀寫分（如，描述，庫存）
當然，數據分區也是有代價的，它將增加數據運維的難度，關聯搜索的複雜度增加等。
總結
X軸上擴展是平臺或系統的交易量或工作量增長，雖然X軸擴展能夠很好處理交易量的增長，但當系統複雜度的大幅度增加，或用戶數量增加以及差異化服務需求出現，X軸擴展就難以應付了。但我們可以通過Y軸擴展來處理系統複雜度增長、Z軸擴展來處理差異性化需求。XYZ三個軸可以根據實際情況酌情使用其中一個、兩個或三個，三個軸既可以無限向下擴展也可以無限向上擴展。我們在設計系統架構時可將擴展立方體模型作爲理論指導，設計完之後回過頭來驗證是否可以做相應的擴展。
一個擴展性良好的系統，會充分考慮三個維度上的可擴展性，熟練運用三個維度的擴展性，使得系統性能改善上有更多的方向，但在系統性能優化上，代碼層面、框架層面、設計層面也是更加的至關重要。