聊聊八種架構(gòu)模式

作者：風(fēng)平浪靜如碼 2022-06-14 11:01:37

作為一個(gè)工作10年以上的老碼農(nóng)，經(jīng)歷的系統(tǒng)架構(gòu)設(shè)計(jì)也算不少，接下來(lái)，我會(huì)把工作中用到的一些架構(gòu)方面的設(shè)計(jì)模式分享給大家，望大家少走彎路。

作為一名后端研發(fā)人員，好的代碼架構(gòu)肯定有章法可循，今天我們就來(lái)學(xué)習(xí)8種常用的架構(gòu)模式，讓你的系統(tǒng)不再是眉毛胡子一把抓。

什么是架構(gòu)

我想這個(gè)問(wèn)題，十個(gè)人回答得有十一個(gè)答案，因?yàn)榱硗獾哪且粋€(gè)是大家妥協(xié)的結(jié)果。哈哈，我理解，架構(gòu)就是骨架，如下圖所示：

人類的身體的支撐是主要由骨架來(lái)承擔(dān)的，然后是其上的肌肉、神經(jīng)、皮膚。架構(gòu)對(duì)于軟件的重要性不亞于骨架對(duì)人類身體的重要性。

什么是設(shè)計(jì)模式

這個(gè)問(wèn)題我問(wèn)過(guò)的面試者不下于數(shù)十次，回答五花八門，在我看來(lái)，模式就是經(jīng)驗(yàn)，設(shè)計(jì)模式就是設(shè)計(jì)經(jīng)驗(yàn)，有了這些經(jīng)驗(yàn)，我們就能在特定情況下使用特定的設(shè)計(jì)、組合設(shè)計(jì)，這樣可以大大節(jié)省我們的設(shè)計(jì)時(shí)間，提高工作效率。作為一個(gè)工作10年以上的老碼農(nóng)，經(jīng)歷的系統(tǒng)架構(gòu)設(shè)計(jì)也算不少，接下來(lái)，我會(huì)把工作中用到的一些架構(gòu)方面的設(shè)計(jì)模式分享給大家，望大家少走彎路。總體而言，共有八種，分別是：

單庫(kù)單應(yīng)用模式：最簡(jiǎn)單的，可能大家都見過(guò)
內(nèi)容分發(fā)模式：目前用的比較多
查詢分離模式：對(duì)于大并發(fā)的查詢、業(yè)務(wù)
微服務(wù)模式：適用于復(fù)雜的業(yè)務(wù)模式的拆解
多級(jí)緩存模式：可以把緩存玩的很好
分庫(kù)分表模式：解決單機(jī)數(shù)據(jù)庫(kù)瓶頸
彈性伸縮模式：解決波峰波谷業(yè)務(wù)流量不均勻的方法之一
多機(jī)房模式：解決高可用、高性能的一種方法

單庫(kù)單應(yīng)用模式

這是最簡(jiǎn)單的一種設(shè)計(jì)模式，我們的大部分本科畢業(yè)設(shè)計(jì)、一些小的應(yīng)用，基本上都是這種模式，這種模式的一般設(shè)計(jì)見下圖：

如上圖所示，這種模式一般只有一個(gè)數(shù)據(jù)庫(kù)，一個(gè)業(yè)務(wù)應(yīng)用層，一個(gè)后臺(tái)管理系統(tǒng)，所有的業(yè)務(wù)都是用過(guò)業(yè)務(wù)層完成的，所有的數(shù)據(jù)也都是存儲(chǔ)在一個(gè)數(shù)據(jù)庫(kù)中的，好一點(diǎn)會(huì)有數(shù)據(jù)庫(kù)的同步。雖然簡(jiǎn)單，但是也并不是一無(wú)是處。

優(yōu)點(diǎn)：結(jié)構(gòu)簡(jiǎn)單、開發(fā)速度快、實(shí)現(xiàn)簡(jiǎn)單，可用于產(chǎn)品的第一版等有原型驗(yàn)證需求、用戶少的設(shè)計(jì)。

缺點(diǎn)：性能差、基本沒有高可用、擴(kuò)展性差，不適用于大規(guī)模部署、應(yīng)用等生產(chǎn)環(huán)境。

內(nèi)容分發(fā)模式

