像我這樣的菜鳥，總會有各種疑問，剛開始是對 JDK API 的疑問，對 NIO 的疑問，對 JVM 的疑問...

[[278647]] 

圖片來自 Pexels

當工作幾年后，對服務的可用性，可擴展性也有了新的疑問，什么疑問呢?其實是老生常談的話題：服務的擴容問題。

正常情況下的服務演化之路

讓我們從最初開始。

單體應用

每個創業公司基本都是從類似 SSM 和 SSH 這種架構起來的，沒什么好講的，基本每個程序員都經歷過。

RPC 應用

當業務越來越大，我們需要對服務進行水平擴容，擴容很簡單，只要保證服務是無狀態的就可以了，如下圖：

當業務又越來越大，我們的服務關系錯綜復雜，同時，有很多服務訪問都是不需要連接 DB 的，只需要連接緩存即可，那么就可以做成分離的，減少 DB 寶貴的連接。

如下圖：

我相信大部分公司都是在這個階段。Dubbo 就是為了解決這個問題而生的。

分庫分表

如果你的公司產品很受歡迎，業務繼續高速發展，數據越來越多，SQL 操作越來越慢，那么數據庫就會成為瓶頸。

那么你肯定會想到分庫分表，不論通過 ID Hash 或者 Range 的方式都可以，如下圖：

這下應該沒問題了吧。任憑你用戶再多，并發再高，我只要無限擴容數據庫，無限擴容應用，就可以了。

這也是本文的標題，分庫分表就能解決無限擴容嗎?實際上，像上面的架構，并不能解決。

其實，這個問題和 RPC 的問題有點類似：數據庫連接過多!

通常，我們的 RPC 應用由于是使用中間件進行數據庫訪問，應用實際上是不知道到底要訪問哪個數據庫的，訪問數據庫的規則由中間件決定，例如 Sharding JDBC。

這就導致，這個應用必須和所有的數據庫連接，就像我們上面的架構圖一樣，一個 RPC 應用需要和 3 個 MySQL 連接。

如果是 30 個 RPC 應用，每個 RPC 的數據庫連接池大小是 8，每個 MySQL 需要維護 240 個連接。

我們知道，MySQL 默認連接數是 100，最大連接數是 16384，也就是說，假設每個應用的連接池大小是 8 ，超過 2048 個應用就無法再繼續連接了，也就無法繼續擴容了。

注意，由于每個物理庫有很多邏輯庫，再加上微服務運動如火如荼，2048 并沒有看起來那么大。

也許你說，我可以通過前面加一個 Proxy 來解決連接數的問題，實際上，代理的性能也會成為問題，為什么?

代理的連接數也是不能超過 16384 的，如果并發超過 16384，變成 163840，那么 Proxy 也解決不了問題。

怎么辦?讓我們再看看上面的架構圖：

我們發現，問題是出在“每個 RPC 應用都要連所有的庫”，導致擴容應用的同時，每個數據庫連接數就要增加。

就算增加數據庫，也不能解決連接數的問題。那怎么辦呢?

單元化

單元化，聽起來高大上，通常在一些 XXX 大會上，分享“關于兩地三中心”，“三地五中心”，“異地多活”等等牛逼的名詞的時候，單元化也會一起出現。

這里我們不討論那么牛逼的，就只說“數據庫連接數過多” 的問題。實際上，思路很簡單：我們不讓應用連接所有的數據庫就可以了。

假設我們根據 Range 分成了 10 個庫，現在有 10 個應用，我們讓每個應用只連一個庫，當應用增多變成 20 個，數據庫的連接不夠用了，我們就將 10 個庫分成 20 個庫。

這樣，無論你應用擴容到多少個，都可以解決數據庫連接數過多的問題。

注意：做這件事的前提是，你必須保證，訪問你這個應用的 Request 請求的數據庫一定是在這個應用的。

換個說法，當用戶從 DNS 那里進來的時候，就知道自己要去那個應用了，所以，規則在 DNS 之前就定好了，雖然這有點夸張，但肯定在進應用之前就知道要去哪個庫了。

所以，這通常需要一個規則，例如通過用戶 ID Hash，由配置中心廣播 Hash 規則。

這樣，所有的組件都能保持一致的規則，從而正確的訪問到數據庫，如下圖：

到這里，我們終于解決了無限擴容的問題。

最后

本文從單體應用開始，逐步講述了一個正常后臺的演進歷程，知道了分庫分表并不能解決“無限擴容”的問題。

只有單元化才能解決這問題，而單元化則帶來更多的復雜性。但是好處不言而喻，單元化帶來了更多的思路。

有了單元化，解決了無限擴容的問題，但是我們還沒有考慮單點的問題，即服務的可用性。要知道，我們這里的數據庫都是單點的。

這就是另一個話題——異地多活，下次再聊。