前言
創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),金口河企業(yè)網(wǎng)站建設(shè),金口河品牌網(wǎng)站建設(shè),網(wǎng)站定制,金口河網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,金口河網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。像我這樣的菜鳥，總會有各種疑問，剛開始是對 JDK API 的疑問，對 NIO 的疑問，對 JVM 的疑問，當工作幾年后，對服務(wù)的可用性，可擴展性也有了新的疑問，什么疑問呢？其實是老生常談的話題：服務(wù)的擴容問題。
正常情況下的服務(wù)演化之路
讓我們從最初開始。
單體應(yīng)用 每個創(chuàng)業(yè)公司基本都是從類似 SSM 和 SSH 這種架構(gòu)起來的，沒什么好講的，基本每個程序員都經(jīng)歷過。
RPC 應(yīng)用 當業(yè)務(wù)越來越大，我們需要對服務(wù)進行水平擴容，擴容很簡單，只要保證服務(wù)是無狀態(tài)的就可以了，如下圖：
當業(yè)務(wù)又越來越大，我們的服務(wù)關(guān)系錯綜復雜，同時，有很多服務(wù)訪問都是不需要連接 DB 的，只需要連接緩存即可，那么就可以做成分離的，減少 DB 寶貴的連接。如下圖：
我相信大部分公司都是在這個階段。Dubbo 就是為了解決這個問題而生的。
如果你的公司產(chǎn)品很受歡迎，業(yè)務(wù)繼續(xù)高速發(fā)展，數(shù)據(jù)越來越多，SQL 操作越來越慢，那么數(shù)據(jù)庫就會成為瓶頸，那么你肯定會想到分庫分表，不論通過 ID hash 或者 range 的方式都可以。如下圖：
這下應(yīng)該沒問題了吧。任憑你用戶再多，并發(fā)再高，我只要無限擴容數(shù)據(jù)庫，無限擴容應(yīng)用，就可以了。
這也是本文的標題，分庫分表就能解決無限擴容嗎？
實際上，像上面的架構(gòu)，并不能解決。
其實，這個問題和 RPC 的問題有點類似：數(shù)據(jù)庫連接過多！??！
通常，我們的 RPC 應(yīng)用由于是使用中間件進行訪問數(shù)據(jù)庫，應(yīng)用實際上是不知道到底要訪問哪個數(shù)據(jù)庫的，訪問數(shù)據(jù)庫的規(guī)則由中間件決定，例如 sharding JDBC。這就導致，這個應(yīng)用必須和所有的數(shù)據(jù)庫連接，就像我們上面的架構(gòu)圖一樣，一個 RPC 應(yīng)用需要和 3 個 mysql 連接，如果是 30 個 RPC 應(yīng)用，每個 RPC 的數(shù)據(jù)庫連接池大小是8 ，每個 mysql 需要維護 240 個連接，我們知道，mysql 默認連接數(shù)是 100，大連接數(shù)是 16384，也就是說，假設(shè)每個應(yīng)用的連接池大小是 8 ，超過 2048 個應(yīng)用就無法再繼續(xù)連接了，也就無法繼續(xù)擴容了。
注意，由于每個物理庫有很多邏輯庫，再加上微服務(wù)運動如火如荼， 2048 并沒有看起來那么大。
也許你說，我可以通過前面加一個 proxy 來解決連接數(shù)的問題，實際上，代理的性能也會成為問題，為什么？代理的連接數(shù)也是不能超過 16384 的，如果并發(fā)超過 16384，變成 163840，那么 proxy 也解決不了問題。
怎么辦？讓我們再看看上面的架構(gòu)圖：
我們發(fā)現(xiàn)，問題是出在“每個 RPC 應(yīng)用都要連所有的庫”，導致擴容應(yīng)用的同時，每個數(shù)據(jù)庫連接數(shù)就要增加。就算增加數(shù)據(jù)庫，也不能解決連接數(shù)的問題。
那怎么辦呢？
歡迎大家關(guān)注我的公種浩【程序員追風】，文章都會在里面更新，整理的資料也會放在里面。
單元化
單元化，聽起來高大上，通常在一些 XXX 大會上，分享“關(guān)于兩地三中心”，“三地五中心”，“異地多活”等等牛逼的名詞的時候，單元化也會一起出現(xiàn)。
這里我們不討論那么牛逼的，就只說“數(shù)據(jù)庫連接數(shù)過多” 的問題。
實際上，思路很簡單：我們不讓應(yīng)用連接所有的數(shù)據(jù)庫就可以了。
假設(shè)我們根據(jù) range 分成了 10 個庫，現(xiàn)在有 10 個應(yīng)用，我們讓每個應(yīng)用只連一個庫，當應(yīng)用增多變成 20個，數(shù)據(jù)庫的連接不夠用了，我們就將 10 個庫分成 20 個庫，這樣，無論你應(yīng)用擴容到多少個，都可以解決數(shù)據(jù)庫連接數(shù)過多的問題。
注意：做這件事的前提是：你必須保證，訪問你這個應(yīng)用的 request 請求的數(shù)據(jù)庫一定是在這個應(yīng)用的。s
換個說法，當用戶從 DNS 那里進來的時候，就知道自己要去那個應(yīng)用了，所以，規(guī)則在 DNS 之前就定好了，雖然這有點夸張，但肯定在進應(yīng)用之前就知道要去哪個庫了。
所以，這通常需要一個規(guī)則，例如通過用戶 ID hash，由配置中心廣播 hash 規(guī)則。這樣，所有的組件都能保持一致的規(guī)則，從而正確的訪問到數(shù)據(jù)庫。如下圖：
到這里，我們終于解決了無限擴容的問題。
總結(jié)
本文從單體應(yīng)用開始，逐步講述了一個正常后臺的演進歷程，知道了分庫分表并不能解決“無限擴容” 的問題，只有單元化才能解決這問題。而單元化則帶來更多的復雜性。但是好處不言而喻。
單元化帶來的更多的思路。
有了單元化，解決了無限擴容的問題，但是我們還沒有考慮單點的問題，即服務(wù)的可用性。要知道，我們這里的數(shù)據(jù)庫都是單點的。
最后
歡迎大家一起交流，喜歡文章記得點個贊喲，感謝支持！
創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務(wù)器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機房獨有T級流量清洗系統(tǒng)配攻擊溯源，準確進行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動現(xiàn)已開啟，新人活動云服務(wù)器買多久送多久。
重慶分公司
重慶分公司
