作者 | Durai Arasan

譯者 | 張衛(wèi)濱

本文分享了擴(kuò)展云和分布式應(yīng)用程序的目標(biāo)與策略，重點(diǎn)介紹了摩根大通（JPMorgan Chase）旗下 Chase.com 在云遷移過程中汲取的經(jīng)驗(yàn)教訓(xùn)。

討論圍繞三個核心目標(biāo)展開，詳細(xì)闡述了實(shí)現(xiàn)這些目標(biāo)的具體策略，最后說明了這些方法在實(shí)踐中的落地方式。對于管理大規(guī)模系統(tǒng)的從業(yè)者而言，這些經(jīng)驗(yàn)源自我們在摩根大通及其他金融機(jī)構(gòu)多年來的實(shí)戰(zhàn)積累，具有寶貴的指導(dǎo)意義。

在規(guī)劃的時候，人們通常只會考慮兩到三倍的負(fù)載增長。然而，一旦系統(tǒng)部署在互聯(lián)網(wǎng)上，就無法控制入站流量的規(guī)模、時間或使用模式。任何事件（無論是源于合法業(yè)務(wù)增長，還是惡意攻擊者的行為）都可能引發(fā)巨大的負(fù)載激增。這兩種情形各自會帶來截然不同的挑戰(zhàn)。

安全控制措施可以阻止惡意流量，但當(dāng)市場波動引發(fā)真實(shí)客戶需求激增時，情況則有所不同?？蛻羟∏谶@些情況下需要訪問金融交易服務(wù)。在系統(tǒng)壓力下，多個組件可能同時發(fā)生故障；網(wǎng)絡(luò)設(shè)備、負(fù)載均衡器、應(yīng)用程序和數(shù)據(jù)庫連接都可能同時中斷。

目 ? ? 標(biāo)

我們的云遷移聚焦于三大核心目標(biāo)：以成本效益高且高效的方式實(shí)現(xiàn)彈性擴(kuò)展、實(shí)現(xiàn)高韌性（這對金融機(jī)構(gòu)尤為重要），以及提供卓越性能，防止因系統(tǒng)遲緩而迫使用戶轉(zhuǎn)向其他服務(wù)。

高效擴(kuò)展

實(shí)現(xiàn)高效性需要分析客戶的使用模式和行為。組織必須在保持彈性擴(kuò)展能力的同時，發(fā)展預(yù)測能力。

流量整形（Traffic shaping）提供了一種識別高頻率功能的方法論，從而能夠有針對性地對關(guān)鍵應(yīng)用進(jìn)行擴(kuò)展。

整體容量管理是另一個關(guān)鍵要素。簡單地增加服務(wù)器并不能保證成功，還需要仔細(xì)權(quán)衡成本的因素。

流量模式與容量規(guī)劃

流量模式是高效擴(kuò)展的基礎(chǔ)。平均流量代表了系統(tǒng)日常處理的基準(zhǔn)水平。可預(yù)測的模式確實(shí)存在，例如，工資入賬等周期性事件會促使客戶查詢賬戶余額。全年還會出現(xiàn)季節(jié)性高峰，這要求提前規(guī)劃。

突發(fā)事件則會帶來不同的挑戰(zhàn)。DDoS 攻擊頻繁發(fā)生，其流量可能超過正常負(fù)載十倍甚至更高。攻擊者利用的是與合法用戶相同的云資源。組織必須在阻斷這些攻擊的同時，確保合法客戶的真實(shí)交易仍能滿足服務(wù)等級協(xié)議（SLA）。

基于已知模式進(jìn)行合理的容量規(guī)劃有助于預(yù)防運(yùn)維方面的問題。然而，彈性擴(kuò)展存在局限性：在擴(kuò)展過程中，應(yīng)用程序需要啟動并建立與服務(wù)及數(shù)據(jù)庫的連接，而建立連接需要時間。從實(shí)例啟動到完全就緒，可能已經(jīng)過去數(shù)分鐘。若大量請求恰好在此期間涌入，系統(tǒng)將面臨資源爭用的問題。

