分庫分表就能無限擴容嗎

分庫分表就能無限擴容嗎？前言正常情況下的服務演化之路單元化最后前言像我這樣的菜鳥，總會有各種疑問，剛開始是對JDKAPI的疑問，對NIO的疑問，對JVM的疑問，當工作幾年后，對服務的可用性，可擴展性也有了新的疑問，什么疑問呢？其實是老生常談的話題：服務的擴容問題。正常情況下的服務演化之路讓我們從最初開始。單體應用每個創(chuàng)業(yè)公司基本都是從類似SSM和SSH這種架構(gòu)起來的，沒什么好講的，基本每個程序員都經(jīng)歷過。RPC應用當業(yè)務越來越大，我們需要對服務進行水平擴容，擴容很簡單，只要保證服務是無狀態(tài)的就可以了，如下圖：當業(yè)務又越來越大，我們的服務關系錯綜復雜，同時，有很多服務訪問都是不需要連接DB的，只需要連接緩存即可，那么就可以做成分離的，減少DB寶貴的連接。如下圖：我相信大部分公司都是在這個階段。Dubbo就是為了解決這個問題而生的。如果你的公司產(chǎn)品很受歡迎，業(yè)務繼續(xù)高速發(fā)展，數(shù)據(jù)越來越多，SQL操作越來越慢，那么數(shù)據(jù)庫就會成為瓶頸，那么你肯定會想到分庫分表，不論通過IDhash或者range的方式都可以。如下圖：這下應該沒問題了吧。任憑你用戶再多，并發(fā)再高，我只要無限擴容數(shù)據(jù)庫，無限擴容應用，就可以了。這也是本文的標題，分庫分表就能解決無限擴容嗎？實際上，像上面的架構(gòu)，并不能解決。其實，這個問題和RPC的問題有點類似：數(shù)據(jù)庫連接過多?。?！搜索公眾號后端架構(gòu)師回復關鍵字“面試”，獲取一份驚喜禮包。通常，我們的RPC應用由于是使用中間件進行訪問數(shù)據(jù)庫，應用實際上是不知道到底要訪問哪個數(shù)據(jù)庫的，訪問數(shù)據(jù)庫的規(guī)則由中間件決定，例如shardingJDBC。這就導致，這個應用必須和所有的數(shù)據(jù)庫連接，就像我們上面的架構(gòu)圖一樣，一個RPC應用需要和3個mysql連接，如果是30個RPC應用，每個RPC的數(shù)據(jù)庫連接池大小是8，每個mysql需要維護240個連接，我們知道，mysql默認連接數(shù)是100，最大連接數(shù)是16384，也就是說，假設每個應用的連接池大小是8，超過2048個應用就無法再繼續(xù)連接了，也就無法繼續(xù)擴容了。注意，由于每個物理庫有很多邏輯庫，再加上微服務運動如火如荼，2048并沒有看起來那么大。也許你說，我可以通過前面加一個proxy來解決連接數(shù)的問題，實際上，代理的性能也會成為問題，為什么？代理的連接數(shù)也是不能超過16384的，如果并發(fā)超過16384，變成163840，那么proxy也解決不了問題。怎么辦？讓我們再看看上面的架構(gòu)圖：我們發(fā)現(xiàn)，問題是出在“每個RPC應用都要連所有的庫”，導致擴容應用的同時，每個數(shù)據(jù)庫連接數(shù)就要增加。就算增加數(shù)據(jù)庫，也不能解決連接數(shù)的問題。那怎么辦呢？單元化單元化，聽起來高大上，通常在一些XXX大會上，分享“關于兩地三中心”，“三地五中心”，“異地多活”等等牛逼的名詞的時候，單元化也會一起出現(xiàn)。這里我們不討論那么牛逼的，就只說“數(shù)據(jù)庫連接數(shù)過多”的問題。實際上，思路很簡單：我們不讓應用連接所有的數(shù)據(jù)庫就可以了。假設我們根據(jù)range分成了10個庫，現(xiàn)在有10個應用，我們讓每個應用只連一個庫，當應用增多變成20個，數(shù)據(jù)庫的連接不夠用了，我們就將10個庫分成20個庫，這樣，無論你應用擴容到多少個，都可以解決數(shù)據(jù)庫連接數(shù)過多的問題。注意：做這件事的前提是：你必須保證，訪問你這個應用的request請求的數(shù)據(jù)庫一定是在這個應用的。s換個說法，當用戶從DNS那里進來的時候，就知道自己要去那個應用了，所以，規(guī)則在DNS之前就定好了，雖然這有點夸張，但肯定在進應用之前就知道要去哪個庫了。所以，這通常需要一個規(guī)則，例如通過用戶IDhash，由配置中心廣播hash規(guī)則。這樣，所有的組件都能保持一致的規(guī)則，從而正確的訪問到數(shù)據(jù)庫。如下圖：到這里，我們終于解決了無限擴容的問題。最后本文從單體應用開始，逐步講述了一個正常后臺的演進歷程，知道了分庫分表并不能解決“無限擴容”的問題，只有單元化才能解決這問題。而單元