[[437209]]

互聯(lián)網(wǎng)的系統(tǒng)常常面臨龐大的用戶群體，意味著系統(tǒng)需要時(shí)刻面臨著大量高并發(fā)請求，海量的數(shù)據(jù)存儲(chǔ)等問題的挑戰(zhàn)，在解決這些問題的同時(shí)還要保證系統(tǒng)的高可用性。同時(shí)互聯(lián)網(wǎng)行業(yè)更新迭代快，很多互聯(lián)網(wǎng)巨頭的發(fā)展初始階段，為了快速把產(chǎn)品上線發(fā)布以占據(jù)用戶流量，會(huì)以最簡單的應(yīng)用架構(gòu)形態(tài)對系統(tǒng)進(jìn)行部署，不會(huì)過多地考慮未來的應(yīng)用架構(gòu)的發(fā)展，所以很多互聯(lián)網(wǎng)公司發(fā)展到一定規(guī)模，都會(huì)進(jìn)行相應(yīng)的架構(gòu)重構(gòu)與改進(jìn)，以便適應(yīng)業(yè)務(wù)的發(fā)展。

我這幾年經(jīng)歷過很多家公司，從幾個(gè)開發(fā)人員的小公司到擁有 10+ 億用戶規(guī)模的公司都經(jīng)歷過，因此我對互聯(lián)網(wǎng)公司的系統(tǒng)應(yīng)用架構(gòu)的演進(jìn)有著一些深刻的感悟。

單點(diǎn)應(yīng)用

公司發(fā)展初期，由于用戶量少，系統(tǒng)的并發(fā)請求并不高，且數(shù)據(jù)量少，往往只需要將應(yīng)用單點(diǎn)部署即可滿足業(yè)務(wù)的需求：

以上就是一個(gè)典型的早期互聯(lián)網(wǎng)應(yīng)用的架構(gòu)模式，應(yīng)用只需要部署在單臺服務(wù)器上，甚至數(shù)據(jù)庫都放在同一臺服務(wù)器，流量直上直下，一桿子到底。

由于應(yīng)用和數(shù)據(jù)庫都是單體形式，所以缺點(diǎn)明顯，不能進(jìn)行故障轉(zhuǎn)移，一旦應(yīng)用或者數(shù)據(jù)庫其中之一遇到故障，則整個(gè)系統(tǒng)不可用。

應(yīng)用 SOA 化

1、水平拆分

單體應(yīng)用缺乏故障轉(zhuǎn)移，同時(shí)隨著請求數(shù)量的增多，單體應(yīng)用部署的請求處理不過來了，常見的問題是應(yīng)用連接數(shù)被打滿，用戶的請求超時(shí)，而且響應(yīng)耗時(shí)長。

如上圖所示，將系統(tǒng)進(jìn)行水平化拆分，部署多個(gè)應(yīng)用實(shí)例，同時(shí)網(wǎng)關(guān)將流量進(jìn)行平均分配，有效減少單個(gè)應(yīng)用的請求壓力，同時(shí)應(yīng)用服務(wù)具備故障轉(zhuǎn)移，當(dāng)服務(wù)遇到故障，只要還保持著一個(gè)以上應(yīng)用實(shí)例，系統(tǒng)就能夠運(yùn)轉(zhuǎn)(還需要考慮降級處理)。

這是初級的應(yīng)用 SOA 化階段。

2、垂直拆分

隨著公司業(yè)務(wù)的高速發(fā)展，業(yè)務(wù)的體量越來越大，一個(gè)應(yīng)用承載了全部的業(yè)務(wù)，所有的業(yè)務(wù)代碼都放在同一個(gè)代碼倉庫中，雖然這樣容易部署，運(yùn)維成本低，但缺點(diǎn)非常明顯，隨著業(yè)務(wù)的體量越來越大，項(xiàng)目的代碼急劇增加，各個(gè)業(yè)務(wù)間的越來越復(fù)雜，耦合度越來越高。而且擴(kuò)展性隨著代碼量的增多越來越差，而且發(fā)布周期窗口會(huì)越來越長，無法做到快速迭代快速上線。