因此，不能僅依賴彈性擴(kuò)展，而應(yīng)該全面考慮完整的運(yùn)維圖景，包括流量模式及相關(guān)因素。預(yù)留計(jì)算容量（Reserved compute capacity）可以應(yīng)對這些挑戰(zhàn)。預(yù)留資源能在需要時保證可用性，尤其在多租戶共享資源池出現(xiàn)爭用時更為關(guān)鍵。此外，預(yù)留計(jì)算還能帶來成本節(jié)約。

成本管理需要進(jìn)行持續(xù)關(guān)注。應(yīng)該定期（如每月或每周）應(yīng)用 FinOps 流程，而非偶爾為之。

超越單純增加服務(wù)器的擴(kuò)展

擴(kuò)展不應(yīng)該局限于簡單地增加服務(wù)器。當(dāng)發(fā)生擴(kuò)展時，有一個根本性的問題，那就是，應(yīng)用程序是否真的因?yàn)檎鎸?shí)客戶的需求而需要擴(kuò)展，還是因?yàn)樯嫌畏?wù)排隊(duì)導(dǎo)致響應(yīng)變慢？當(dāng)線程等待響應(yīng)而無法執(zhí)行時，CPU 和內(nèi)存的壓力會上升，即使實(shí)際需求并未增長，也會觸發(fā)彈性擴(kuò)展。

這種場景要求我們在設(shè)計(jì)中考慮容錯，并將其與擴(kuò)展策略整合。斷路器（Circuit breaker）在此過程中會發(fā)揮關(guān)鍵作用。當(dāng)上游服務(wù)變慢或失敗時，斷路器可以防止應(yīng)用無限期等待響應(yīng)，而是強(qiáng)制設(shè)置超時限制：系統(tǒng)要么在限定窗口內(nèi)收到成功響應(yīng)，要么快速失敗并繼續(xù)處理。這種設(shè)計(jì)可避免線程耗盡、減少不必要的資源消耗，并防止錯誤地觸發(fā)擴(kuò)展。如果沒有斷路器的話，緩慢的依賴項(xiàng)可能會引發(fā)全系統(tǒng)的性能退化，導(dǎo)致彈性擴(kuò)展，從而添加更多無法解決根本問題的服務(wù)器。

高韌性

韌性（Resiliency）要求為不可避免的系統(tǒng)故障做好準(zhǔn)備。早期檢測和隨時執(zhí)行故障轉(zhuǎn)移程序至關(guān)重要。然而，為所有組件實(shí)現(xiàn) 100% 的可用性既不現(xiàn)實(shí)，也無必要。

基礎(chǔ)設(shè)施可根據(jù)關(guān)鍵性分為四個層級。關(guān)鍵（Critical）類的組件必須盡可能接近 100% 可用。DNS 就屬此類，無論網(wǎng)站架構(gòu)多么完善，DNS 如果出現(xiàn)故障將會導(dǎo)致所有訪問中斷。

可管理（Manageable）層的組件在發(fā)生故障時可通過故障轉(zhuǎn)移維持運(yùn)行，目標(biāo)為“四個九”的可用性（99.99%，即每年可接受約 52 分鐘的停機(jī)時間）。

可容忍（Tolerable）層的組件具備內(nèi)置韌性。例如，緩存長期數(shù)據(jù)的令牌服務(wù)，若服務(wù)在緩存有效期內(nèi)不可用，系統(tǒng)仍可使用已緩存的數(shù)據(jù)繼續(xù)運(yùn)行。

最后，可接受（Acceptable）層的組件允許有限的數(shù)據(jù)丟失，比如，某些日志系統(tǒng)。韌性目標(biāo)由影響的嚴(yán)重程度決定。

性能

