譯者 | 陳峻

審校 | 重樓

你可能知曉，在大型科技公司計(jì)劃為數(shù)百萬(wàn)用戶提供服務(wù)時(shí)，系統(tǒng)的可擴(kuò)展性能力通常需要從一開(kāi)始就成為設(shè)計(jì)的一部分，而不應(yīng)在后期被追加。否則，隨著用戶期望的不斷攀升和全球流量模式的變化，該系統(tǒng)將根本無(wú)法應(yīng)對(duì)。下面，我將向你介紹大型科技公司通常會(huì)如何看待大規(guī)模的可擴(kuò)展性，他們?cè)诂F(xiàn)實(shí)世界中的有效策略（不僅僅是理論），以及可用性、成本、可觀察性是如何在系統(tǒng)設(shè)計(jì)中被結(jié)合到一起的。

可擴(kuò)展性為何重要？

一個(gè)龐大的系統(tǒng)，不可避免地會(huì)面臨硬件失效、網(wǎng)絡(luò)問(wèn)題、甚至是數(shù)據(jù)中心癱瘓等潛在威脅。對(duì)此，人們通常的做法是：

• 將系統(tǒng)分解為單獨(dú)的部分，以便某個(gè)故障不會(huì)拖累其他部分
• 不僅需要備份服務(wù)器，也應(yīng)備份數(shù)據(jù)庫(kù)、存儲(chǔ)庫(kù)、甚至是整個(gè)地理區(qū)域的系統(tǒng)
• 持續(xù)執(zhí)行運(yùn)行狀況檢查，并設(shè)置自動(dòng)故障轉(zhuǎn)移，以實(shí)現(xiàn)無(wú)需人工干預(yù)的恢復(fù)
• 根據(jù)實(shí)時(shí)需求擴(kuò)展或縮減系統(tǒng)資源
• 密切監(jiān)視系統(tǒng)行為，以便在其出現(xiàn)重大中斷之前，捕獲早期警告信號(hào)

當(dāng)然，上述做法并非一勞永逸之事。運(yùn)維團(tuán)隊(duì)需要持續(xù)根據(jù)真實(shí)情況和經(jīng)驗(yàn)教訓(xùn)，不斷改進(jìn)系統(tǒng)的可擴(kuò)展性。

跨區(qū)域擴(kuò)展系統(tǒng)

多區(qū)域部署策略

提高可擴(kuò)展性的一項(xiàng)明智舉措是將系統(tǒng)分布在不同區(qū)域。AWS 和 GCP 等平臺(tái)就是這樣構(gòu)建的。由于它們?cè)诓煌瑓^(qū)域被設(shè)計(jì)為相互隔離，因此每個(gè)區(qū)域都可以獨(dú)立的方式運(yùn)行，即使有整個(gè)區(qū)域系統(tǒng)出現(xiàn)離線的狀況，其他區(qū)域的系統(tǒng)也能夠繼續(xù)運(yùn)行。而且，該區(qū)域的用戶也會(huì)被自動(dòng)路由到運(yùn)行狀況良好的區(qū)域，進(jìn)而讓用戶甚至不會(huì)注意到本區(qū)域的系統(tǒng)出現(xiàn)了故障。

目前，科技公司通常采取兩種方法來(lái)實(shí)現(xiàn)數(shù)據(jù)的跨區(qū)域復(fù)制：

• 異步復(fù)制：雖然效率更高，但是一旦災(zāi)難在關(guān)鍵時(shí)間點(diǎn)發(fā)生，用戶可能會(huì)丟失一些最新尚未完成同步的數(shù)據(jù)。
• 同步復(fù)制：對(duì)于關(guān)鍵數(shù)據(jù)來(lái)說(shuō)更安全，但是勢(shì)必會(huì)引入一些因前一項(xiàng)同步未完成，而造成的延遲。

大多數(shù)實(shí)際架構(gòu)最終都會(huì)將兩種方法混合在一起。也就是說(shuō)，具體該如何設(shè)置，往往取決于系統(tǒng)的哪些部分可以承受哪一類的風(fēng)險(xiǎn)。

前文提到了區(qū)域隔離。其實(shí)，并非每個(gè)系統(tǒng)都需要多區(qū)域的設(shè)置。業(yè)界也有公司將多個(gè)可用部分部署在單個(gè)區(qū)域內(nèi)，以處理大量數(shù)據(jù)。對(duì)于那些關(guān)鍵性的服務(wù)和任務(wù)、以及面對(duì)非常嚴(yán)格的合規(guī)性要求時(shí)（如“兩地三中心”），多區(qū)域設(shè)計(jì)仍然是非常必要的。

設(shè)置正確的故障轉(zhuǎn)移計(jì)劃

設(shè)置正確的故障轉(zhuǎn)移計(jì)劃

