高并發系統設計（五）：【系統設計目标③】如何讓系統易于擴充？

資料庫、緩存、依賴的第三方、負載均衡、交換機帶寬等等都是系統擴充時需要考慮的因素。我們要知道系統并發到了某一個量級之後，哪一個因素會成為我們的瓶頸點，進而針對性地進行擴充。

比方說，你系統的流量是每秒1000次請求，對資料庫的請求量也是每秒1000次。如果流量增加10倍，雖然系統可以通過擴容正常服務，資料庫卻成了瓶頸。再比方說，單機網絡帶寬是50Mbps，那麼如果擴容到30台機器，前端負載均衡的帶寬就超過了千兆帶寬的限制，也會成為瓶頸點。

拆分是提升系統擴充性最重要的一個思路，它會把龐雜的系統拆分成獨立的，有單一職責的子產品。相對于大系統來說，考慮一個一個小子產品的擴充性當然會簡單一些。将複雜的問題簡單化。

無論是存儲的資料量，還是并發通路量，不同的業務子產品之間的量級相差很大，比如說成熟社群中，關系的資料量是遠遠大于使用者資料量的，但是使用者資料的通路量卻遠比關系資料要大。是以假如存儲目前的瓶頸點是容量，那麼我們隻需要針對關系子產品的資料做拆分就好了，而不需要拆分使用者子產品的資料。是以存儲拆分首先考慮的次元是業務次元。注意：當資料庫按照業務和資料次元拆分之後，我們盡量不要使用事務。因為當一個事務中同時更新不同的資料庫時，需要使用二階段送出，來協調所有資料庫要麼全部更新成功，要麼全部更新失敗。這個協調的成本會随着資源的擴充不斷升高，最終達到無法承受的程度。

拆分之後，這個簡單的社群系統就有了使用者庫、内容庫、評論庫、點贊庫和關系庫。這麼做還能隔離故障，某一個庫“挂了”不會影響到其它的資料庫。假如單一的業務資料庫在容量和并發請求量上仍然會超過單機的限制，就需要針對資料庫做第二次拆分。

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

首先，我們需要把相同業務的服務拆分成單獨的業務池，每個業務依賴獨自的資料庫資源，不會依賴其它業務的資料庫資源。這樣當某一個業務的接口成為瓶頸時，我們隻需要擴充業務的池子，以及确認上下遊的依賴方就可以了，這樣就大大減少了擴容的複雜度。池子就是一組機器組成的叢集。