基本上所有的大型的網(wǎng)站都有或多或少的采用這一種設(shè)計(jì)模式，常見的應(yīng)用場(chǎng)景是使用CDN技術(shù)把網(wǎng)頁(yè)、圖片、CSS、JS等這些靜態(tài)資源分發(fā)到離用戶最近的服務(wù)器。這種模式的一般設(shè)計(jì)見下圖：

如上圖所示，這種模式較單庫(kù)單應(yīng)用模式多了一個(gè)CDN、一個(gè)云存儲(chǔ)OSS(七牛、又拍等雷同)。一個(gè)典型的應(yīng)用流程(以用戶上傳、查看圖片需求為例)如下：

上傳的時(shí)候，用戶選擇本地機(jī)器上的一個(gè)圖片進(jìn)行上傳
程序會(huì)把這個(gè)圖片上傳到云存儲(chǔ)OSS上，并返回該圖片的一個(gè)URL
程序把這個(gè)URL字符串存儲(chǔ)在業(yè)務(wù)數(shù)據(jù)庫(kù)中，上傳完成。
查看的時(shí)候，程序從業(yè)務(wù)數(shù)據(jù)庫(kù)得到該圖片的URL
程序通過(guò)DNS查詢這個(gè)URL的圖片服務(wù)器
智能DNS會(huì)解析這個(gè)URL，得到與用戶最近的服務(wù)器(或集群)的地址A
然后把服務(wù)器A上的圖片返回給程序
程序顯示該圖片，查看完成。

由上可知，這個(gè)模式的關(guān)鍵是智能DNS，它能夠解析出離用戶最近的服務(wù)器。運(yùn)行原理大致是：根據(jù)請(qǐng)求者的IP得到請(qǐng)求地點(diǎn)B，然后通過(guò)計(jì)算或者配置得到與B最近或通訊時(shí)間最短的服務(wù)器C，然后把C的IP地址返回給請(qǐng)求者。這種模式的優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：資源下載快、無(wú)需過(guò)多的開發(fā)與配置，同時(shí)也減輕了后端服務(wù)器對(duì)資源的存儲(chǔ)壓力，減少帶寬的使用。
缺點(diǎn)：目前來(lái)說(shuō)OSS，CDN的價(jià)格還是稍微有些貴(雖然已經(jīng)降價(jià)好幾次了)，只適用于中小規(guī)模的應(yīng)用，另外由于網(wǎng)絡(luò)傳輸?shù)难舆t、CDN的同步策略等，會(huì)有一些一致性、更新慢方面的問(wèn)題。

查詢分離模式

這種模式主要解決單機(jī)數(shù)據(jù)庫(kù)壓力過(guò)大，從而導(dǎo)致業(yè)務(wù)緩慢甚至超時(shí)，查詢響應(yīng)時(shí)間變長(zhǎng)的問(wèn)題，也包括需要大量數(shù)據(jù)庫(kù)服務(wù)器計(jì)算資源的查詢請(qǐng)求。這個(gè)可以說(shuō)是單庫(kù)單應(yīng)用模式的升級(jí)版本，也是技術(shù)架構(gòu)迭代演進(jìn)過(guò)程中的必經(jīng)之路。這種模式的一般設(shè)計(jì)見下圖：

如上圖所示，這種模式較單庫(kù)單應(yīng)用模式與內(nèi)容分發(fā)模式多了幾個(gè)部分，一個(gè)是業(yè)務(wù)數(shù)據(jù)庫(kù)的主從分離，一個(gè)是引入了ES，為什么要這樣？都解決了哪些痛點(diǎn)，下面具體結(jié)合業(yè)務(wù)需求場(chǎng)景進(jìn)行敘述。

場(chǎng)景一：全文關(guān)鍵詞檢索

我想這個(gè)需求，絕大多數(shù)應(yīng)用都會(huì)有，如果使用傳統(tǒng)的數(shù)據(jù)庫(kù)技術(shù)，大部分可能都會(huì)使用like這種SQL語(yǔ)句，高級(jí)一點(diǎn)可能是先分詞，然后通過(guò)分詞index相關(guān)的記錄。SQL語(yǔ)句的性能問(wèn)題與全表掃描機(jī)制導(dǎo)致了非常嚴(yán)重的性能問(wèn)題，現(xiàn)在基本上很少見到。這里的ES是ElasticSearch的縮寫，是一種查詢引擎，類似的還有Solr等，都差不多的技術(shù)，ES較Solr配置簡(jiǎn)單、使用方便，所以這里選用了它。另外，ES支持橫向擴(kuò)展，理論上沒有性能的瓶頸。同時(shí)，還支持各種插件、自定義分詞器等，可擴(kuò)展性較強(qiáng)。在這里，使用ES不僅可以替代數(shù)據(jù)庫(kù)完成全文檢索功能，還可以實(shí)現(xiàn)諸如分頁(yè)、排序、分組、分面等功能。具體的，請(qǐng)同學(xué)們自行學(xué)習(xí)之。那怎么使用呢？一個(gè)一般的流程是這樣的：