每個(gè)可擴(kuò)展的系統(tǒng)都需要有可靠的故障轉(zhuǎn)移策略作為支撐。通常，我們有兩種轉(zhuǎn)移模型可供選擇：

• 主+主設(shè)置：是讓多個(gè)節(jié)點(diǎn)或區(qū)域同時(shí)處理實(shí)時(shí)流量。如果一個(gè)節(jié)點(diǎn)出現(xiàn)故障，另一個(gè)節(jié)點(diǎn)會(huì)立即接手。該模型幾乎為系統(tǒng)提供了零停機(jī)時(shí)間，不過(guò)需要團(tuán)隊(duì)非常小心地維持同步和平衡。
• 主+被設(shè)置：讓一個(gè)活躍節(jié)點(diǎn)執(zhí)行所有工作，而另一個(gè)備用節(jié)點(diǎn)則處于空閑狀態(tài)，等待故障。該模型更簡(jiǎn)單、更便宜，但在切換期間可能會(huì)出現(xiàn)短暫的中斷。

無(wú)論你選擇哪種模型，定期的故障轉(zhuǎn)移測(cè)試都是必須的，畢竟模擬失敗和恢復(fù)演練是大型系統(tǒng)運(yùn)維團(tuán)隊(duì)必須具備的基本能力。

使用自動(dòng)擴(kuò)展為流量峰值做準(zhǔn)備

如果你的系統(tǒng)無(wú)法隨流量的變化進(jìn)行自動(dòng)調(diào)節(jié)，那么請(qǐng)求峰值一旦出現(xiàn)，系統(tǒng)就可能出現(xiàn)大量延時(shí)甚至中斷。這也就是需要引入自動(dòng)擴(kuò)展（Auto Scaling）工具的必要所在。此類工具允許你的系統(tǒng)能夠根據(jù)實(shí)時(shí)使用情況的特征數(shù)據(jù)（如 CPU 負(fù)載、內(nèi)存使用情況或請(qǐng)求數(shù)量），自動(dòng)添加或刪除資源。在此基礎(chǔ)上，預(yù)測(cè)性的自動(dòng)擴(kuò)展工具可以根據(jù)歷史模式，預(yù)測(cè)需求高峰的到來(lái)，例如，在黑色星期五大促開(kāi)始之前提前擴(kuò)容。

當(dāng)然，擴(kuò)展需要在整個(gè)技術(shù)棧中進(jìn)行，并涉及：Web 服務(wù)器、數(shù)據(jù)庫(kù)、緩存、消息隊(duì)列等任何可能造成瓶頸的薄弱環(huán)節(jié)。

值得注意的是：自動(dòng)擴(kuò)展策略需要經(jīng)過(guò)測(cè)試與驗(yàn)證，以調(diào)整好智能閾值、冷卻期和開(kāi)銷監(jiān)控。否則，你最終可能會(huì)既浪費(fèi)資源，又推高成本，還未實(shí)現(xiàn)預(yù)期的效果。

微服務(wù)：通過(guò)分解來(lái)處理故障

微服務(wù)架構(gòu)的優(yōu)勢(shì)

目前，微服務(wù)已成為構(gòu)建具有可擴(kuò)展能力的大規(guī)模系統(tǒng)的首選架構(gòu)。其基本思想是將一個(gè)大的系統(tǒng)拆分成許多較小的、集中的服務(wù)。而且這些服務(wù)能夠通過(guò) API 來(lái)相互通信。因此，該方法帶來(lái)了如下好處：

• 如果有一項(xiàng)服務(wù)失效，其損害會(huì)得到控制，而不會(huì)導(dǎo)致整個(gè)系統(tǒng)的癱瘓。
• 每一項(xiàng)服務(wù)都可以根據(jù)自己的需求進(jìn)行獨(dú)立擴(kuò)展。
• 運(yùn)維團(tuán)隊(duì)可以只更新部分服務(wù)，而不會(huì)影響到系統(tǒng)中不相關(guān)的部分。
• 各項(xiàng)服務(wù)可以分別使用適合其自身需求的最佳技術(shù)。

當(dāng)然，微服務(wù)也帶來(lái)了一定的復(fù)雜性。運(yùn)維團(tuán)隊(duì)需要管理諸如：服務(wù)發(fā)現(xiàn)、分布式跟蹤、集中式日志記錄、以及更復(fù)雜的部署管道等方面。

雖然微服務(wù)并非免費(fèi)，但是如果你的目標(biāo)是在大型系統(tǒng)中實(shí)現(xiàn)可擴(kuò)展性、以及快速迭代的話，此類技術(shù)仍然值得大規(guī)模采用。

可觀察性：獲悉系統(tǒng)是否正常運(yùn)行

在復(fù)雜的系統(tǒng)中，可觀察性往往可以從如下三個(gè)方面，讓你領(lǐng)先于問(wèn)題的惡化，了解其根本原因：

