當業務又越來越大，我們的服務關系錯綜複雜，同時，有很多服務通路都是不需要連接配接 DB 的，隻需要連接配接緩存即可，那麼就可以做成分離的，減少 DB 寶貴的連接配接。如下圖：
我相信大部分公司都是在這個階段。Dubbo 就是為了解決這個問題而生的。分布式 | Dubbo 架構設計詳解，這篇文章看下。
3、分庫分表
如果你的公司産品很受歡迎，業務繼續高速發展，資料越來越多，SQL 操作越來越慢，那麼資料庫就會成為瓶頸，那麼你肯定會想到分庫分表，不論通過 ID hash 或者 range 的方式都可以。如下圖：
這下應該沒問題了吧。任憑你使用者再多，并發再高，我隻要無限擴容資料庫，無限擴容應用，就可以了。關注Java技術棧微信公衆号，在背景回複關鍵字：_架構_，可以擷取更多棧長整理的架構技術幹貨。
這也是本文的标題，分庫分表就能解決無限擴容嗎？
實際上，像上面的架構，并不能解決。
其實，這個問題和 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 應用都要連所有的庫”，導緻擴容應用的同時，每個資料庫連接配接數就要增加。就算增加資料庫，也不能解決連接配接數的問題。
那怎麼辦呢？關注Java技術棧微信公衆号，在背景回複關鍵字：_架構_，可以擷取更多棧長整理的架構技術幹貨。
單元化
單元化，聽起來高大上，通常在一些 XXX 大會上，分享“關于兩地三中心”，“三地五中心”，“異地多活”等等牛逼的名詞的時候，單元化也會一起出現。
這裡我們不讨論那麼牛逼的，就隻說“資料庫連接配接數過多” 的問題。
實際上，思路很簡單：我們不讓應用連接配接所有的資料庫就可以了。
假設我們根據 range 分成了 10 個庫，現在有 10 個應用，我們讓每個應用隻連一個庫，當應用增多變成 20個，資料庫的連接配接不夠用了，我們就将 10 個庫分成 20 個庫，這樣，無論你應用擴容到多少個，都可以解決資料庫連接配接數過多的問題。
注意：做這件事的前提是：你必須保證，通路你這個應用的 request 請求的資料庫一定是在這個應用的。s
換個說法，當使用者從 DNS 那裡進來的時候，就知道自己要去那個應用了，是以，規則在 DNS 之前就定好了，雖然這有點誇張，但肯定在進應用之前就知道要去哪個庫了。
是以，這通常需要一個規則，例如通過使用者 ID hash，由配置中心廣播 hash 規則。這樣，所有的元件都能保持一緻的規則，進而正确的通路到資料庫。如下圖：
到這裡，我們終于解決了無限擴容的問題。
最後
本文從單體應用開始，逐漸講述了一個正常背景的演進曆程，知道了分庫分表并不能解決“無限擴容” 的問題，隻有單元化才能解決這問題。而單元化則帶來更多的複雜性。但是好處不言而喻。
單元化帶來的更多的思路。
有了單元化，解決了無限擴容的問題，但是我們還沒有考慮單點的問題，即服務的可用性。要知道，我們這裡的資料庫都是單點的。