當我們需要分布式系統提供更強的性能時，該怎樣擴展系統呢？什么時候該加機器？什么時候該重構代碼？擴容時，究竟該選擇哈希算法還是最小連接數算法，才能有效提升性能？在面對 Scalability 可伸縮性問題時，我們必須有一個系統的方法論，才能應對日益復雜的分布式系統。這一講我將介紹 AKF 立方體理論，它定義了擴展系統的 3 個維度，我們可以綜合使用它們來優化性能。

什么是AKF

AKF 立方體也叫做scala cube，它在《The Art of Scalability》一書中被首次提出，旨在提供一個系統化的擴展思路。AKF 把系統擴展分為以下三個維度：

• X 軸：直接水平復制應用進程來擴展系統。也就是”加機器解決問題”，集群
• Y 軸：將功能拆分出來擴展系統。
• Z 軸：基于用戶信息擴展系統。也就是數據分區

如下圖所示：

圖片

如何基于 AKF X 軸擴展系統？

我們日常見到的各種系統擴展方案，都可以歸結到 AKF 立方體的這三個維度上。而且，我們可以同時組合這 3 個方向上的擴展動作，使得系統可以近乎無限地提升性能。為了避免對 AKF 的介紹過于抽象，下面我用一個實際的例子，帶你看看這 3 個方向的擴展到底該如何應用。假定我們開發一個博客平臺，用戶可以申請自己的博客帳號，并在其上發布文章。最初的系統考慮了 MVC 架構，將數據狀態及關系模型交給數據庫實現，應用進程通過 SQL 語言操作數據模型，經由 HTTP 協議對瀏覽器客戶端提供服務，如下圖所示：

圖片

在這個架構中，處理業務的應用進程屬于無狀態服務，用戶數據全部放在了關系數據庫中。因此，當我們在應用進程前加 1 個負載均衡服務后，就可以通過部署更多的應用進程，提供更大的吞吐量。而且，初期增加應用進程，RPS 可以獲得線性增長，很實用，如下圖：

圖片

這就叫做沿 AKF X 軸擴展系統。這種擴展方式最大的優點，就是開發成本近乎為零，而且實施起來速度快！在搭建好負載均衡后，只需要在新的物理機、虛擬機或者微服務上復制程序，就可以讓新進程分擔請求流量，而且不會影響事務 Transaction 的處理。當然，AKF X 軸擴展最大的問題是只能擴展無狀態服務，當有狀態的數據庫出現性能瓶頸時，X 軸是無能為力的。例如，當用戶數據量持續增長，關系數據庫中的表就會達到百萬、千萬行數據，SQL 語句會越來越慢，這時可以沿著 AKF Z 軸去分庫分表提升性能。又比如，當請求用戶頻率越來越高，那么可以把單實例數據庫擴展為主備多實例，沿 Y 軸把讀寫功能分離提升性能。下面我們先來看 AKF Y 軸如何擴展系統。

如何基于 AKF Y 軸擴展系統？

當數據庫的 CPU、網絡帶寬、內存、磁盤 IO 等某個指標率先達到上限后，系統的吞吐量就達到了瓶頸，此時沿著 AKF X 軸擴展系統，是沒有辦法提升性能的。在現代經濟中，更細分、更專業的產業化、供應鏈分工，可以給社會帶來更高的效率，而 AKF Y 軸與之相似，當遇到上述性能瓶頸后，拆分系統功能，使得各組件的職責、分工更細，也可以提升系統的效率。比如，當我們將應用進程對數據庫的讀寫操作拆分后，就可以擴展單機數據庫為主備分布式系統，使得主庫支持讀寫兩種 SQL，而備庫只支持讀 SQL。這樣，主庫可以輕松地支持事務操作，且它將數據同步到備庫中也并不復雜，如下圖所示：

圖片

當然，上圖中如果讀性能達到了瓶頸，我們可以繼續沿著 AKF X 軸，用復制的方式擴展多個備庫，提升讀 SQL 的性能，可見，AKF 多個軸完全可以搭配著協同使用。拆分功能是需要重構代碼的，它的實施成本比沿 X 軸簡單復制擴展要高得多。在上圖中，通常關系數據庫的客戶端 SDK 已經支持讀寫分離，所以實施成本由中間件承擔了，這對我們理解 Y 軸的實施代價意義不大，所以我們再來看從業務上拆分功能的例子。當這個博客平臺訪問量越來越大時，一臺主庫是無法扛住所有寫流量的。因此，基于業務特性拆分功能，就是必須要做的工作。比如，把用戶的個人信息、身份驗證等功能拆分出一個子系統，再把文章、留言發布等功能拆分到另一個子系統，由無狀態的業務層代碼分開調用，并通過事務組合在一起，如下圖所示：

圖片

這樣，每個后端的子應用更加聚焦于細分的功能，它的數據庫規模會變小，也更容易優化性能。比如，針對用戶登錄功能，你可以再次基于 Y 軸將身份驗證功能拆分，用 Redis 等服務搭建一個基于 LRU 算法淘汰的緩存系統，快速驗證用戶身份。然而，沿 Y 軸做功能拆分，實施成本非常高，需要重構代碼并做大量測試工作，上線部署也很復雜。比如上例中要對數據模型做拆分（如同一個庫中的表拆分到多個庫中，或者表中的字段拆到多張表中），設計組件之間的 API 交互協議，重構無狀態應用進程中的代碼，為了完成升級還要做數據遷移，等等。解決數據增長引發的性能下降問題，除了成本較高的 AKF Y 軸擴展方式外，沿 Z 軸擴展系統也很有效，它的實施成本更低一些，下面我們具體看一下。