為了解決以上問題，我們可以對系統(tǒng)按照業(yè)務(wù)的維度進(jìn)行垂直拆分，比如商城系統(tǒng)，可以拆分成用戶服務(wù)、交易服務(wù)、訂單服務(wù)等，如上圖所示。

到這里，系統(tǒng)經(jīng)過水平拆分和垂直拆分，應(yīng)用層基本完成了 SOA 化。

存儲(chǔ)拆分

1、存儲(chǔ)讀寫分離

隨著業(yè)務(wù)的發(fā)展，這時(shí)發(fā)現(xiàn)應(yīng)用服務(wù)不再是負(fù)擔(dān)，但數(shù)據(jù)層成為了整個(gè)系統(tǒng)的唯一單點(diǎn)，這時(shí)候，隨著系統(tǒng) TPS 的增多，應(yīng)用的實(shí)例部署越來越多，單個(gè)數(shù)據(jù)庫的連接數(shù)變多，數(shù)據(jù)的寫入效率變慢了，單主庫無法維持整個(gè)系統(tǒng)的數(shù)據(jù)讀寫。

這時(shí)將數(shù)據(jù)層進(jìn)行讀寫分離，將數(shù)據(jù)庫拆分成一個(gè)主數(shù)據(jù)庫和若干個(gè)從數(shù)據(jù)庫，數(shù)據(jù)的寫入還是由主數(shù)據(jù)庫負(fù)責(zé)，讀數(shù)據(jù)則由從數(shù)據(jù)庫負(fù)責(zé)，這樣就可以大大減輕了數(shù)據(jù)寫入的負(fù)擔(dān)。但讀寫分離就是讀和寫不是嚴(yán)格同步的，主數(shù)據(jù)庫同步數(shù)據(jù)給從數(shù)據(jù)庫需要一定的時(shí)間，但大部分的數(shù)據(jù)延遲都能夠接受。

2、存儲(chǔ)垂直拆分

數(shù)據(jù)讀寫分離之后，數(shù)據(jù)寫入減輕了一定的負(fù)擔(dān)，但我們發(fā)現(xiàn)，整個(gè)系統(tǒng)全局只有只有一個(gè)主庫，各個(gè)業(yè)務(wù)域的數(shù)據(jù)寫入都嚴(yán)重依賴于這個(gè)主庫，流量一旦上來，單主數(shù)據(jù)庫根本扛不住。

與應(yīng)用垂直拆分類似，存儲(chǔ)層的垂直拆分，同樣根據(jù)業(yè)務(wù)維度去拆分，拆分成若干個(gè)庫，比如商城系統(tǒng)，可以拆分成用戶庫、訂單庫等。從上圖可以看到，數(shù)據(jù)寫入的流量，各個(gè)業(yè)務(wù)域獨(dú)自負(fù)擔(dān)自己的數(shù)據(jù)讀寫。

至此，一個(gè)基本完整的分布式應(yīng)用架構(gòu)基本成型了，隨之而來的就是要解決因數(shù)據(jù)庫拆分而伴生的分布式事務(wù)問題。

3、存儲(chǔ)水平拆分

當(dāng)業(yè)務(wù)發(fā)展到一定量級，單庫單表不足以承擔(dān)起各自業(yè)務(wù)域的數(shù)據(jù)讀寫，那這時(shí)怎么辦呢?

這時(shí)我們可以按照用戶維度，對數(shù)據(jù)進(jìn)行水平拆分，比如按照用戶 ID 最后兩位，將一張大表切分成 100 張小表，再新建 100 個(gè)庫(當(dāng)然數(shù)據(jù)庫可以少于表的數(shù)量)，我們可以將這種分庫分表規(guī)則稱為百庫百表模式。

分庫分表可以有效減少單表數(shù)據(jù)的數(shù)據(jù)量，還可以按照用戶維度將流量分散到各個(gè)庫和表中，性能得到了全面的提升。

