大規模云和分布式應用：摩根大通的教訓與策略：摩根大通的教訓與策略

作者 | Durai Arasan

譯者 | 張衛濱

本文分享了擴展云和分布式應用程序的目標與策略，重點介紹了摩根大通（JPMorgan Chase）旗下 Chase.com 在云遷移過程中汲取的經驗教訓。

討論圍繞三個核心目標展開，詳細闡述了實現這些目標的具體策略，最后說明了這些方法在實踐中的落地方式。對于管理大規模系統的從業者而言，這些經驗源自我們在摩根大通及其他金融機構多年來的實戰積累，具有寶貴的指導意義。

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

安全控制措施可以阻止惡意流量，但當市場波動引發真實客戶需求激增時，情況則有所不同。客戶恰恰會在這些情況下需要訪問金融交易服務。在系統壓力下，多個組件可能同時發生故障；網絡設備、負載均衡器、應用程序和數據庫連接都可能同時中斷。

目 標

我們的云遷移聚焦于三大核心目標：以成本效益高且高效的方式實現彈性擴展、實現高韌性（這對金融機構尤為重要），以及提供卓越性能，防止因系統遲緩而迫使用戶轉向其他服務。

高效擴展

實現高效性需要分析客戶的使用模式和行為。組織必須在保持彈性擴展能力的同時，發展預測能力。

流量整形（Traffic shaping）提供了一種識別高頻率功能的方法論，從而能夠有針對性地對關鍵應用進行擴展。

整體容量管理是另一個關鍵要素。簡單地增加服務器并不能保證成功，還需要仔細權衡成本的因素。

流量模式與容量規劃

流量模式是高效擴展的基礎。平均流量代表了系統日常處理的基準水平。可預測的模式確實存在，例如，工資入賬等周期性事件會促使客戶查詢賬戶余額。全年還會出現季節性高峰，這要求提前規劃。

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

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

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

成本管理需要進行持續關注。應該定期（如每月或每周）應用 FinOps 流程，而非偶爾為之。

超越單純增加服務器的擴展

擴展不應該局限于簡單地增加服務器。當發生擴展時，有一個根本性的問題，那就是，應用程序是否真的因為真實客戶的需求而需要擴展，還是因為上游服務排隊導致響應變慢？當線程等待響應而無法執行時，CPU 和內存的壓力會上升，即使實際需求并未增長，也會觸發彈性擴展。

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

高韌性

韌性（Resiliency）要求為不可避免的系統故障做好準備。早期檢測和隨時執行故障轉移程序至關重要。然而，為所有組件實現 100% 的可用性既不現實，也無必要。

基礎設施可根據關鍵性分為四個層級。關鍵（Critical）類的組件必須盡可能接近 100% 可用。DNS 就屬此類，無論網站架構多么完善，DNS 如果出現故障將會導致所有訪問中斷。

可管理（Manageable）層的組件在發生故障時可通過故障轉移維持運行，目標為“四個九”的可用性（99.99%，即每年可接受約 52 分鐘的停機時間）。

可容忍（Tolerable）層的組件具備內置韌性。例如，緩存長期數據的令牌服務，若服務在緩存有效期內不可用，系統仍可使用已緩存的數據繼續運行。

最后，可接受（Acceptable）層的組件允許有限的數據丟失，比如，某些日志系統。韌性目標由影響的嚴重程度決定。

性能

性能會顯著影響用戶體驗和基礎設施成本，但并非所有應用程序的表現完全相同。通過部署接入點（Point of Presence, PoP）可以提升用戶體驗，因為它對網站延遲（尤其在移動設備上）尤為敏感。

速度至關重要，因為它能建立用戶信任，用戶期望更快、更好的體驗。谷歌等搜索引擎已經認識到這一點，并將速度納入其排名算法。在網絡連接受限的場景下，移動端性能尤為關鍵。從基礎設施角度看，客戶完成相同任務所花費的時間越少，運營成本就越低。

我們通過實施全面的性能策略，從初始部署到完整架構落地，系統延遲降低了 71%。這些策略可適配其他業務場景。

五大核心策略

架構方法圍繞五個重點領域展開：多區域部署、高性能優化、全面自動化、具備自愈能力的可觀測性，以及強大的安全性。

多區域部署

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

實現多區域架構需要解決 DNS 管理的問題，因為不同區域擁有獨立的負載均衡器，需要協調一致。還需要確定區域間流量的調度策略。在包含多個可用區的區域內，也需選擇流量的分配方式。

可用區故障

假設一個負載均衡器將流量分發至同一區域內的兩個可用區。兩個應用均報告健康狀態，可用區看似正常，流量持續流入。然而，如果其中一個可用區的應用與后端系統連接異常，而另一可用區正常，流量仍將流入受損的可用區。若應用雖實現了就緒（readiness）和存活（liveness）探針，卻未將依賴系統狀態納入健康檢查，那么就有可能出現問題。缺乏適當的反饋機制時，負載均衡器會繼續路由流量，導致應用失敗。

針對這種情況，解決方案包括將依賴系統的健康狀態通過就緒或存活探針反饋給負載均衡器，或采用基于代理的重路由機制將流量導向正常的可用區。這需要有效管理內外部故障，以應對應用停機。

區域性的故障

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

多區域的挑戰

跨區域的數據復制與確保數據一致性是主要的關注點。當數據中心位置有限而客戶遍布全國時，客戶分片（customer sharding）是一種可行的方案：將客戶按地理位置分片，并由就近的數據中心提供服務，這樣可以減少復制的需求，并簡化架構。