如何基于 AKF Z 軸擴展系統？

不同于站在服務角度擴展系統的 X 軸和 Y 軸，AKF Z 軸則從用戶維度拆分系統，它不僅可以提升數據持續增長降低的性能，還能基于用戶的地理位置獲得額外收益。仍然以上面虛擬的博客平臺為例，當注冊用戶數量上億后，無論你如何基于 Y 軸的功能去拆分表（即“垂直”地拆分表中的字段），都無法使得關系數據庫單個表的行數在千萬級以下，這樣表字段的 B 樹索引非常龐大，難以完全放在內存中，最后大量的磁盤 IO 操作會拖慢 SQL 語句的執行。這個時候，關系數據庫最常用的分庫分表操作就登場了，它正是 AKF 沿 Z 軸拆分系統的實踐。比如已經含有上億行數據的 User 用戶信息表，可以分成 10 個庫，每個庫再分成 10 張表，利用固定的哈希函數，就可以把每個用戶的數據映射到某個庫的某張表中。這樣，單張表的數據量就可以降低到 1 百萬行左右，如果每個庫部署在不同的服務器上（具體的部署方式視訪問吞吐量以及服務器的配置而定），它們處理的數據量減少了很多，卻可以獨占服務器的硬件資源，性能自然就有了提升。如下圖所示：

圖片

分庫分表是關系數據庫中解決數據增長壓力的最有效辦法，但分庫分表同時也導致跨表的查詢語句復雜許多，而跨庫的事務幾乎難以實現，因此這種擴展的代價非常高。當然，如果你使用的是類似 MySQL 這些成熟的關系數據庫，整個生態中會有廠商提供相應的中間件層，使用它們可以降低 Z 軸擴展的代價。再比如，最開始我們采用 X 軸復制擴展的服務，它們的負載均衡策略很簡單，只需要選擇負載最小的上游服務器即可，比如 RoundRobin 或者最小連接算法都可以達到目的。但若上游服務器通過 Y 軸擴展，開啟了緩存功能，那么考慮到緩存的命中率，就必須改用 Z 軸擴展的方式，基于用戶信息做哈希規則下的新路由，盡量將同一個用戶的請求命中相同的上游服務器，才能充分提高緩存命中率。Z 軸擴展還有一個好處，就是可以充分利用 IDC 與用戶間的網速差，選擇更快的 IDC 為用戶提供高性能服務。網絡是基于光速傳播的，當 IDC 跨城市、國家甚至大洲時，用戶訪問不同 IDC 的網速就會有很大差異。當然，同一地域內不同的網絡運營商之間，也會有很大的網速差。例如你在全球都有 IDC 或者公有云服務器時，就可以通過域名為當地用戶就近提供服務，這樣性能會高很多。事實上，CDN 技術就基于 IP 地址的位置信息，就近為用戶提供靜態資源的高速訪問。

下圖中，我使用了 2 種 Z 軸擴展系統的方式。首先是基于客戶端的地理位置，選擇不同的 IDC 就近提供服務。其次是將不同的用戶分組，比如免費用戶組與付費用戶組，這樣在業務上分離用戶群體后，還可以有針對性地提供不同水準的服務。

圖片

沿 AKF Z 軸擴展系統可以解決數據增長帶來的性能瓶頸，也可以基于數據的空間位置提升系統性能，然而它的實施成本比較高，尤其是在系統宕機、擴容時，一旦路由規則發生變化，會帶來很大的數據遷移成本，[第 24 講] 我將要介紹的一致性哈希算法，其實就是用來解決這一問題的。

小結

這一講我們介紹了如何基于 AKF 立方體的 X、Y、Z 三個軸擴展系統提升性能。X 軸擴展系統時實施成本最低，只需要將程序復制到不同的服務器上運行，再用下游的負載均衡分配流量即可。X 軸只能應用在無狀態進程上，故無法解決數據增長引入的性能瓶頸。Y 軸擴展系統時實施成本最高，通常涉及到部分代碼的重構，但它通過拆分功能，使系統中的組件分工更細，因此可以解決數據增長帶來的性能壓力，也可以提升系統的總體效率。比如關系數據庫的讀寫分離、表字段的垂直拆分，或者引入緩存，都屬于沿 Y 軸擴展系統。Z 軸擴展系統時實施成本也比較高，但它基于用戶信息拆分數據后，可以在解決數據增長問題的同時，基于地理位置就近提供服務，進而大幅度降低請求的時延，比如常見的 CDN 就是這么提升用戶體驗的。但 Z 軸擴展系統后，一旦發生路由規則的變動導致數據遷移時，運維成本就會比較高。當然，X、Y、Z 軸的擴展并不是孤立的，我們可以同時應用這 3 個維度擴展系統。分布式系統非常復雜，AKF 給我們提供了一種自上而下的方法論，讓我們能夠針對不同場景下的性能瓶頸，以最低的成本提升性能。