至此，一個(gè)完整的分布式架構(gòu)已經(jīng)成型，事實(shí)上這是很多大型互聯(lián)網(wǎng)公司當(dāng)前的部署架構(gòu)現(xiàn)狀。

單元化部署

隨著業(yè)務(wù)的進(jìn)一步發(fā)展，類似某些擁有 10 億+用戶量級的巨頭公司，因此他們的應(yīng)用實(shí)例部署規(guī)模都非常大，這隨著而來會(huì)伴隨著數(shù)據(jù)庫連接數(shù)量不夠的問題，從上圖我們可以看出，隨著應(yīng)用實(shí)例的增加，數(shù)據(jù)庫的鏈接數(shù)量就會(huì)增多。

為什么呢?

因?yàn)槊總€(gè)數(shù)據(jù)庫的實(shí)例，都是被應(yīng)用實(shí)例所共享的，那你可能要問為什么要共享，那是因?yàn)榫W(wǎng)關(guān)的流量是按平均分配的，你的每個(gè)請求，都有可能落到任意的應(yīng)用實(shí)例中，那么這時(shí)應(yīng)用實(shí)例就必須要根據(jù)你的用戶 ID，將數(shù)據(jù)落在指定的表中，這時(shí)應(yīng)用實(shí)例必須要擁有所有數(shù)據(jù)庫的連接才能做到。

那么像 10 億+用戶量級的系統(tǒng)，本身流量已經(jīng)非常高了，每當(dāng)讓服務(wù)進(jìn)行水平擴(kuò)容，都異常艱難，甚至已經(jīng)到了數(shù)據(jù)庫連接的上限，服務(wù)不能繼續(xù)水平擴(kuò)容了。

那應(yīng)該怎么辦?

既然數(shù)據(jù)可以按照用戶維度進(jìn)行分庫分表，那么請求的流量何嘗不能按照用戶維度進(jìn)行水平拆分呢?

我們將按照用戶維度對應(yīng)用實(shí)例進(jìn)行單元化隔離，每個(gè)單元都部署了系統(tǒng)所有的服務(wù)，用戶可在某個(gè)單元內(nèi)走完所有的業(yè)務(wù)流程，如下圖所示：

可以看出，經(jīng)過單元化隔離，數(shù)據(jù)庫的連接數(shù)量成倍地減少，如果單元化粒度拆分更小，那么數(shù)據(jù)庫的連接數(shù)量會(huì)更少。

數(shù)據(jù)分區(qū)

對于大型互聯(lián)網(wǎng)公司來說，往往擁有多個(gè)物理機(jī)房，在多個(gè)機(jī)房中，部署模式主要分成兩種：

垂直部署(擴(kuò)展模式)：將系統(tǒng)的服務(wù)、數(shù)據(jù)庫劃分為若干份，每個(gè)機(jī)房擁有部分服務(wù)和數(shù)據(jù)庫，這樣可以解決機(jī)房容量問題，但是要完成一個(gè)業(yè)務(wù)，可能需要經(jīng)過多個(gè)機(jī)房協(xié)作，且某個(gè)機(jī)房出現(xiàn)故障，會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用，不具備容災(zāi)能力;

水平部署(鏡像模式)：每個(gè)機(jī)房擁有所有的服務(wù)，即每個(gè)機(jī)房都能夠完成一個(gè)業(yè)務(wù)的流轉(zhuǎn)，具備容災(zāi)能力。

一般大多數(shù)公司都會(huì)采用第二種水平部署模式，但是這種模式下，需要解決數(shù)據(jù)分區(qū)問題，我們知道應(yīng)用都是無狀態(tài)的，我們可以很容易地將流量隨機(jī)分配給各個(gè)機(jī)房，讓每個(gè)機(jī)房承載一定的流量。但是數(shù)據(jù)卻不行，要做到每個(gè)機(jī)房擁有獨(dú)立的數(shù)據(jù)庫是一件挺難的事情。

那怎么解決數(shù)據(jù)分區(qū)問題呢?

