除了復(fù)雜度坑赡，互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展的另外兩個關(guān)鍵特點是“高性能”和“高可用”衡奥。通常情況下瓤介，我們在設(shè)計高可用和高性能系統(tǒng)的時候吕喘，主要關(guān)注點在系統(tǒng)本身的復(fù)雜度，然后通過各種手段來實現(xiàn)高可用和高性能的要求刑桑，例如我前面介紹的計算高性能架構(gòu)模式氯质、存儲高可用架構(gòu)模式等。但是當(dāng)我們站在一個公司的的角度來思考架構(gòu)的時候祠斧，單個系統(tǒng)的高可用和高性能并不等于整體業(yè)務(wù)的高可用和高性能闻察，互聯(lián)網(wǎng)業(yè)務(wù)的高性能和高可用需要從更高的角度去設(shè)計，這個高點就是“網(wǎng)絡(luò)”琢锋，所以我將相關(guān)措施統(tǒng)一劃歸為“網(wǎng)絡(luò)層”辕漂。注意這里的網(wǎng)絡(luò)層和通常理解的如何搭建一個局域網(wǎng)這種概念不一樣，這里強調(diào)的是站在網(wǎng)絡(luò)層的角度整體設(shè)計架構(gòu)吴超，而不是某個具體網(wǎng)絡(luò)的搭建钉嘹。

接下來我將介紹互聯(lián)網(wǎng)架構(gòu)模板的“網(wǎng)絡(luò)層”技術(shù)的幾個關(guān)鍵架構(gòu)設(shè)計點，部分內(nèi)容專欄前面已經(jīng)有深入闡述鲸阻，今天作為概要的總結(jié)把它們歸納一下跋涣。

負載均衡

顧名思議缨睡，負載均衡就是將請求均衡地分配到多個系統(tǒng)上。使用負載均衡的原因也很簡單：每個系統(tǒng)的處理能力是有限的陈辱，為了應(yīng)對大容量的訪問奖年，必須使用多個系統(tǒng)。例如沛贪，一臺 32 核 64GB 內(nèi)存的機器陋守，性能測試數(shù)據(jù)顯示每秒處理 Hello World 的 HTTP 請求不超過 2 萬，實際業(yè)務(wù)機器處理 HTTP 請求每秒可能才幾百 QPS利赋，而互聯(lián)網(wǎng)業(yè)務(wù)并發(fā)超過 1 萬是比較常見的水评，遇到雙十一、過年發(fā)紅包這些極端場景隐砸，每秒可以達到幾十萬的請求之碗。

1.DNS

DNS 是最簡單也是最常見的負載均衡方式蝙眶，一般用來實現(xiàn)地理級別的均衡季希。例如，北方的用戶訪問北京的機房幽纷，南方的用戶訪問廣州的機房式塌。一般不會使用 DNS 來做機器級別的負載均衡，因為太耗費 IP 資源了友浸。例如峰尝，百度搜索可能要 10000 臺以上機器，不可能將這么多機器全部配置公網(wǎng) IP收恢，然后用 DNS 來做負載均衡武学。有興趣的讀者可以在 Linux 用“dig?baidu.com”命令看看實際上用了幾個 IP 地址。

DNS 負載均衡的優(yōu)點是通用（全球通用）伦意、成本低（申請域名火窒，注冊 DNS 即可），但缺點也比較明顯驮肉，主要體現(xiàn)在：

DNS 緩存的時間比較長熏矿，即使將某臺業(yè)務(wù)機器從 DNS 服務(wù)器上刪除，由于緩存的原因离钝，還是有很多用戶會繼續(xù)訪問已經(jīng)被刪除的機器票编。

DNS 不夠靈活。DNS 不能感知后端服務(wù)器的狀態(tài)卵渴，只能根據(jù)配置策略進行負載均衡慧域，無法做到更加靈活的負載均衡策略。比如說某臺機器的配置比其他機器要好很多浪读，理論上來說應(yīng)該多分配一些請求給它昔榴，但 DNS 無法做到這一點宛裕。

所以對于時延和故障敏感的業(yè)務(wù)，有實力的公司可能會嘗試實現(xiàn)HTTP-DNS的功能论泛，即使用 HTTP 協(xié)議實現(xiàn)一個私有的 DNS 系統(tǒng)揩尸。HTTP-DNS 主要應(yīng)用在通過 App 提供服務(wù)的業(yè)務(wù)上，因為在 App 端可以實現(xiàn)靈活的服務(wù)器訪問策略屁奏，如果是 Web 業(yè)務(wù)岩榆，實現(xiàn)起來就比較麻煩一些，因為 URL 的解析是由瀏覽器來完成的坟瓢，只有 Javascript 的訪問可以像 App 那樣實現(xiàn)比較靈活的控制勇边。