狀態管理需要戰略性的決策。為活躍會話維護會話親和性（session affinity），并在必要時支持故障轉移，這有助于高效運行。

高性能

高性能對用戶體驗至關重要。良好的性能如同可靠的撥號音，用戶期望即時響應，不容延遲。邊緣計算是實現性能目標的主要手段。現代網站具有復雜的用戶界面，內容密集。我們可將靜態內容卸載至靠近客戶的入網點（Point of Presence，PoP），而源服務器（origin server）僅處理動態操作和關鍵服務，如登錄、賬戶、支付等。

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

內容分發

地理分布會顯著影響性能。如果每次資源請求都需要跨越很長的距離，物理網絡的屏障將會造成顯著的延遲。如果相同的內容已在 PoP 緩存，檢索可在 100 毫秒內完成，遠優于訪問源站所需的較長響應時間（比如，大于 500 毫秒）。性能提升的同時會帶來安全方面的收益，因為惡意的流量可以在邊緣被攔截。

“最后一公里連接（last-mile connectivity）”的問題值得關注。互聯網通信涉及多個網絡跳轉。邊緣計算改變了這一模式，從用戶到邊緣節點通常只需要一跳，再結合優化的網絡傳輸，這樣所帶來的效率遠高于標準的 ISP-to-ISP 連接。

移動應用也有優化的空間。移動設備具備本地存儲，可用于緩存網絡解析結果、配置設置和預抓取的內容。

自動化

自動化是關鍵的戰略元素。在整個流水線的各個階段實施全面自動化可帶來巨大收益，這需要涵蓋部署、基礎設施供應、環境配置、集成自動化操作的健康檢查，以及整體的流量管理。

架構不能止步于文檔。通過創建“帶有傾向性的（opinionated）”架構模板，可以幫助團隊構建自動繼承架構標準的應用。應用通過基于清單（manifest）定義進行自動化部署，這樣能夠讓團隊聚焦業務功能，而非基礎設施工具的復雜性。

基礎設施“重鋪”

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

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

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

自動化故障轉移

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

可觀測性與自愈能力

可觀測性要求對觀測到的事件進行自動化的響應。云環境在各組件中會產生大量事件，比如系統事件、基礎設施事件和應用事件。所有的可觀測事件都需要自動處理。自動化會通過無服務器函數與可觀測性進行集成，也就是在事件觸發后，函數自動執行，并且會根據預設的條件切換在哪個區域執行。

數據庫問題會觸發獨立的數據庫切換函數；維護活動可以觸發函數以屏蔽特定區域或虛擬私有網絡（virtual private cloud，VPC）。這些示例場景展示了如何實現自動化行為，同時確保與可觀測性的集成。儀表盤監控能夠提供輔助價值，但不應該作為主要的響應機制。

健康檢查

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

應用內的健康檢查要向上傳播至可用區這一層級，它要檢查所有的實例。然后，這個信息轉移至 VPC 層級，以評估整體 VPC 的健康狀況，最終輸入全局的路由器。每一層級均通過簡單的布爾指標實現自動化健康評估，從而支持快速決策。該方法通過系統性健康檢查以實現自愈的能力。

決策標準

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

“灰度故障”（gray failures）指的是故障確定存在但連接仍存在的模糊故障場景。網絡相關的故障更難診斷。當某項業務功能受損時，可以考慮將流量重路由至健康的可用區。可以基于可觀測性數據執行多種應對措施。

健壯的安全性

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

遷 移

文化轉型是成功遷移的基礎，因為云運維與傳統的企業自建系統存在根本性的差異。云服務商會持續更新服務，網絡策略在不斷演進，瀏覽器也在不斷變化，諸多因素都要求我們持續適應。Well-Architected Framework 及相關原則在這方面提供了指導。

“誰構建、誰擁有、誰部署”的所有權模型將責任賦予了應用團隊。人為錯誤與疏忽不可避免，而自動化可以確保一致性。

測試與驗證

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

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

抽象層

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

遷移客戶流量

大型應用的遷移無法一蹴而就。在初期，可以先在內部用戶群體中驗證系統，使應用趨于穩定。壓縮時間表往往會適得其反，因為某些問題和使用模式需要長期觀察才能發現。應用需要充足的運行時間以完成優化。

面對龐大的功能集，在有限時間內完成所有功能可能不現實。將系統拆分為離散應用集可以應對該挑戰。在遷移的各個階段，可逐步將小比例的客戶群體進行遷移，最終再實現全面遷移。

結 果

這些策略的實施帶來了可衡量的成果：顯著降低成本，性能指標大幅提升，平臺在對比分析中名列前茅。Dynatrace 的公開報告對美國銀行網站進行了比較，它指出實現亞秒級（<1 秒）響應的站點代表了最優的性能。

結 論

從這些策略中可以提煉出一些關鍵的考量因素。權衡是不可避免的，我們需要綜合考慮成本與性能，同時不損害其他的需求。例如，在多區域架構中，需要評估緩存復制策略：是在單區域還是多區域維護緩存？運維的復雜性隨云架構組件的增多而上升。降低復雜性、減少應用監控中的人工干預至關重要，而自動化是實現這一目標的關鍵機制。

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

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

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

Scaling Cloud and Distributed Applications: Lessons and Strategies（(https://www.infoq.com/articles/scaling-cloud-distributed-applications/)）

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。