性能會顯著影響用戶體驗(yàn)和基礎(chǔ)設(shè)施成本，但并非所有應(yīng)用程序的表現(xiàn)完全相同。通過部署接入點(diǎn)（Point of Presence, PoP）可以提升用戶體驗(yàn)，因?yàn)樗鼘W(wǎng)站延遲（尤其在移動設(shè)備上）尤為敏感。

速度至關(guān)重要，因?yàn)樗芙⒂脩粜湃?，用戶期望更快、更好的體驗(yàn)。谷歌等搜索引擎已經(jīng)認(rèn)識到這一點(diǎn)，并將速度納入其排名算法。在網(wǎng)絡(luò)連接受限的場景下，移動端性能尤為關(guān)鍵。從基礎(chǔ)設(shè)施角度看，客戶完成相同任務(wù)所花費(fèi)的時間越少，運(yùn)營成本就越低。

我們通過實(shí)施全面的性能策略，從初始部署到完整架構(gòu)落地，系統(tǒng)延遲降低了 71%。這些策略可適配其他業(yè)務(wù)場景。

五大核心策略

架構(gòu)方法圍繞五個重點(diǎn)領(lǐng)域展開：多區(qū)域部署、高性能優(yōu)化、全面自動化、具備自愈能力的可觀測性，以及強(qiáng)大的安全性。

多區(qū)域部署

多區(qū)域架構(gòu)通過隔離和分段實(shí)現(xiàn)功能化的解耦。這種方法有助于管理區(qū)域故障、可用區(qū)故障和網(wǎng)絡(luò)故障，并限制故障的爆炸半徑（blast radius）。面對 9400 萬客戶，可用區(qū)級別的故障可被限制為僅影響一小部分用戶，而非全部用戶。

實(shí)現(xiàn)多區(qū)域架構(gòu)需要解決 DNS 管理的問題，因?yàn)椴煌瑓^(qū)域擁有獨(dú)立的負(fù)載均衡器，需要協(xié)調(diào)一致。還需要確定區(qū)域間流量的調(diào)度策略。在包含多個可用區(qū)的區(qū)域內(nèi)，也需選擇流量的分配方式。

可用區(qū)故障

假設(shè)一個負(fù)載均衡器將流量分發(fā)至同一區(qū)域內(nèi)的兩個可用區(qū)。兩個應(yīng)用均報(bào)告健康狀態(tài)，可用區(qū)看似正常，流量持續(xù)流入。然而，如果其中一個可用區(qū)的應(yīng)用與后端系統(tǒng)連接異常，而另一可用區(qū)正常，流量仍將流入受損的可用區(qū)。若應(yīng)用雖實(shí)現(xiàn)了就緒（readiness）和存活（liveness）探針，卻未將依賴系統(tǒng)狀態(tài)納入健康檢查，那么就有可能出現(xiàn)問題。缺乏適當(dāng)?shù)姆答仚C(jī)制時，負(fù)載均衡器會繼續(xù)路由流量，導(dǎo)致應(yīng)用失敗。

針對這種情況，解決方案包括將依賴系統(tǒng)的健康狀態(tài)通過就緒或存活探針反饋給負(fù)載均衡器，或采用基于代理的重路由機(jī)制將流量導(dǎo)向正常的可用區(qū)。這需要有效管理內(nèi)外部故障，以應(yīng)對應(yīng)用停機(jī)。

區(qū)域性的故障

在多區(qū)域部署中，我們依賴統(tǒng)一的區(qū)域健康脈搏檢查（每 10 秒執(zhí)行一次），以確保對區(qū)域健康狀況的一致性和及時可見性。在這里，關(guān)鍵的決策在于，故障是否需要完全切換至備用區(qū)域，或者降級服務(wù)是否可接受。降級服務(wù)的可行性取決于應(yīng)用的分段情況。若關(guān)鍵服務(wù)（如儀表盤首頁）失效，則需要故障轉(zhuǎn)移；若非關(guān)鍵組件失效，那么可以繼續(xù)運(yùn)行以避免更大的影響。但故障轉(zhuǎn)移會引發(fā)“驚群效應(yīng)”（thundering herd），例如，整個區(qū)域失效時，重定向流量突增可能壓垮剩余區(qū)域，而自動擴(kuò)展需要時間才能提供額外的容量。健康檢查標(biāo)準(zhǔn)（包括失敗與成功閾值）決定了對應(yīng)的響應(yīng)策略。