服務(wù)端把一條業(yè)務(wù)數(shù)據(jù)落庫(kù)
服務(wù)端異步把該條數(shù)據(jù)發(fā)送到ES
ES把該條記錄按照規(guī)則、配置放入自己的索引庫(kù)
客戶端查詢的時(shí)候，由服務(wù)端把這個(gè)請(qǐng)求發(fā)送到ES，得到數(shù)據(jù)后，根據(jù)需求拼裝、組合數(shù)據(jù)，返回給客戶端

實(shí)際中怎么用，還請(qǐng)同學(xué)們根據(jù)實(shí)際情況做組合、取舍。

場(chǎng)景二：大量的普通查詢

這個(gè)場(chǎng)景是指我們的業(yè)務(wù)中的大部分輔助性的查詢，如：取錢的時(shí)候先查詢一下余額，根據(jù)用戶的ID查詢用戶的記錄，取得該用戶最新的一條取錢記錄等。我們肯定是要天天要用的，而且用的還非常多。同時(shí)呢，我們的寫入請(qǐng)求也是非常多的，導(dǎo)致大量的寫入、查詢操作壓向同一數(shù)據(jù)庫(kù)，然后，數(shù)據(jù)庫(kù)掛了，系統(tǒng)掛了，領(lǐng)導(dǎo)生氣了，被開除了，還不起房貸了，露宿街頭了，老婆跟別人跑了，......

不敢想，所以要求我們必須分散數(shù)據(jù)庫(kù)的壓力，一個(gè)業(yè)界較成熟的方案就是數(shù)據(jù)庫(kù)的讀寫分離，寫的時(shí)候入主庫(kù)，讀的時(shí)候讀從庫(kù)。這樣就把壓力分散到不同的數(shù)據(jù)庫(kù)了，如果一個(gè)讀庫(kù)性能不行，扛不住的話，可以一主多從，橫向擴(kuò)展。可謂是一劑良藥啊！那怎么使用呢？一個(gè)一般的流程是這樣的：

服務(wù)端把一條業(yè)務(wù)數(shù)據(jù)落庫(kù)
數(shù)據(jù)庫(kù)同步或異步或半同步把該條數(shù)據(jù)復(fù)制到從庫(kù)
服務(wù)端讀數(shù)據(jù)的時(shí)候直接去從庫(kù)讀相應(yīng)的數(shù)據(jù)

比較簡(jiǎn)單吧，一些聰明的、愛思考的、上進(jìn)的同學(xué)可能發(fā)現(xiàn)問(wèn)題了，也包括上面介紹的場(chǎng)景一，就是延遲問(wèn)題，如：數(shù)據(jù)還沒有到從庫(kù)，我就馬上讀，那么是讀不到的，會(huì)發(fā)生問(wèn)題的。對(duì)于這個(gè)問(wèn)題，各家公司解決的思路不一樣，方法不盡相同。一個(gè)普遍的解決方案是：讀不到就讀主庫(kù)，當(dāng)然這么說(shuō)也是有前提條件的，但具體的方案這里就不一一展開了，我可能會(huì)在接下來(lái)的分享中詳解各種方案。另外，關(guān)于數(shù)據(jù)庫(kù)的復(fù)制模式，還請(qǐng)同學(xué)們自行學(xué)習(xí)，太多了，這里說(shuō)不清。該總結(jié)一下這種模式的優(yōu)缺點(diǎn)的了，如下：

優(yōu)點(diǎn)：減少數(shù)據(jù)庫(kù)的壓力，理論上提供無(wú)限高的讀性能，間接提高業(yè)務(wù)(寫)的性能，專用的查詢、索引、全文(分詞)解決方案。
缺點(diǎn)：數(shù)據(jù)延遲，數(shù)據(jù)一致性的保證。

微服務(wù)模式

