微服務架構設計基礎之立方體模型

背景

對於如今的微服務架構的應用來講，對大量併發的及時響應是一項制勝能力。據用戶行爲分析平臺統計，隨行付的某一款APP產品每日請求就達到上千萬次用戶請求、加解密服務3000萬次/日等等。這些微服務每時每刻在處理如此高強度的請求，對數據層的應對能力要求極高。若是咱們把對速度的需求放在複雜的分佈式數據架構背景下，是很難想象如何讓應用應對如此巨大的數據訪問量的。但很幸運，咱們有方法作到。即立方體模型。

立方體模型

可擴展的分佈式系統架構設計有一個樸素的理念，就是：經過加機器就能夠解決容量和可用性的問題。

對於一個迅速增加的應用而言，容量和性能是首當其衝要面臨的問題。但隨着時間的向前推移、應用規模不斷的快速增加，除了面對性能與容量的問題外，還須要解決功能與模塊數量上增加帶來的系統複雜性問題、業務變化帶來的差別化服務問題等。而多數狀況下應用設計之初出於諸多因素的考量，並無充分考慮或在設計之初就將此類問題提上日程，致使系統的重構成爲常態，從而影響業務交付能力。對此，「架構即將來」一書中提出了更加系統的可擴展模型，可擴展模型是一個富有啓發性的方法，描述了微服務三個維度的擴展方法，能夠經過它來了解微服務架構的擴展維度。

• X軸：橫向擴展模式，關注水平的數據和服務克隆
• Y軸：功能分解模式，關注應用中的職責的劃分
• Z軸：數據分區模式，關注服務和數據的優先級劃分

X軸擴展

X軸擴展是經過絕對平等的複製服務和數據，以解決容量和可用性的問題。以乘坐火車爲例，因春運高峯集中，乘客人數也是平時時的幾倍、甚至幾十倍。12306爲了提升運力都會採用複製的方法：增長火車數量。增長火車數量有效的提升春運運力、提升乘客出行體驗。

對於軟件工程而言，好比加解密微服務的性能峯值1000TPS，一般咱們須要提升TPS，會採起復制加解密服務：增長服務提供者。這就是X軸擴展的一個完美示例，說明了X軸擴展的思路，把工做無偏向的分配給「複製品」，各個「複製品」之間不共享任何內容、能獨立提供服務。而對於軟件技術來說，X軸擴展主要有負載均衡和數據複製兩種技術方式。

負載均衡

負載均衡是將用戶的訪問請求經過負載均衡器，均衡分配到由各個「複製品」組成的集羣中去。當某個「複製品」出現故障，也能輕易地將相應「工做」轉移給其它的複製品來「代爲完成」。經常使用的硬件負載有F五、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三個軸能夠根據實際狀況酌情使用其中一個、兩個或三個，三個軸既能夠無限向下擴展也能夠無限向上擴展。咱們在設計系統架構時可將擴展立方體模型做爲理論指導，設計完以後回過頭來驗證是否能夠作相應的擴展。

一個擴展性良好的系統，會充分考慮三個維度上的可擴展性，熟練運用三個維度的擴展性，使得系統性能改善上有更多的方向，但在系統性能優化上，代碼層面、框架層面、設計層面也是更加的相當重要。

做者簡介

馬鐵利，TGO鯤鵬會北京分會會員，10年全棧工程師，擅長微服務分佈式架構設計。主要負責架構部平常管理，參與構建微服務平臺周邊基礎設施及中間件。負責隨行付對外開源等事宜。