HTTP-DNS 的優(yōu)缺點有：

靈活：HTTP-DNS 可以根據(jù)業(yè)務(wù)需求靈活的設(shè)置各種策略。

可控：HTTP-DNS 是自己開發(fā)的系統(tǒng)折联，IP 更新粒褒、策略更新等無需依賴外部服務(wù)商。

及時：HTTP-DNS 不受傳統(tǒng) DNS 緩存的影響诚镰，可以非侈确兀快地更新數(shù)據(jù)、隔離故障清笨。

開發(fā)成本高：沒有通用的解決方案月杉，需要自己開發(fā)。

侵入性：需要 App 基于 HTTP-DNS 進行改造抠艾。

2.Nginx 苛萎、LVS 、F5

DNS 用于實現(xiàn)地理級別的負載均衡检号，而 Nginx腌歉、LVS、F5 用于同一地點內(nèi)機器級別的負載均衡齐苛。其中 Nginx 是軟件的 7 層負載均衡翘盖，LVS 是內(nèi)核的 4 層負載均衡，F(xiàn)5 是硬件的 4 層負載均衡脸狸。

軟件和硬件的區(qū)別就在于性能最仑，硬件遠遠高于軟件，Ngxin 的性能是萬級炊甲，一般的 Linux 服務(wù)器上裝個 Nginx 大概能到 5 萬 / 秒泥彤；LVS 的性能是十萬級，沒有具體測試過卿啡，據(jù)說可達到 80 萬 / 秒吟吝；F5 性能是百萬級，從 200 萬 / 秒到 800 萬 / 秒都有颈娜。硬件雖然性能高剑逃，但是單臺硬件的成本也很高浙宜，一臺最便宜的 F5 都是幾十萬，但是如果按照同等請求量級來計算成本的話蛹磺，實際上硬件負載均衡設(shè)備可能會更便宜粟瞬，例如假設(shè)每秒處理 100 萬請求，用一臺 F5 就夠了萤捆，但用 Nginx裙品，可能要 20 臺，這樣折算下來用 F5 的成本反而低俗或。因此通常情況下市怎，如果性能要求不高，可以用軟件負載均衡辛慰；如果性能要求很高区匠，推薦用硬件負載均衡。

4 層和 7 層的區(qū)別就在于協(xié)議和靈活性帅腌。Nginx 支持 HTTP驰弄、E-mail 協(xié)議，而 LVS 和 F5 是 4 層負載均衡狞膘，和協(xié)議無關(guān)揩懒，幾乎所有應(yīng)用都可以做，例如聊天挽封、數(shù)據(jù)庫等。

目前很多云服務(wù)商都已經(jīng)提供了負載均衡的產(chǎn)品臣镣，例如阿里云的 SLB辅愿、UCloud 的 ULB 等，中小公司直接購買即可忆某。

CDN

CDN 是為了解決用戶網(wǎng)絡(luò)訪問時的“最后一公里”效應(yīng)点待，本質(zhì)上是一種“以空間換時間”的加速策略，即將內(nèi)容緩存在離用戶最近的地方弃舒，用戶訪問的是緩存的內(nèi)容癞埠，而不是站點實時的內(nèi)容。

下面是簡單的 CDN 請求流程示意圖：

（https://docs.qingcloud.com/product/network/_images/cdn_principle.png）

CDN 經(jīng)過多年的發(fā)展聋呢，已經(jīng)變成了一個很龐大的體系：分布式存儲苗踪、全局負載均衡、網(wǎng)絡(luò)重定向削锰、流量控制等都屬于 CDN 的范疇通铲，尤其是在視頻、直播等領(lǐng)域器贩，如果沒有 CDN颅夺，用戶是不可能實現(xiàn)流暢觀看內(nèi)容的朋截。

幸運的是，大部分程序員和架構(gòu)師都不太需要深入理解 CDN 的細節(jié)吧黄，因為 CDN 作為網(wǎng)絡(luò)的基礎(chǔ)服務(wù)部服，獨立搭建的成本巨大，很少有公司自己設(shè)計和搭建 CDN 系統(tǒng)拗慨，從 CDN 服務(wù)商購買 CDN 服務(wù)即可饲宿，目前有專門的 CDN 服務(wù)商，例如網(wǎng)宿和藍汛胆描；也有云計算廠家提供 CDN 服務(wù)瘫想，例如阿里云和騰訊云都提供 CDN 的服務(wù)。

多機房

從架構(gòu)上來說昌讲，單機房就是一個全局的網(wǎng)絡(luò)單點国夜，在發(fā)生比較大的故障或者災(zāi)害時，單機房難以保證業(yè)務(wù)的高可用短绸。例如车吹，停電、機房網(wǎng)絡(luò)中斷醋闭、地震窄驹、水災(zāi)等都有可能導(dǎo)致一個機房完全癱瘓。