多區(qū)域的挑戰(zhàn)

跨區(qū)域的數(shù)據(jù)復(fù)制與確保數(shù)據(jù)一致性是主要的關(guān)注點(diǎn)。當(dāng)數(shù)據(jù)中心位置有限而客戶遍布全國時，客戶分片（customer sharding）是一種可行的方案：將客戶按地理位置分片，并由就近的數(shù)據(jù)中心提供服務(wù)，這樣可以減少復(fù)制的需求，并簡化架構(gòu)。

狀態(tài)管理需要戰(zhàn)略性的決策。為活躍會話維護(hù)會話親和性（session affinity），并在必要時支持故障轉(zhuǎn)移，這有助于高效運(yùn)行。

高性能

高性能對用戶體驗(yàn)至關(guān)重要。良好的性能如同可靠的撥號音，用戶期望即時響應(yīng)，不容延遲。邊緣計(jì)算是實(shí)現(xiàn)性能目標(biāo)的主要手段?，F(xiàn)代網(wǎng)站具有復(fù)雜的用戶界面，內(nèi)容密集。我們可將靜態(tài)內(nèi)容卸載至靠近客戶的入網(wǎng)點(diǎn)（Point of Presence，PoP），而源服務(wù)器（origin server）僅處理動態(tài)操作和關(guān)鍵服務(wù)，如登錄、賬戶、支付等。

流量整形（traffic shaping）可以對流量進(jìn)行分類。關(guān)鍵流量指的是支撐業(yè)務(wù)運(yùn)營的核心功能，比如，客戶日常的登錄、余額查詢和支付。分配給關(guān)鍵服務(wù)的資源必須始終保持運(yùn)行。在壓力條件下，即便其他流量出現(xiàn)降級也是可以接受的。

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

地理分布會顯著影響性能。如果每次資源請求都需要跨越很長的距離，物理網(wǎng)絡(luò)的屏障將會造成顯著的延遲。如果相同的內(nèi)容已在 PoP 緩存，檢索可在 100 毫秒內(nèi)完成，遠(yuǎn)優(yōu)于訪問源站所需的較長響應(yīng)時間（比如，大于 500 毫秒）。性能提升的同時會帶來安全方面的收益，因?yàn)閻阂獾牧髁靠梢栽谶吘壉粩r截。

“最后一公里連接（last-mile connectivity）”的問題值得關(guān)注?；ヂ?lián)網(wǎng)通信涉及多個網(wǎng)絡(luò)跳轉(zhuǎn)。邊緣計(jì)算改變了這一模式，從用戶到邊緣節(jié)點(diǎn)通常只需要一跳，再結(jié)合優(yōu)化的網(wǎng)絡(luò)傳輸，這樣所帶來的效率遠(yuǎn)高于標(biāo)準(zhǔn)的 ISP-to-ISP 連接。

移動應(yīng)用也有優(yōu)化的空間。移動設(shè)備具備本地存儲，可用于緩存網(wǎng)絡(luò)解析結(jié)果、配置設(shè)置和預(yù)抓取的內(nèi)容。

自動化

自動化是關(guān)鍵的戰(zhàn)略元素。在整個流水線的各個階段實(shí)施全面自動化可帶來巨大收益，這需要涵蓋部署、基礎(chǔ)設(shè)施供應(yīng)、環(huán)境配置、集成自動化操作的健康檢查，以及整體的流量管理。