前面我們已經(jīng)談到單元化部署，由于一個(gè)單元包含了系統(tǒng)所有的服務(wù)，我們可將其稱作一個(gè)邏輯數(shù)據(jù)中心(Logical Data Center)，簡稱 LDC。

同樣，水平部署模式下，一個(gè)物理機(jī)房也擁有所有的服務(wù)，我們可將其稱作一個(gè)互聯(lián)網(wǎng)數(shù)據(jù)中心(Internet Data Center)，簡稱 IDC。

那么，它們的關(guān)系：

LDC 是對 IDC 的一種邏輯劃分。

用大白話講就是：

LDC 則是在 IDC 的基礎(chǔ)上進(jìn)行的一個(gè)邏輯劃分，一個(gè) LDC 邏輯數(shù)據(jù)中心被稱為一個(gè)「單元」，每個(gè)單元都擁有所有部署的應(yīng)用，每個(gè)單元可以分配到任意一個(gè)物理機(jī)房，每個(gè)物理機(jī)房可以擁有若干個(gè)單元，如下圖所示：

如上圖所示，物理機(jī)房在水平部署模式下，單元化如何解決數(shù)據(jù)分區(qū)問題呢?

前面我們說了我們按照用戶維度進(jìn)行單元化隔離部署的，那么我們也可以對數(shù)據(jù)進(jìn)行分區(qū)，將數(shù)據(jù)按照用戶維度對數(shù)據(jù)進(jìn)行分區(qū)，比如將用戶最后 2 位進(jìn)行數(shù)據(jù)分區(qū)，一共將數(shù)據(jù)拆分成 100 份，每個(gè)單元負(fù)責(zé)若干份數(shù)據(jù)，比如系統(tǒng)一共有 10 個(gè)單元，那么每個(gè)單元負(fù)責(zé) 10 個(gè)分區(qū)的數(shù)據(jù)。

這樣，每個(gè)單元下都有獨(dú)立的數(shù)據(jù)分區(qū)，完全可以做到數(shù)據(jù)的隔離。

如何擴(kuò)容

在單元化部署架構(gòu)下，如何進(jìn)行擴(kuò)容呢?

應(yīng)用擴(kuò)容

系統(tǒng)經(jīng)過單元化隔離部署之后，通常情況下數(shù)據(jù)庫連接已不再是瓶頸，這也是單元化部署帶來的收益之一，這時(shí)我們很容易通過將單元中的每個(gè)服務(wù)增加若干個(gè)應(yīng)用實(shí)例來達(dá)到擴(kuò)容的目的。

單元擴(kuò)容

增加單元數(shù)量，增加后的每個(gè)單元，流量重新分配，但需要注意的是，增加單元數(shù)據(jù)，并不意味著數(shù)據(jù)分區(qū)會(huì)增加，數(shù)據(jù)層與應(yīng)用層的擴(kuò)容完全沒有關(guān)系，但值得一提的是，單元擴(kuò)容可以有效減少數(shù)據(jù)庫的連接數(shù)，每個(gè)單元所連接的數(shù)據(jù)分區(qū)，是按照單元所負(fù)責(zé)的用戶維度的流量來區(qū)分的，如下圖所示：

存儲(chǔ)擴(kuò)容

增加一個(gè)單元很容易，但是要在原有的數(shù)據(jù)分區(qū)下進(jìn)行擴(kuò)容，就不好做了，因?yàn)樯婕暗奖砺酚梢?guī)則的變更，需要對數(shù)據(jù)進(jìn)行遷移，且一般在進(jìn)行分庫分表時(shí)，都會(huì)提前預(yù)估未來業(yè)務(wù)的容量需求，各個(gè)用戶維度已經(jīng)提前進(jìn)行了 Pre-Sharding 處理了，所以如果數(shù)據(jù)要進(jìn)行擴(kuò)容，則需要對數(shù)據(jù)進(jìn)行重新 sharding 處理，這里涉及到數(shù)據(jù)遷移，就不細(xì)展開了。

本文轉(zhuǎn)載自微信公眾號「后端進(jìn)階」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系后端進(jìn)階公眾號。