多機房設(shè)計最核心的因素就是如何處理時延帶來的影響证逻，常見的策略有：

1. 同城多機房

同一個城市多個機房乐埠，距離不會太遠，可以投入重金囚企，搭建私有的高速網(wǎng)絡(luò)丈咐，基本上能夠做到和同機房一樣的效果。

這種方式對業(yè)務(wù)影響很小龙宏，但投入較大棵逊，如果不是大公司，一般是承受不起的银酗；而且遇到極端的地震辆影、水災(zāi)等自然災(zāi)害，同城多機房也是有很大風(fēng)險的黍特。

2. 跨城多機房

在不同的城市搭建多個機房蛙讥，機房間通過網(wǎng)絡(luò)進行數(shù)據(jù)復(fù)制（例如，MySQL 主備復(fù)制）衅澈，但由于跨城網(wǎng)絡(luò)時延的問題键菱，業(yè)務(wù)上需要做一定的妥協(xié)和兼容，比如不需要數(shù)據(jù)的實時強一致性，只是保證最終一致性经备。

例如拭抬，微博類產(chǎn)品，B 用戶關(guān)注了 A 用戶侵蒙，A 用戶在北京機房發(fā)布了一條微博造虎，B 在廣州機房不需要立刻看到 A 用戶發(fā)的微博，等 10 分鐘看到也可以纷闺。

這種方式實現(xiàn)簡單算凿，但和業(yè)務(wù)有很強的相關(guān)性，微博可以這樣做犁功，支付寶的轉(zhuǎn)賬業(yè)務(wù)就不能這樣做氓轰，因為用戶余額是強一致性的。

3. 跨國多機房

和跨城多機房類似浸卦，只是地理上分布更遠署鸡，時延更大。由于時延太大和用戶跨國訪問實在太慢限嫌，跨國多機房一般僅用于備份和服務(wù)本國用戶靴庆。

多中心

多中心必須以多機房為前提，但從設(shè)計的角度來看怒医，多中心相比多機房是本質(zhì)上的飛越炉抒，難度也高出一個等級。

簡單來說稚叹，多機房的主要目標是災(zāi)備焰薄，當(dāng)機房故障時，可以比較快速地將業(yè)務(wù)切換到另外一個機房入录，這種切換操作允許一定時間的中斷（例如蛤奥，10 分鐘、1 個小時）索烹，而且業(yè)務(wù)也可能有損失（例如逆巍，某些未同步的數(shù)據(jù)不能馬上恢復(fù)，或者要等幾天才恢復(fù)，甚至永遠都不能恢復(fù)了）堪滨。因此相比多機房來說，多中心的要求就高多了鳖粟，要求每個中心都同時對外提供服務(wù)禾唁，且業(yè)務(wù)能夠自動在多中心之間切換，故障后不需人工干預(yù)或者很少的人工干預(yù)就能自動恢復(fù)迟蜜。

多中心設(shè)計的關(guān)鍵就在于“數(shù)據(jù)一致性”和“數(shù)據(jù)事務(wù)性”如何保證刹孔，這兩個難點都和業(yè)務(wù)緊密相關(guān)，目前沒有很成熟的且通用的解決方案娜睛，需要基于業(yè)務(wù)的特性進行詳細的分析和設(shè)計髓霞。以淘寶為例卦睹，淘寶對外宣稱自己是多中心的，但是在實際設(shè)計過程中方库，商品瀏覽的多中心方案结序、訂單的多中心方案、支付的多中心方案都需要獨立設(shè)計和實現(xiàn)纵潦。

正因為多中心設(shè)計的復(fù)雜性徐鹤，不一定所有業(yè)務(wù)都能實現(xiàn)多中心，目前國內(nèi)的銀行邀层、支付寶這類系統(tǒng)就沒有完全實現(xiàn)多中心返敬，不然也不會出現(xiàn)挖掘機一鏟子下去，支付寶中斷 4 小時的故障寥院。

有關(guān)多中心設(shè)計更詳細的內(nèi)容劲赠，你可以查看專欄第28、29只磷、30期的內(nèi)容经磅。

小結(jié)

今天我為你講了互聯(lián)網(wǎng)架構(gòu)模板中的“網(wǎng)絡(luò)層”技術(shù)，希望對你有所幫助钮追。

這就是今天的全部內(nèi)容预厌，留一道思考題給你吧，為什么可以購買負載均衡和 CDN 服務(wù)元媚，但卻不能購買多機房和多中心服務(wù)轧叽？

歡迎你把答案寫到留言區(qū)，和我一起討論刊棕。相信經(jīng)過深度思考的回答炭晒，也會讓你對知識的理解更加深刻。（編輯亂入：精彩的留言有機會獲得豐厚福利哦Ｉ恰）