• 通過(guò)各項(xiàng)指標(biāo)的展示，為你提供有關(guān)錯(cuò)誤率、延遲、吞吐量和資源使用情況等方面的數(shù)據(jù)。
• 通過(guò)日志記錄整個(gè)系統(tǒng)中的事件，以便你可以在出現(xiàn)問(wèn)題時(shí)進(jìn)行調(diào)查。
• 通過(guò)分布式跟蹤允許你跨多個(gè)服務(wù)跟蹤單個(gè)請(qǐng)求，以查找和定位瓶頸或故障點(diǎn)。

為了達(dá)到上述三個(gè)方面的可觀察性，運(yùn)維團(tuán)隊(duì)通常需要使用諸如： AWS CloudWatch、X-Ray 等平臺(tái)，以及 Prometheus 和 Jaeger 等開(kāi)源工具，給系統(tǒng)和應(yīng)用構(gòu)建控制面板、綜合檢測(cè)、主動(dòng)運(yùn)行狀況監(jiān)控、以及警報(bào)服務(wù)。

真正關(guān)鍵的不在于工具，而是確保系統(tǒng)從一開(kāi)始就本著易于觀察和故障排除的初衷予以搭建?？梢?jiàn)，良好的可觀察性不但可以為運(yùn)營(yíng)團(tuán)隊(duì)縮短事件的發(fā)現(xiàn)時(shí)間，易于找到根本原因，而且能夠協(xié)助團(tuán)隊(duì)在故障真正影響到用戶之前，被及時(shí)修復(fù)。

管理三平衡：成本、速度和可擴(kuò)展性

成本、速度和可擴(kuò)展性

在實(shí)踐中，構(gòu)建可擴(kuò)展的系統(tǒng)往往需要從如下三個(gè)方面做出權(quán)衡與取舍：

• 強(qiáng)一致性雖然可以為你提供更安全的數(shù)據(jù)保障，但是可能會(huì)降低系統(tǒng)的運(yùn)行效率。
• 高可用性架構(gòu)的基礎(chǔ)設(shè)施往往成本更高，但是能夠?yàn)槟惚苊飧蟮耐C(jī)損失。
• 復(fù)雜的設(shè)計(jì)雖然可以為你提供強(qiáng)大的可擴(kuò)展性，但是可能會(huì)讓后期維護(hù)遇到困難。

對(duì)于不同規(guī)模和重要程度的系統(tǒng)而言，有時(shí)候，大型科研公司必須投入大量的資金，以避免哪怕一分鐘的停機(jī)時(shí)間。不過(guò)，再有錢的公司也無(wú)法做到360度無(wú)死角的高可用性，因此他們需要根據(jù)系統(tǒng)中的數(shù)據(jù)價(jià)值，通過(guò)模擬故障，對(duì)停機(jī)可能對(duì)業(yè)務(wù)造成的影響進(jìn)行建模，并運(yùn)行混沌測(cè)試的方式，發(fā)現(xiàn)真正的弱點(diǎn)，以最終做出深思熟慮的取舍。

小結(jié)

綜上所述，對(duì)于大型科技公司而言，在全球范圍內(nèi)構(gòu)建可靠的系統(tǒng)是一項(xiàng)艱巨的工作。它往往需要仔細(xì)的規(guī)劃、深思熟慮的權(quán)衡、時(shí)刻保持警惕，以及致力于從每一次故障中吸取教訓(xùn)。因此，系統(tǒng)構(gòu)建者應(yīng)該將可擴(kuò)展性視為一個(gè)持續(xù)改進(jìn)系統(tǒng)容錯(cuò)能力、提供出色的用戶體驗(yàn)的過(guò)程，而不是一次性的項(xiàng)目。下面四點(diǎn)建議希望能給構(gòu)建者們起到提醒作用：

• 可擴(kuò)展性應(yīng)在架構(gòu)設(shè)計(jì)期間考慮，而不是在后期被追加。
• 每次事件發(fā)生后，各個(gè)團(tuán)隊(duì)?wèi)?yīng)開(kāi)展無(wú)指責(zé)的復(fù)盤，并專注于改進(jìn)與提升。
• 系統(tǒng)變更需謹(jǐn)慎，通常可以參照金絲雀（Canary）等部署策略一起推出。
• 混沌工程可以被用于主動(dòng)測(cè)試系統(tǒng)在大量請(qǐng)求壓力下的行為狀況。

就可擴(kuò)展性本身而言，我們并沒(méi)有放之四海而皆準(zhǔn)的答案。其構(gòu)建程度完全取決于你的用戶、你的業(yè)務(wù)、以及那些你絕對(duì)無(wú)法承受的中斷類型。

譯者介紹

陳峻（Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn)。

原文標(biāo)題：How Large Tech Companies Architect Resilient Systems for Millions of Users，作者：Ravi Teja Thutari