上面的模式看似不錯(cuò)，解決了性能問(wèn)題，我可以不用露宿街頭了、老婆還是我的，哈哈。但是軟件系統(tǒng)天生的復(fù)雜性決定了，除了性能，還有其他諸如高可用、健壯性等大量問(wèn)題等待我們解決，再加上各個(gè)部門間的撕逼、扯皮，更讓我們碼農(nóng)雪上加霜，所以

繼續(xù)吧......

微服務(wù)模式可以說(shuō)是最近的熱點(diǎn)，花花綠綠、大大小小、國(guó)內(nèi)國(guó)外的公司都在鼓吹，實(shí)踐這個(gè)模式，可是大部分都沒有弄清楚為什么要這么做，也并不知道這么做有什么好處、壞處，在這里，我將以我自己的親身實(shí)踐說(shuō)一下我對(duì)這個(gè)模式的看法，不喜勿噴！隨著業(yè)務(wù)與人員的增加，遇到了如下的問(wèn)題：

單機(jī)數(shù)據(jù)庫(kù)寫請(qǐng)求量大量增加，導(dǎo)致數(shù)據(jù)庫(kù)壓力變大
數(shù)據(jù)庫(kù)一旦掛了，那么整個(gè)業(yè)務(wù)都掛了
業(yè)務(wù)代碼越來(lái)越多，都在一個(gè)GIT里，越來(lái)越難以維護(hù)
代碼腐化嚴(yán)重、臭味越來(lái)越濃
上線越來(lái)越頻繁，經(jīng)常是一個(gè)小功能的修改，就要整個(gè)大項(xiàng)目要重新編譯
部門越來(lái)越多，該哪個(gè)部門改動(dòng)大項(xiàng)目中的哪個(gè)東西，撕逼的厲害
其他一些外圍系統(tǒng)直接連接數(shù)據(jù)庫(kù)，導(dǎo)致一旦數(shù)據(jù)庫(kù)結(jié)構(gòu)發(fā)生變化，所有的相關(guān)系統(tǒng)都要通知，甚至對(duì)修改不敏感的系統(tǒng)也要通知
每個(gè)應(yīng)用服務(wù)器需要開通所有的權(quán)限、網(wǎng)絡(luò)、FTP、各種各樣的，因?yàn)槊總€(gè)服務(wù)器部署的應(yīng)用都是一樣的
作為架構(gòu)師，我已經(jīng)失去了對(duì)這個(gè)系統(tǒng)的把控......

為了解決上述問(wèn)題，我司使用了微服務(wù)模式，這種模式的一般設(shè)計(jì)見下圖：

如上圖所示，我把業(yè)務(wù)分塊，做了垂直切分，切成一個(gè)個(gè)獨(dú)立的系統(tǒng)，每個(gè)系統(tǒng)各自衍化，有自己的庫(kù)、緩存、ES等輔助系統(tǒng)，系統(tǒng)之間的實(shí)時(shí)交互通過(guò)RPC，異步交互通過(guò)MQ，通過(guò)這種組合，共同完成整個(gè)系統(tǒng)功能。那么，這么做是否真的解決上述問(wèn)題了呢？不玩虛的，一個(gè)個(gè)來(lái)說(shuō)。對(duì)于問(wèn)題一，由于拆分成了多個(gè)子系統(tǒng)，系統(tǒng)的壓力被分散了，而各個(gè)子系統(tǒng)都有自己的數(shù)據(jù)庫(kù)實(shí)例，所以數(shù)據(jù)庫(kù)的壓力變小。

對(duì)于問(wèn)題二，一個(gè)子系統(tǒng)A的數(shù)據(jù)庫(kù)掛了，只是影響到系統(tǒng)A和使用系統(tǒng)A的那些功能，不會(huì)所有的功能不可用，從而解決一個(gè)數(shù)據(jù)庫(kù)掛了，導(dǎo)致所有功能不可用的問(wèn)題。

問(wèn)題三、四，也因?yàn)椴鸱值玫搅私鉀Q，各個(gè)子系統(tǒng)有自己獨(dú)立的GIT代碼庫(kù)，不會(huì)相互影響。通用的模塊可通過(guò)庫(kù)、服務(wù)、平臺(tái)的形式解決。

問(wèn)題五，子系統(tǒng)A發(fā)生改變，需要上線，那么我只需要編譯A，然后上線就可以了，不需要其他系統(tǒng)做同樣的事情。

問(wèn)題六，順應(yīng)了康威定律，我部門該干什么事、輸出什么，也通過(guò)服務(wù)的形式暴露出來(lái)，我部只管把我部的職責(zé)、軟件功能做好就可以。

