?生產實踐中，如果遇到業務流量變高導致服務負載升高甚至報警，我們的第一反應往往是「加機器」。

俗話說，能用錢解決的問題都不是問題。

俗話又說，充錢你就能變得更強。

但是，作為一個有理想有抱負的架構師，除了「加機器」，其實你的微服務還能更優雅、更精細地進行優化。

本文預計閱讀時間 10分鐘，將從以下三個方面展開：

• 從「AKF擴展立方」說起
• Y軸擴展的常用模式
• z軸擴展的思想與應用

1.從「AKF擴展立方」說起

在上一篇文章，我們從「服務維度」學習架構師的常用能力——微服務設計與治理。

圍繞著微服務生命周期的七個階段，總結了常用的16條原則。

其中原則15在微服務服務治理實踐中非常重要，本文將重點進行拆解分析。

原則15：參考「AKF擴展立方」模型，服務除了「水平擴容」外，還可以考慮「功能拆分」或者 「數據分區」。

所謂AKF擴展立方體（AKF Scale Cube），是一個描述從單體應用到一個分布式可擴展架構的模型概念。

• X軸：服務和數據的水平擴容。
• Y軸：功能/業務拆分
• Z軸：沿客戶邊界的服務和數據分區?

「水平擴容」比較容易理解，就是我們常見的操作——加機器。

根據AKF模型，面對服務負載升高的情況，其實除了加機器外，我們還可以考慮「功能拆分」或者 「數據分區」。

2.Y軸擴展的常用模式

「Y軸擴展」相對復雜，我總結了幾種模式：

微服務拆分。根據具體業務模型、領域模型拆分更細粒度的微服務。

業務隔離拆分。利用消息隊列，將在線業務（OLTP）和耗費大量資源的計算任務拆分隔離。

核心與非核心隔離。對于一個微服務，可以將SKA客戶與普通客戶進行隔離，SKA客戶使用獨立的集群資源，提高穩定性。

2.1 微服務拆分

某個微服務負載過高，一個非常常見的原因就是這個微服務承擔了過多的職責。這個時候，我們需要根據具體業務模型、領域模型拆分更細粒度的微服務。也是我們常說的「垂直拆分」。

最典型的拆分方法論就是按照領域驅動設計（DDD)進行拆分。

以電商領域為例，按照領域可以拆分為:

• 用戶服務
• 商品服務
• 訂單服務
• 評價服務
• 其他

系統按照領域拆分為多個微服務后，各個微服務由單獨的團隊負責整個生命周期的維護，單獨部署運行。

這種隔離拆分的方式，能帶來以下優勢：

• 提高整體系統的負載能力
• 各個微服務間具備 獨立擴縮容、故障隔離 等能力。

2.2 耗時任務隔離拆分

「Y軸擴展」除了按照領域進行服務拆分之外，另外一種非常重要的拆分方式，是將在線業務（OLTP)類型服務中「耗時任務」進行隔離拆分。

我們服務一般會采用Tomcat或者Jetty部署，同時采用同步調用的方式。以Jetty為例，默認線程池最大線程數為200。如果請求中有耗時任務，影響了同步請求的RT，那么線程池滿后就會阻塞請求。

正如利特爾法則（Little's law）表述的：在一個穩定的系統（L）中，長期的平均顧客人數，等于長期的有效抵達率（λ），乘以顧客在這個系統中平均的等待時間（W）；或者，我們可以用一個代數式來表達：

因此，耗時任務會顯著提高服務負載、降低在線業務服務的吞吐能力。

通過引入消息隊列或者任務隊列框架，我們可以將耗時任務從在線業務服務中進行隔離拆分。

這種隔離拆分的方式，能帶來以下優勢：

• 提高在線服務的吞吐能力
• 避免耗時任務影響在線業務的穩定性。

2.3 核心與非核心隔離拆分

「Y軸擴展」的第三種方式，是將 核心 與 非核心 進行拆分。

比如，我們通常可能會將「核心接口」與「非核心」接口通過一個服務內的不同線程池實現隔離。但是在節點資源（cpu/內存/帶寬等）上并不能實現隔離。

因此，我們可以更進一步，通過集群拆分的形式進行隔離。

通過服務路由的配置，將核心接口路由到核心集群（一般節點配置更高），非核心接口路由到非核心集群。

另外，也有saas服務，通常會對SKA客戶做獨立集群，也是類似的邏輯。

其實按用戶拆分隔離跟「數據分區」有一點類似，也可以歸類到「z軸擴展」

這種隔離拆分的方式，能帶來以下優勢：

• 精細化提高服務吞吐能力（針對核心接口、核心客戶）
• 核心業務獨享資源，提高核心業務穩定性
• 避免非核心接口/用戶 影響 核心接口/用戶 的穩定性

3.Z軸擴展的思想與應用

Z軸擴展的核心思想，是基于請求者或用戶獨特的需求，進行系統劃分，并使得劃分出來的子系統是相互隔離但又是完整的。

生產實踐中，常用的z軸擴展有兩種應用：

• 單元化架構
• 數據分區

3.1 單元化架構

單元化架構主要關注的是應用部署、調用層面的問題。

一個單元，是一個五臟俱全的縮小版全站，它部署了所有微服務。

但它又不是真正的全站，因為每個單元只能操作一部分數據。

從這里我們也能看出，單元化架構要求系統必須具備的一項能力——數據分區。

當然，僅把數據分區了還不夠，單元化的另外一個必要條件是，全站所有業務數據分區所用的拆分維度和拆分規則都必須一樣。

一般來說，我們絕大多數系統都是面向用戶的，按用戶維度對數據分區，是一個最佳實踐。

當然，如果是全球化部署的單元化架構，還需要考慮按照地域進行分區。

3.2 數據分區

數據分區（shard），即是將全局數據按照某一個維度水平劃分開來，每個分區的數據內容互不重疊，這也就是數據庫「水平拆分」所做的事情。

前面提到了「數據分區」是「單元化」的必要條件，但是「數據分區」還有其他很多場景應用。

最典型的，就是MySQL單機瓶頸后，需要進行「分庫分表」。在服務中需要引入一些支持數據拆分和路由的中間件，如sharding-jdbc、mycat等，在數據層面需要配置相應的分片邏輯。

另外，其他數據庫的分區擴展（如redis集群、mongo集群等），也是非常典型的應用場景。

一般包括以下幾種數據劃分的方式：

• 數據類型（如：業務類型）
• 數據范圍（如：時間段，用戶 ID）
• 數據熱度（如：用戶活躍度，商品熱度）
• 按讀寫分（如：商品描述，商品庫存）

4.小結

本文從「AKF擴展立方」說起，介紹了提高服務負載能力的幾種服務治理方式。

除了X軸擴展（加機器）外，還可以通過Y軸擴展（功能/業務拆分）、Z軸擴展（數據分區）等方式，更優雅、更精細地進行優化。?