譯者 | 陳峻

審校 | 重樓

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

可擴展性為何重要？

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

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

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

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

多區(qū)域部署策略

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

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

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

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

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

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

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

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

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

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

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

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

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

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

微服務(wù)：通過分解來處理故障

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

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

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

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

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

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

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

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

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

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

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

成本、速度和可擴展性

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

• 強一致性雖然可以為你提供更安全的數(shù)據(jù)保障，但是可能會降低系統(tǒng)的運行效率。
• 高可用性架構(gòu)的基礎(chǔ)設(shè)施往往成本更高，但是能夠為你避免更大的停機損失。
• 復(fù)雜的設(shè)計雖然可以為你提供強大的可擴展性，但是可能會讓后期維護遇到困難。

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

小結(jié)

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

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

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

譯者介紹

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

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