問(wèn)題七，所有需要我部數(shù)據(jù)的需求，都通過(guò)接口的形式發(fā)布出去，客戶通過(guò)接口獲取數(shù)據(jù)，從而屏蔽了底層數(shù)據(jù)庫(kù)結(jié)構(gòu)，甚至數(shù)據(jù)來(lái)源，我部只需保證我部的接口契約沒有發(fā)生變化即可，新的需求增加新的接口，不會(huì)影響老的接口。

問(wèn)題八，不同的子系統(tǒng)需要不同的權(quán)限，這個(gè)問(wèn)題也優(yōu)雅的解決了。

問(wèn)題九，暫時(shí)控制住了復(fù)雜性，我只需控制好大的方面，定義好系統(tǒng)邊界、接口、大的流程，然后再分而治之、逐個(gè)擊破、合縱連橫。

目前來(lái)說(shuō)，所有問(wèn)題得到解決！bingo! 但是，還有許多其他的副作用會(huì)隨之產(chǎn)生，如RPC、MQ的超高穩(wěn)定性、超高性能，網(wǎng)絡(luò)延遲，數(shù)據(jù)一致性等問(wèn)題，這里就不展開來(lái)講了，太多了，一本書都講不完。

另外，對(duì)于這個(gè)模式來(lái)說(shuō)，最難把握的是度，切記不要切分過(guò)細(xì)，我見過(guò)一個(gè)功能一個(gè)子系統(tǒng)，上百個(gè)方法分成上百個(gè)子系統(tǒng)的，真的是太過(guò)度了。實(shí)踐中，一個(gè)較為可行的方法是：能不分就不分，除非有非常必要的理由！。

優(yōu)點(diǎn)：相對(duì)高性能，可擴(kuò)展性強(qiáng)，高可用，適合于中等以上規(guī)模公司架構(gòu)。

缺點(diǎn)：復(fù)雜、度不好把握。指不僅需要一個(gè)能在高層把控大方向、大流程、總體技術(shù)的人，還需要能夠針對(duì)各個(gè)子系統(tǒng)有針對(duì)性的開發(fā)。把握不好度或者濫用的話，這個(gè)模式適得其反！

多級(jí)緩存模式

這個(gè)模式可以說(shuō)是應(yīng)對(duì)超高查詢壓力的一種普遍采用的策略，基本的思想就是在所有鏈路的地方，能加緩存就加緩存，如下圖所示：

如上圖所示，一般在三個(gè)地方加入緩存，一個(gè)是客戶端處，一個(gè)是API網(wǎng)關(guān)處，一個(gè)是具體的后端業(yè)務(wù)處，下面分別介紹。

客戶端處緩存：這個(gè)地方加緩存可以說(shuō)是效果最好的---無(wú)延遲。因?yàn)椴挥媒?jīng)過(guò)長(zhǎng)長(zhǎng)的網(wǎng)絡(luò)鏈條去后端業(yè)務(wù)處獲取數(shù)據(jù)，從而導(dǎo)致加載時(shí)間過(guò)長(zhǎng)，客戶流失等損失。雖然有CDN的支持，但是從客戶端到CDN還是有網(wǎng)絡(luò)延遲的，雖然不大。具體的技術(shù)依據(jù)不同的客戶端而定，對(duì)于WEB來(lái)講，有瀏覽器本地緩存、Cookie、Storage、緩存策略等技術(shù)；對(duì)于APP來(lái)講，有本地?cái)?shù)據(jù)庫(kù)、本地文件、本地內(nèi)存、進(jìn)程內(nèi)緩存支持。以上提到的各種技術(shù)有興趣的同學(xué)可以繼續(xù)展開來(lái)學(xué)習(xí)。如果客戶端緩存沒有命中，那么就會(huì)去后端業(yè)務(wù)拿數(shù)據(jù)，一般來(lái)講，都會(huì)有個(gè)API網(wǎng)關(guān)，在這里加緩存也是非常有必要的。

API網(wǎng)關(guān)處緩存：這個(gè)地方加緩存的好處是不用把請(qǐng)求發(fā)送到后方，直接在這里就處理了，然后返回給請(qǐng)求者。常見的技術(shù)，如http請(qǐng)求，API網(wǎng)關(guān)用的基本都是nginx，可以使用nginx本身的緩存模塊，也可以使用Lua+Redis技術(shù)定制化。其他的也都大同小異。

