當(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)用

image

當(dāng)業(yè)務(wù)又越來越大奋早，我們的服務(wù)關(guān)系錯(cuò)綜復(fù)雜盛霎，同時(shí)，有很多服務(wù)訪問都是不需要連接 DB 的耽装，只需要連接緩存即可愤炸，那么就可以做成分離的，減少 DB 寶貴的連接掉奄。

image

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

分庫(kù)分表

如果你的公司產(chǎn)品很受歡迎姓建，業(yè)務(wù)繼續(xù)高速發(fā)展诞仓，數(shù)據(jù)越來越多，SQL 操作越來越慢引瀑，那么數(shù)據(jù)庫(kù)就會(huì)成為瓶頸狂芋。

那么你肯定會(huì)想到分庫(kù)分表，不論通過 ID Hash 或者 Range 的方式都可以憨栽，如下圖：

image

這下應(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)圖：

image

我們發(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)用的麸折。

換個(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ī)則。

image

到這里螟碎，我們終于解決了無限擴(kuò)容的問題眉菱。

最后

本文從單體應(yīng)用開始，逐步講述了一個(gè)正常后臺(tái)的演進(jìn)歷程掉分，知道了分庫(kù)分表并不能解決“無限擴(kuò)容”的問題俭缓。

只有單元化才能解決這問題克伊，而單元化則帶來更多的復(fù)雜性。但是好處不言而喻华坦，單元化帶來了更多的思路愿吹。

有了單元化，解決了無限擴(kuò)容的問題惜姐，但是我們還沒有考慮單點(diǎn)的問題犁跪，即服務(wù)的可用性。要知道歹袁，我們這里的數(shù)據(jù)庫(kù)都是單點(diǎn)的坷衍。