架構(gòu)不能止步于文檔。通過創(chuàng)建“帶有傾向性的（opinionated）”架構(gòu)模板，可以幫助團(tuán)隊(duì)構(gòu)建自動繼承架構(gòu)標(biāo)準(zhǔn)的應(yīng)用。應(yīng)用通過基于清單（manifest）定義進(jìn)行自動化部署，這樣能夠讓團(tuán)隊(duì)聚焦業(yè)務(wù)功能，而非基礎(chǔ)設(shè)施工具的復(fù)雜性。

基礎(chǔ)設(shè)施“重鋪”

基礎(chǔ)設(shè)施“重鋪（repaving）”是一種高效的實(shí)踐，即在每個迭代周期系統(tǒng)性地重建基礎(chǔ)設(shè)施。自動化的流程會定期清理運(yùn)行中的實(shí)例。這種方式能夠通過消除配置漂移（configuration drift）來增強(qiáng)安全性。當(dāng)存在漂移或需要應(yīng)用補(bǔ)丁（包括零日漏洞修復(fù)）時，所有更新均可系統(tǒng)性地實(shí)現(xiàn)。

長期運(yùn)行會導(dǎo)致資源陳舊、性能下降和安全漏洞。我們可以定期（如每周或每兩周）自動重建環(huán)境，步驟大致如下：先優(yōu)雅地移除流量，再重建環(huán)境并重啟服務(wù)，從而保障運(yùn)維的穩(wěn)定性。

重鋪實(shí)現(xiàn)涉及多個組件：自動化腳本監(jiān)控實(shí)例的生命周期；基于時間的有效性觸發(fā)器會移除路由，阻止新請求進(jìn)入但允許現(xiàn)有請求完成；隨后關(guān)閉實(shí)例、清理節(jié)點(diǎn)并創(chuàng)建新實(shí)例。創(chuàng)建新實(shí)例時，可以使用更新后的鏡像，以解決零日（zero-day）漏洞并添加安全補(bǔ)丁，也可以僅簡單地重建實(shí)例。具體的操作由策略決定。所有流程均自動化完成，在重鋪前會移除流量，確保對客戶不會產(chǎn)生任何影響。

自動化故障轉(zhuǎn)移

具備優(yōu)雅降級能力的自動化故障轉(zhuǎn)移需要考慮活躍的會話。對于正在進(jìn)行處理的客戶，會話的處理方式不同于新的會話，需要進(jìn)行特殊路由。除此之外，必須防止故障轉(zhuǎn)移循環(huán)，如果兩個區(qū)域均不健康，持續(xù)切換只會加劇問題。不同場景對延遲容忍度不同；非關(guān)鍵服務(wù)故障時，可在受影響區(qū)域繼續(xù)運(yùn)行。

可觀測性與自愈能力

可觀測性要求對觀測到的事件進(jìn)行自動化的響應(yīng)。云環(huán)境在各組件中會產(chǎn)生大量事件，比如系統(tǒng)事件、基礎(chǔ)設(shè)施事件和應(yīng)用事件。所有的可觀測事件都需要自動處理。自動化會通過無服務(wù)器函數(shù)與可觀測性進(jìn)行集成，也就是在事件觸發(fā)后，函數(shù)自動執(zhí)行，并且會根據(jù)預(yù)設(shè)的條件切換在哪個區(qū)域執(zhí)行。

數(shù)據(jù)庫問題會觸發(fā)獨(dú)立的數(shù)據(jù)庫切換函數(shù)；維護(hù)活動可以觸發(fā)函數(shù)以屏蔽特定區(qū)域或虛擬私有網(wǎng)絡(luò)（virtual private cloud，VPC）。這些示例場景展示了如何實(shí)現(xiàn)自動化行為，同時確保與可觀測性的集成。儀表盤監(jiān)控能夠提供輔助價(jià)值，但不應(yīng)該作為主要的響應(yīng)機(jī)制。

健康檢查