后端業(yè)務(wù)處：這個(gè)我想就不用多說(shuō)了，大家應(yīng)該差不多都知道，什么Redis,Memcache,Jvm內(nèi)等等，不熬述了。

實(shí)踐中，要結(jié)合具體的實(shí)際情況，綜合利用各級(jí)緩存技術(shù)，使得各種請(qǐng)求最大程度的在到達(dá)后端業(yè)務(wù)之前就被解決掉，從而減少后端服務(wù)壓力、減少占用帶寬、增強(qiáng)用戶體驗(yàn)。至于是否只有這三個(gè)地方加緩存，我覺得要活學(xué)活用，**心法比劍法重要！**總結(jié)一下這個(gè)模式的優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：抗住大量讀請(qǐng)求，減少后端壓力。
缺點(diǎn)：數(shù)據(jù)一致性問(wèn)題較突出，容易發(fā)生雪崩，即：如果客戶端緩存失效、API網(wǎng)關(guān)緩存失效，那么所有的大量請(qǐng)求瞬間壓向后端業(yè)務(wù)系統(tǒng)，后果可想而知。

分???庫(kù)分表模式

這種模式主要解決單表寫入、讀取、存儲(chǔ)壓力過(guò)大，從而導(dǎo)致業(yè)務(wù)緩慢甚至超時(shí)，交易失敗，容量不夠的問(wèn)題。一般有水平切分和垂直切分兩種，這里主要介紹水平切分。這個(gè)模式也是技術(shù)架構(gòu)迭代演進(jìn)過(guò)程中的必經(jīng)之路。這種模式的一般設(shè)計(jì)見下圖：

如上圖所示紅色部分，把一張表分到了幾個(gè)不同的庫(kù)中，從而分擔(dān)壓力。是不是很籠統(tǒng)？哈哈，那我們接下來(lái)就詳細(xì)的講解一下。首先澄清幾個(gè)概念，如下：

主機(jī)：硬件，指一臺(tái)物理機(jī)，或者虛擬機(jī)，有自己的CPU，內(nèi)存，硬盤等。
實(shí)例：數(shù)據(jù)庫(kù)實(shí)例，如一個(gè)MySQL服務(wù)進(jìn)程。一個(gè)主機(jī)可以有多個(gè)實(shí)例，不同的實(shí)例有不同的進(jìn)程，監(jiān)聽不同的端口。
庫(kù)：指表的集合，如學(xué)校庫(kù)，可能包含教師表、學(xué)生表、食堂表等等，這些表在一個(gè)庫(kù)中。一個(gè)實(shí)例中可以有多個(gè)庫(kù)。庫(kù)與庫(kù)之間用庫(kù)名來(lái)區(qū)分。
表：庫(kù)中的表，不必多說(shuō)，不懂的就不用往下看了，不解釋。
那么怎么把單表分散呢？到底怎么個(gè)分發(fā)呢？分發(fā)到哪里呢？以下是幾個(gè)工作中的實(shí)踐，分享一下：
主機(jī)：這是最主要的也是最重要的點(diǎn)，本質(zhì)上分庫(kù)分表是因?yàn)橛?jì)算與存儲(chǔ)資源不夠?qū)е碌模@種資源主要是由物理機(jī)，主機(jī)提供的，所以在這里分是最基本的，畢竟沒有可用的計(jì)算資源，怎么分效果都不是太好的。
實(shí)例：實(shí)例控制著連接數(shù)，同時(shí)受OS限制，CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)IO也會(huì)受間接影響。會(huì)出現(xiàn)熱實(shí)例的現(xiàn)象，即：有些實(shí)例特別忙，有些實(shí)例非常的空閑。一個(gè)典型的現(xiàn)象是：由于單表反應(yīng)慢，導(dǎo)致連接池被打滿，所有其他的業(yè)務(wù)都受影響了。這時(shí)候，把表分到不同的實(shí)例是有一些效果的。
庫(kù)：一般是由于單庫(kù)中最大單表數(shù)量的限制，才采取分庫(kù)。
表：?jiǎn)伪韷毫^(guò)大，索引量大，容量大，單表的鎖。據(jù)以上，把單表水平切分成不同的表。

大型應(yīng)用中，都是一臺(tái)主機(jī)上只有一個(gè)實(shí)例，一個(gè)實(shí)例中只有一個(gè)庫(kù)，庫(kù)==實(shí)例==主機(jī)，所以才有了分庫(kù)分表這個(gè)簡(jiǎn)稱。

