前言
像我這樣的菜鳥，總會(huì)有各種疑問绣硝，剛開始是對(duì) JDK API 的疑問蜻势，對(duì) NIO 的疑問，對(duì) JVM 的疑問鹉胖，當(dāng)工作幾年后握玛，對(duì)服務(wù)的可用性，可擴(kuò)展性也有了新的疑問甫菠，什么疑問呢挠铲？其實(shí)是老生常談的話題：服務(wù)的擴(kuò)容問題。
正常情況下的服務(wù)演化之路
讓我們從最初開始寂诱。
- 單體應(yīng)用
每個(gè)創(chuàng)業(yè)公司基本都是從類似 SSM 和 SSH 這種架構(gòu)起來的拂苹，沒什么好講的，基本每個(gè)程序員都經(jīng)歷過刹衫。 - RPC 應(yīng)用
當(dāng)業(yè)務(wù)越來越大醋寝，我們需要對(duì)服務(wù)進(jìn)行水平擴(kuò)容搞挣，擴(kuò)容很簡(jiǎn)單带迟，只要保證服務(wù)是無狀態(tài)的就可以了音羞，如下圖：
當(dāng)業(yè)務(wù)又越來越大，我們的服務(wù)關(guān)系錯(cuò)綜復(fù)雜仓犬，同時(shí)嗅绰，有很多服務(wù)訪問都是不需要連接 DB 的，只需要連接緩存即可搀继，那么就可以做成分離的窘面，減少 DB 寶貴的連接。如下圖：
我相信大部分公司都是在這個(gè)階段叽躯。Dubbo 就是為了解決這個(gè)問題而生的财边。
- 分庫(kù)分表
如果你的公司產(chǎn)品很受歡迎，業(yè)務(wù)繼續(xù)高速發(fā)展点骑，數(shù)據(jù)越來越多酣难，SQL 操作越來越慢，那么數(shù)據(jù)庫(kù)就會(huì)成為瓶頸黑滴，那么你肯定會(huì)想到分庫(kù)分表憨募，不論通過 ID hash 或者 range 的方式都可以。如下圖：
這下應(yīng)該沒問題了吧袁辈。任憑你用戶再多菜谣，并發(fā)再高，我只要無限擴(kuò)容數(shù)據(jù)庫(kù)晚缩，無限擴(kuò)容應(yīng)用尾膊，就可以了。
這也是本文的標(biāo)題荞彼，分庫(kù)分表就能解決無限擴(kuò)容嗎冈敛？
實(shí)際上，像上面的架構(gòu)卿泽，并不能解決莺债。
其實(shí)，這個(gè)問題和 RPC 的問題有點(diǎn)類似：數(shù)據(jù)庫(kù)連接過多Ｇ┴病Ｆ氚睢！
通常第租，我們的 RPC 應(yīng)用由于是使用中間件進(jìn)行訪問數(shù)據(jù)庫(kù)措拇，應(yīng)用實(shí)際上是不知道到底要訪問哪個(gè)數(shù)據(jù)庫(kù)的，訪問數(shù)據(jù)庫(kù)的規(guī)則由中間件決定慎宾，例如 sharding JDBC丐吓。這就導(dǎo)致浅悉，這個(gè)應(yīng)用必須和所有的數(shù)據(jù)庫(kù)連接，就像我們上面的架構(gòu)圖一樣券犁，一個(gè) RPC 應(yīng)用需要和 3 個(gè) mysql 連接术健，如果是 30 個(gè) RPC 應(yīng)用，每個(gè) RPC 的數(shù)據(jù)庫(kù)連接池大小是8 粘衬，每個(gè) mysql 需要維護(hù) 240 個(gè)連接荞估，我們知道，mysql 默認(rèn)連接數(shù)是 100稚新，最大連接數(shù)是 16384勘伺，也就是說，假設(shè)每個(gè)應(yīng)用的連接池大小是 8 褂删，超過 2048 個(gè)應(yīng)用就無法再繼續(xù)連接了飞醉，也就無法繼續(xù)擴(kuò)容了。注意屯阀，由于每個(gè)物理庫(kù)有很多邏輯庫(kù)缅帘，再加上微服務(wù)運(yùn)動(dòng)如火如荼， 2048 并沒有看起來那么大蹲盘。
也許你說股毫，我可以通過前面加一個(gè) proxy 來解決連接數(shù)的問題，實(shí)際上召衔，代理的性能也會(huì)成為問題铃诬，為什么？代理的連接數(shù)也是不能超過 16384 的苍凛，如果并發(fā)超過 16384趣席，變成 163840，那么 proxy 也解決不了問題醇蝴。
怎么辦宣肚？讓我們?cè)倏纯瓷厦娴募軜?gòu)圖：
我們發(fā)現(xiàn)，問題是出在“每個(gè) RPC 應(yīng)用都要連所有的庫(kù)”悠栓，導(dǎo)致擴(kuò)容應(yīng)用的同時(shí)霉涨，每個(gè)數(shù)據(jù)庫(kù)連接數(shù)就要增加。就算增加數(shù)據(jù)庫(kù)惭适，也不能解決連接數(shù)的問題笙瑟。
那怎么辦呢？
單元化
單元化癞志，聽起來高大上往枷，通常在一些 XXX 大會(huì)上，分享“關(guān)于兩地三中心”，“三地五中心”错洁，“異地多活”等等牛逼的名詞的時(shí)候秉宿，單元化也會(huì)一起出現(xiàn)。
這里我們不討論那么牛逼的屯碴，就只說“數(shù)據(jù)庫(kù)連接數(shù)過多” 的問題描睦。
實(shí)際上，思路很簡(jiǎn)單：我們不讓應(yīng)用連接所有的數(shù)據(jù)庫(kù)就可以了窿锉。
假設(shè)我們根據(jù) range 分成了 10 個(gè)庫(kù)酌摇，現(xiàn)在有 10 個(gè)應(yīng)用膝舅，我們讓每個(gè)應(yīng)用只連一個(gè)庫(kù)嗡载，當(dāng)應(yīng)用增多變成 20個(gè)，數(shù)據(jù)庫(kù)的連接不夠用了仍稀，我們就將 10 個(gè)庫(kù)分成 20 個(gè)庫(kù)洼滚，這樣，無論你應(yīng)用擴(kuò)容到多少個(gè)技潘，都可以解決數(shù)據(jù)庫(kù)連接數(shù)過多的問題遥巴。
注意：做這件事的前提是：你必須保證，訪問你這個(gè)應(yīng)用的 request 請(qǐng)求的數(shù)據(jù)庫(kù)一定是在這個(gè)應(yīng)用的享幽。s
換個(gè)說法铲掐，當(dāng)用戶從 DNS 那里進(jìn)來的時(shí)候，就知道自己要去那個(gè)應(yīng)用了值桩，所以摆霉，規(guī)則在 DNS 之前就定好了，雖然這有點(diǎn)夸張奔坟，但肯定在進(jìn)應(yīng)用之前就知道要去哪個(gè)庫(kù)了携栋。
所以，這通常需要一個(gè)規(guī)則咳秉，例如通過用戶 ID hash婉支，由配置中心廣播 hash 規(guī)則。這樣澜建，所有的組件都能保持一致的規(guī)則向挖，從而正確的訪問到數(shù)據(jù)庫(kù)。如下圖：
到這里炕舵，我們終于解決了無限擴(kuò)容的問題何之。
最后
本文從單體應(yīng)用開始，逐步講述了一個(gè)正常后臺(tái)的演進(jìn)歷程幕侠，知道了分庫(kù)分表并不能解決“無限擴(kuò)容” 的問題帝美，只有單元化才能解決這問題。而單元化則帶來更多的復(fù)雜性。但是好處不言而喻悼潭。
單元化帶來的更多的思路庇忌。
有了單元化，解決了無限擴(kuò)容的問題舰褪，但是我們還沒有考慮單點(diǎn)的問題皆疹，即服務(wù)的可用性。要知道占拍，我們這里的數(shù)據(jù)庫(kù)都是單點(diǎn)的略就。
這就是另一個(gè)話題 —— 異地多活。限于篇幅晃酒，下次再聊表牢。