健康監(jiān)控需要在多個層級進(jìn)行。在應(yīng)用層，健康判斷可能涉及復(fù)雜的評估，不僅要檢查應(yīng)用本身是否正常運(yùn)行，還包括與數(shù)據(jù)庫、緩存及其他系統(tǒng)的連接是否通暢。健康檢查器內(nèi)部可以包含復(fù)雜的邏輯，但返回狀態(tài)必須簡單，僅用布爾值表示健康或不健康狀態(tài)即可。

應(yīng)用內(nèi)的健康檢查要向上傳播至可用區(qū)這一層級，它要檢查所有的實(shí)例。然后，這個信息轉(zhuǎn)移至 VPC 層級，以評估整體 VPC 的健康狀況，最終輸入全局的路由器。每一層級均通過簡單的布爾指標(biāo)實(shí)現(xiàn)自動化健康評估，從而支持快速決策。該方法通過系統(tǒng)性健康檢查以實(shí)現(xiàn)自愈的能力。

決策標(biāo)準(zhǔn)

我們可能會遇到如下的場景，告警指示節(jié)點(diǎn)不可用且容量受損，這可能是供應(yīng)商的問題，流量需要從受影響的 VPC 進(jìn)行重定向；應(yīng)用告警顯示延遲問題且性能受損，組織需要根據(jù)業(yè)務(wù)需求決定是繼續(xù)提供降級服務(wù)，還是滿足服務(wù)等級協(xié)議（service level agreement，SLA）的要求。在這樣的場景中，選擇降級服務(wù)意味著接受較慢的性能，而非切換至可能存在相同問題的其他可用區(qū)。

“灰度故障”（gray failures）指的是故障確定存在但連接仍存在的模糊故障場景。網(wǎng)絡(luò)相關(guān)的故障更難診斷。當(dāng)某項(xiàng)業(yè)務(wù)功能受損時，可以考慮將流量重路由至健康的可用區(qū)?？梢曰诳捎^測性數(shù)據(jù)執(zhí)行多種應(yīng)對措施。

健壯的安全性

安全需要采用零信任模型的分層實(shí)現(xiàn)。每一層必須獨(dú)立運(yùn)作，假定其他層均可能失效。客戶端設(shè)備可能會被惡意軟件攻陷；邊界安全功能需要在邊緣實(shí)現(xiàn)過濾和 Web 應(yīng)用防火墻；內(nèi)部網(wǎng)絡(luò)需要分段和隔離；容器安全方面，需要進(jìn)行鏡像掃描并采用最小權(quán)限原則；應(yīng)用安全方面，需要確保正確地認(rèn)證與授權(quán)；數(shù)據(jù)安全方面，要實(shí)施加密與隱私控制。各層之間要實(shí)現(xiàn)互相強(qiáng)化。

遷 ? ?移

文化轉(zhuǎn)型是成功遷移的基礎(chǔ)，因?yàn)樵七\(yùn)維與傳統(tǒng)的企業(yè)自建系統(tǒng)存在根本性的差異。云服務(wù)商會持續(xù)更新服務(wù)，網(wǎng)絡(luò)策略在不斷演進(jìn)，瀏覽器也在不斷變化，諸多因素都要求我們持續(xù)適應(yīng)。Well-Architected Framework 及相關(guān)原則在這方面提供了指導(dǎo)。

“誰構(gòu)建、誰擁有、誰部署”的所有權(quán)模型將責(zé)任賦予了應(yīng)用團(tuán)隊(duì)。人為錯誤與疏忽不可避免，而自動化可以確保一致性。

測試與驗(yàn)證

測試方法各異。Chaos Monkey 等工具通過向運(yùn)行中的系統(tǒng)注入故障實(shí)現(xiàn)反應(yīng)式測試；失效模式與影響分析（FMEA，F(xiàn)ailure Mode and Effects Analysis）則通過系統(tǒng)性組件評估進(jìn)行預(yù)測性分析，識別潛在的故障并制定緩解策略。這兩種方法均有它的價(jià)值，但 FMEA 更適用于在各應(yīng)用層進(jìn)行全面測試，確保能夠開發(fā)分析與緩解策略。