既然知道了基本理論，那么具體是怎么做的呢？邏輯是怎么跑的呢？接下來(lái)以一個(gè)例子來(lái)講解一下。這個(gè)需求很簡(jiǎn)單，用戶表(user)，單表數(shù)據(jù)量1億，查詢、插入、存儲(chǔ)都出現(xiàn)了問(wèn)題，怎么辦呢？

首先，分析問(wèn)題，這個(gè)明顯是由于數(shù)據(jù)量太大了而導(dǎo)致的問(wèn)題。其次，設(shè)計(jì)方案，可以分為10個(gè)庫(kù)，這樣每個(gè)庫(kù)的數(shù)據(jù)量就降到了1KW，單表1KW數(shù)據(jù)量還是有些大，而且不利于以后量的增長(zhǎng)，所以每個(gè)庫(kù)再分100個(gè)表，這個(gè)每個(gè)單表數(shù)據(jù)量就為10W了，對(duì)于查詢、索引更新、單表文件大小、打開速度，都有一些益處。接下來(lái)，給IT部門打電話，要10臺(tái)物理機(jī)，擴(kuò)展數(shù)據(jù)庫(kù)...... 最后，邏輯實(shí)現(xiàn)，這里應(yīng)該是最有學(xué)問(wèn)的地方。首先是寫入數(shù)據(jù)，需要知道寫到哪個(gè)分庫(kù)分表中，讀也是一樣的，所以，需要有個(gè)請(qǐng)求路由層，負(fù)責(zé)把請(qǐng)求分發(fā)、轉(zhuǎn)換到不同的庫(kù)表中，一般有路由規(guī)則的概念。

怎么樣，簡(jiǎn)單吧？哈哈，too 那義務(wù)。說(shuō)說(shuō)這個(gè)模式的問(wèn)題，主要是帶來(lái)了事務(wù)上的問(wèn)題，因?yàn)榉謳?kù)分表，事務(wù)完成不了，而分布式事務(wù)又太笨重，所以這里需要有一定的策略，保證在這種情況下事務(wù)能夠完成。采取的策略如：最終一致性、復(fù)制、特殊設(shè)計(jì)等。再有就是業(yè)務(wù)代碼的改造，一些關(guān)聯(lián)查詢要改造，一些單表orderBy的問(wèn)題需要特殊處理，也包括groupBy語(yǔ)句，如何解決這些副作用不是一句兩句能說(shuō)清楚的，以后有時(shí)間，我單獨(dú)講講這些。

該總結(jié)一下這種模式的優(yōu)缺點(diǎn)的了，如下：

優(yōu)點(diǎn)：減少數(shù)據(jù)庫(kù)單表的壓力。

缺點(diǎn)：事務(wù)保證困難、業(yè)務(wù)邏輯需要做大量改造。

彈性伸縮模式

這種模式主要解決突發(fā)流量的到來(lái)，導(dǎo)致無(wú)法橫向擴(kuò)展或者橫向擴(kuò)展太慢，進(jìn)而影響業(yè)務(wù)，全站崩潰的問(wèn)題。這個(gè)模式是一種相對(duì)來(lái)說(shuō)比較高級(jí)的技術(shù)，也是各個(gè)大公司目前都在研究、試用的技術(shù)。截至今日，有這種思想的架構(gòu)師就已經(jīng)是很不錯(cuò)了，能夠拿到較高薪資，更別提那些已經(jīng)實(shí)踐過(guò)的，甚至實(shí)現(xiàn)了底層系統(tǒng)的那些，所以，你懂得...... 這種模式的一般設(shè)計(jì)見下圖：

如上圖所示，多了一個(gè)彈性伸縮服務(wù)，用來(lái)動(dòng)態(tài)的增加、減少實(shí)例。原理上非常簡(jiǎn)單，但是這個(gè)模式到底解決什么問(wèn)題呢？先說(shuō)說(shuō)由來(lái)和意義。

每年的雙11、六一八或者一些大促到來(lái)之前，我們都會(huì)為大流量的到來(lái)做以下幾個(gè)方面的工作: 提前準(zhǔn)備10倍甚至更多的機(jī)器，即使用不上也要放在那里備著，以防萬(wàn)一。這樣浪費(fèi)了大量的資源。每臺(tái)機(jī)器配置、調(diào)試、引流，以便讓所有的機(jī)器都可用。這樣浪費(fèi)了大量的人力、物力，更容易出錯(cuò)。如果機(jī)器準(zhǔn)備不充分，那么還要加班加點(diǎn)的重復(fù)上面的工作。這樣做特別容易出錯(cuò)，引來(lái)領(lǐng)導(dǎo)的不滿，沒時(shí)間回家陪老婆，然后你的老婆就......(自己想)

