從架構設計上來說，高可擴展性是一個設計的指標，它表示可以通過增加機器的方式來線性提高系統的處理能力，從而承擔更高的流量和并發。

你可能會問："在架構設計之初，為什么不預先考慮好使用多少臺機器，支持現有的并發呢？" 答案是峰值的流量不可控。

通常情況下，在業務平穩期，我們會預留30%至50%的冗余資源，以處理運營活動或推廣可能引發的峰值流量。然而，當突發事件發生時，流量可能會瞬間增加到2至3倍甚至更高的水平。以微博為例，這種情況是很常見的。

當出現鹿晗和關曉彤互相確認戀情等突發事件時，微博的流量會迅速增加，導致信息流無法及時刷新。在這種情況下，我們需要迅速應對流量激增，最快的方法是增加服務器。然而，需要確保增加了三倍的服務器后，系統能夠支持三倍的流量。有人可能會覺得這很明顯，但實際上，這個過程中存在一些挑戰。讓我們看看這些挑戰是什么。

為什么提升擴展性會很復雜

增加處理核心是提高系統并行處理能力的一種方法，但它并不總是有效的。當任務并行數增加時，系統可能因為資源爭用而性能下降，達到一個拐點。這不僅適用于單機系統，也適用于由多臺機器組成的集群系統。集群系統中，不同的層次可能存在一些限制系統橫向擴展的“瓶頸點”。

讓我通過一個例子來解釋這個概念。假設系統的每秒請求量是1000次，與數據庫的請求量相同。如果流量增加了10倍，系統可以通過擴容來滿足需求，但數據庫可能成為瓶頸。

再舉一個例子，單臺服務器的網絡帶寬是50Mbps，如果擴展到30臺服務器，前端負載均衡的帶寬將超過千兆帶寬的限制，也成為瓶頸。那么，系統中有哪些服務可能會成為限制系統擴展的關鍵因素呢？無狀態的服務和組件更容易擴展，而像MySQL這樣的有狀態存儲服務則難以擴展。

這是因為在向存儲集群中添加或刪除服務器時，涉及大量數據遷移，而傳統的關系型數據庫通常不支持這種操作。這是提高系統擴展性復雜性的主要原因之一。此外，從示例中可以看出，我們需要從整體架構的角度考慮系統的擴展性，而不僅僅是業務服務器的角度。因此，數據庫、緩存、第三方依賴、負載均衡、網絡帶寬等都是需要考慮的因素。我們需要了解系統達到一定并發水平后，哪些因素將成為瓶頸，然后有針對性地擴展系統。

針對這些復雜的擴展性問題，我提煉了一些系統設計思路。

高可擴展性的設計思路

拆分是提高系統擴展性的關鍵策略，它將復雜的系統分解成獨立的、具有單一職責的模塊。與處理整個大系統相比，考慮如何擴展每個小模塊顯然更加簡單。我們的方法是將復雜的問題分解為簡單的部分。

在不同類型的模塊拆分方面，我們需要遵循不同的原則。舉個簡單的例子，如果你要設計一個社區，可能會有以下5個模塊：用戶、關系、內容、評論/贊、搜索。通常，這些模塊都會使用最簡單的三層部署架構，其中負載均衡用于請求分發，應用服務器用于處理業務邏輯，數據庫用于數據存儲。然而，問題是所有這些模塊的業務代碼都混合在一起，數據也存儲在同一個數據庫中。

圖片

1. 存儲層的擴展性

不同的業務模塊之間的數據量和并發訪問量可能差異很大。以一個成熟的社區系統為例，關系模塊的數據量可能遠大于用戶數據，但用戶數據的訪問量卻更高。因此，如果存儲容量成為瓶頸，我們可以選擇僅拆分關系模塊的數據，而不必拆分用戶模塊的數據。這種存儲拆分是基于業務維度的，將系統拆分為用戶庫、內容庫、評論庫、點贊庫和關系庫等，從而隔離了故障。如果其中一個庫出現問題，不會影響其他數據庫的正常運行。

拆分之后，這個簡單的社區系統就有了用戶庫、內容庫、評論庫、點贊庫和關系庫。這么做還能隔離故障，某一個庫“掛了”不會影響到其它的數據庫。

圖片

按照業務拆分雖然在一定程度上提升了系統的擴展性，但隨著系統運行時間的增長，單一的業務數據庫可能會面臨容量和并發請求量超過單機限制的問題。在這種情況下，我們需要考慮對數據庫進行第二次拆分。

這次的拆分是基于數據特征進行水平拆分的。例如，我們可以向用戶庫添加兩個節點，然后使用特定的算法將用戶數據分布到這三個庫中。

水平拆分后，數據庫就可以突破單機的限制。但需要注意的是，不應隨意增加節點，因為節點的增加涉及到數據的手動遷移，會增加成本。因此，從長遠考慮，最好一次性增加足夠數量的節點，以避免頻繁擴容。

此外，在數據庫按照業務和數據維度進行拆分后，應盡量避免使用事務。因為當一個事務涉及同時更新不同的數據庫時，需要使用二階段提交來協調，這會隨著資源擴展而導致協調成本不斷增加，最終可能無法承受。接下來，我們將討論業務層如何實現易于擴展。

2. 業務層的擴展性

我們一般會從三個維度考慮業務層的拆分方案，它們分別是：業務維度，重要性維度和請求來源維度。

首先，我們需要把相同業務的服務拆分成單獨的業務池，比方說上面的社區系統中，我們可以按照業務的維度拆分成用戶池、內容池、關系池、評論池、點贊池和搜索池。

每個業務依賴獨自的數據庫資源，不會依賴其它業務的數據庫資源。這樣當某一個業務的接口成為瓶頸時，我們只需要擴展業務的池子，以及確認上下游的依賴方就可以了，這樣就大大減少了擴容的復雜度。

圖片

此外，我們還可以根據業務接口的重要性，將業務劃分為核心池和非核心池。以關系池為例，關注和取消關注接口可能相對重要，因此它們可以放入核心池。而拉黑和取消拉黑等操作可能不那么重要，可以放入非核心池。

這種方法允許我們首先確保核心池的性能。當整體流量增加時，我們可以首先擴容核心池，并對一些非核心池的接口進行降級，以確保整體系統的穩定性。

圖片

最后，你還可以根據接入客戶端類型的不同做業務池的拆分。比如說，服務于客戶端接口的業務可以定義為外網池，服務于小程序或者 HTML5 頁面的業務可以定義為 H5 池，服務于內部其它部門的業務可以定義為內網池，等等。