公司開發(fā)了名為 TrueCD 的 CI/CD 方法論，這是一套包含了十二個步驟的自動化流程，相關(guān)文檔已經(jīng)在官方博客進(jìn)行詳細(xì)闡述。該流程類似于航空業(yè)的飛行前安全檢查。

抽象層

從企業(yè)自建環(huán)境向云遷移會影響應(yīng)用的架構(gòu)。應(yīng)用包含了大量的業(yè)務(wù)邏輯，持續(xù)變更可能對業(yè)務(wù)運(yùn)維產(chǎn)生連鎖影響。抽象層可以最大限度地減少此類影響。該架構(gòu)方法可在單云、多云、自建環(huán)境或混合環(huán)境中靈活選用業(yè)界最佳組件。Dapr 是一個廣受認(rèn)可的開源框架，支持多云架構(gòu)。

遷移客戶流量

大型應(yīng)用的遷移無法一蹴而就。在初期，可以先在內(nèi)部用戶群體中驗(yàn)證系統(tǒng)，使應(yīng)用趨于穩(wěn)定。壓縮時間表往往會適得其反，因?yàn)槟承﹩栴}和使用模式需要長期觀察才能發(fā)現(xiàn)。應(yīng)用需要充足的運(yùn)行時間以完成優(yōu)化。

面對龐大的功能集，在有限時間內(nèi)完成所有功能可能不現(xiàn)實(shí)。將系統(tǒng)拆分為離散應(yīng)用集可以應(yīng)對該挑戰(zhàn)。在遷移的各個階段，可逐步將小比例的客戶群體進(jìn)行遷移，最終再實(shí)現(xiàn)全面遷移。

結(jié) ? ?果

這些策略的實(shí)施帶來了可衡量的成果：顯著降低成本，性能指標(biāo)大幅提升，平臺在對比分析中名列前茅。Dynatrace 的公開報(bào)告對美國銀行網(wǎng)站進(jìn)行了比較，它指出實(shí)現(xiàn)亞秒級（<1 秒）響應(yīng)的站點(diǎn)代表了最優(yōu)的性能。

結(jié) ? ?論

從這些策略中可以提煉出一些關(guān)鍵的考量因素。權(quán)衡是不可避免的，我們需要綜合考慮成本與性能，同時不損害其他的需求。例如，在多區(qū)域架構(gòu)中，需要評估緩存復(fù)制策略：是在單區(qū)域還是多區(qū)域維護(hù)緩存？運(yùn)維的復(fù)雜性隨云架構(gòu)組件的增多而上升。降低復(fù)雜性、減少應(yīng)用監(jiān)控中的人工干預(yù)至關(guān)重要，而自動化是實(shí)現(xiàn)這一目標(biāo)的關(guān)鍵機(jī)制。

控制故障的爆炸半徑始終至關(guān)重要。站點(diǎn)必然會遇到各種問題，組件難免失效。關(guān)鍵在于故障發(fā)生時的影響范圍，是波及所有客戶，還是僅限一小部分？這一關(guān)注點(diǎn)至關(guān)重要。我們必須建立面向行動的可觀測性，并與自動化操作緊密關(guān)聯(lián)起來。

所有決策必須以客戶為中心。業(yè)務(wù)運(yùn)營服務(wù)于客戶。請思考“撥號音體驗(yàn)”：拿起電話，用戶期望立即聽到撥號音。應(yīng)用亦應(yīng)如此，用戶打開移動應(yīng)用，理應(yīng)立即看到結(jié)果。

核心原則：智能擴(kuò)展，保持可靠性。當(dāng)下一次流量激增不可避免地到來時，系統(tǒng)弱點(diǎn)必將暴露出來。這些策略的直接目標(biāo)在于，當(dāng)流量激增時，關(guān)鍵組件必須能夠保持運(yùn)行，核心系統(tǒng)必須維持響應(yīng)能力，客戶必須像往常一樣獲得即時響應(yīng)。