在雙十一之后，我們還要人工做縮容，非常的辛苦。一般一年中會(huì)有多次促銷，那么我們就會(huì)一直這樣，實(shí)在是煩！

最嚴(yán)重的，突然間的大流量爆發(fā)，會(huì)讓我們觸不及防，半夜起來(lái)擴(kuò)容是在正常不過(guò)的事情，為此，我們偷懶起來(lái)，要更多的機(jī)器備著，也就出現(xiàn)了大量的cpu利用率為1%的機(jī)器。

我相信，如果你是老板一定很震驚吧！！！哈哈，那么如何改變這種情況呢？請(qǐng)接著看

為此，首先把所有的計(jì)算資源整合成資源池的概念，然后通過(guò)一些策略、監(jiān)控、服務(wù)，動(dòng)態(tài)的從資源池中獲取資源，用完后在放回到池子中，供其他系統(tǒng)使用。具體實(shí)現(xiàn)上比較成熟的兩種資源池方案是VM、docker，每個(gè)都有著自己強(qiáng)大的生態(tài)。監(jiān)控的點(diǎn)有CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)IO、服務(wù)質(zhì)量等，根據(jù)這些，在配合一些預(yù)留、擴(kuò)張、收縮策略，就可以簡(jiǎn)單的實(shí)現(xiàn)自動(dòng)伸縮。怎么樣？是不是很神奇？

該總結(jié)一下這種模式的優(yōu)缺點(diǎn)的了，如下：

優(yōu)點(diǎn)：彈性、隨需計(jì)算，充分優(yōu)化企業(yè)計(jì)算資源。
缺點(diǎn)：應(yīng)用要從架構(gòu)層做到可橫向擴(kuò)展化改造、依賴的底層配套比較多，對(duì)技術(shù)水平、實(shí)力、應(yīng)用規(guī)模要求較高。

多機(jī)房模式

這種模式主要解決不同地區(qū)高性能、高可用的問(wèn)題。

隨著應(yīng)用用戶不斷的增加，用戶群體分布在全球各地，如果把服務(wù)器部署在一個(gè)地方，一個(gè)機(jī)房，比如北京，那么美國(guó)的用戶使用應(yīng)用的時(shí)候就會(huì)特別慢，因?yàn)槊恳粋€(gè)請(qǐng)求都需要通過(guò)海底光纜走上個(gè)那么一秒鐘(預(yù)估)左右，這樣對(duì)用戶體驗(yàn)及其不好。怎么辦？使用多機(jī)房部署。

這種模式的一般設(shè)計(jì)見下圖：

如上圖所示，一個(gè)典型的用戶請(qǐng)求流程如下：

用戶請(qǐng)求一個(gè)鏈接A 通過(guò)DNS智能解析到離用戶最近的機(jī)房B 使用B機(jī)房服務(wù)鏈接A

是不是覺得很簡(jiǎn)單，沒啥？其實(shí)這里面的問(wèn)題沒有表面這么簡(jiǎn)單，下面一一道來(lái)。首先是數(shù)據(jù)同步問(wèn)題，在中國(guó)產(chǎn)生的數(shù)據(jù)要同步到美國(guó)，美國(guó)的也一樣，數(shù)據(jù)同步就會(huì)涉及數(shù)據(jù)版本、一致性、更新丟棄、刪除等問(wèn)題。其次是一地多機(jī)房的請(qǐng)求路由問(wèn)題，典型的是如上圖，中國(guó)的北京機(jī)房和杭州機(jī)房，如果北京機(jī)房掛了，那么要能夠通過(guò)路由把所有發(fā)往北京機(jī)房的請(qǐng)求轉(zhuǎn)發(fā)到杭州機(jī)房。異地也存在這個(gè)問(wèn)題。

所以，多機(jī)房模式，也就是異地多活并不是那么的簡(jiǎn)單，這里只是起了個(gè)頭，具體的有哪些坑，會(huì)在另一篇文章中介紹。

該總結(jié)一下這種模式的優(yōu)缺點(diǎn)的了，如下：