海外潑天流量｜淺談全球化技術架構

阿里妹導讀

本文對海外潑天流量現狀做了快速整理，旨在拋磚引玉，促進國內企業在出海過程中，交流如何構建全球化技術架構的落地經驗，相信會有越來越多資深人士分享更深層次的實踐。

作者｜唐三、望宸，白璵、榆松、十眠、稚柳對本文亦有貢獻。

登陸小紅書，搜尋 refugee，你就能看到一個不一樣的小紅書。隨機點選幾個，讓大資料記住你，就能持續看到一個不一樣的小紅書。

是的，短短48小時，透過小紅書進入了真正的地球村，雖然語言不通，但是圖片就能詮釋一切，相信小紅書的自動翻譯功能會馬上上線。在此之前，所有社交平臺都是獨立站，因為每個國家的法律法規不同、應用商店政策不同、金融支付方式不同，均需要獨立運營，自然使用者也就都是隔離態，全靠相互搬運瞭解對方的社交文化。小紅書看似是目前為數不多支援全球使用者登陸的國內社交平臺，透過本地區手機號即可註冊和登入。

當我們還在關注這潑天流量是否可持續時，出海企業可能已經開始思考應對海外的潑天流量時，需要提前做好哪些準備了？本文對相關材料做了快速整理，旨在拋磚引玉，促進國內企業在出海過程中，交流如何構建全球化技術架構的落地經驗，相信會有越來越多資深人士分享更深層次的實踐。

全球化架構的運營挑戰

全球化不僅僅是市場的擴充套件，它還帶來了運營和技術架構上的巨大挑戰。

嚴格遵守不同國家和地區的法律法規，如資料隱私保護法規、內容審查規定、主流應用商店的稽核指南和開發者政策等，確保應用合法合規運營。
升級內容稽核體系和推薦演算法，因為各國對社交平臺的內容監管要求不盡相同，需要設計支援不同體系的自動化內容稽核工具，以及提供更適合當地使用者的內容推薦演算法。
面向全球的 APP，無論是瀏覽頁還是釋出頁，都需要支援多語言、多時區、多幣種，提供基於大模型實現頁面的自動頁翻譯功能，金融支付遵行當地法規等。

全球化架構的技術挑戰

全球化過程中，技術架構在效能、可用性、安全合規、資料一致性、成本方面存在著諸多挑戰[1] ，包括網路延遲與抖動、跨區域資料一致性、合規性與資料主權、高可用性與容災、成本控制與資源最佳化、安全防護等。

網路延遲與抖動：使用者的地理位置與伺服器之間的距離直接影響服務的響應時間。高延遲會導致使用者體驗下降，尤其是在即時性要求較高的應用場景中（如社交、遊戲、車聯網等）。網路抖動（即延遲的不穩定性）可能導致服務響應時間波動，也會影響使用者體驗。
跨區域資料一致性：在全球化架構中，資料通常需要在多個區域之間進行同步和複製。例如國外使用者在社交社群釋出的內容，國內可以無時差、無遺漏的刷到。但跨區域的資料同步面臨網路延遲、分割槽容忍性和一致性模型的挑戰。
合規性與資料主權：不同國家和地區對資料儲存、傳輸和處理有不同的法律法規要求。資料是否本地儲存、是否可以複製出境、使用者是否需要同意、是否需要向監管機構登記和備案。例如，歐盟的《通用資料保護條例》（GDPR）對個人資料的處理提出了明確的要求。
高可用性和容災：全球化架構需要在多個區域部署服務，確保在一個區域發生故障時，其他區域能夠繼續提供服務。然而，跨區域的高可用性和容災設計面臨網路分割槽、資料同步和故障切換的挑戰。如何在保證高可用性的同時，避免腦裂和資料丟失，是全球化架構設計中的難題。
成本控制和資源最佳化：全球化部署意味著需要在多個區域建設或租用資料中心、購買頻寬和計算資源。基礎設施能力不均、定價不同，如何在保證服務穩定性的前提下，最佳化資源使用、降低成本，是企業持續要投入資源解決的重要問題。
安全防護：全球化架構面臨來自全球範圍的網路攻擊和安全威脅，如 DDoS 攻擊、資料洩露、惡意軟體等。在全球範圍內實施統一的安全策略，確保服務的安全性和穩定性，也是全球化架構設計中的重要挑戰。

雲原生在全球化過程中對業務穩定性帶來的增益作用

線上應用出海，意味著將面臨更多的流量和更多元化的使用者需求，可以看作是線上應用國內網際網路化的升級版。

由於全球化部署架構下，各地基礎設施能力不均、流量波動幅度更大、多區域&多機房&多業務帶來的複雜架構等因素，導致團隊在穩定性上存在著更加嚴峻的挑戰。對此，積極藉助安全合規、遍佈全球的雲計算公司的基礎設施和雲原生的應用構建正規化，來應對上述挑戰是最為高效的應對方式之一。

應對全球化架構的運營和技術挑戰，是一個體系化的工程。以下僅從應用的高可用性和容災維度進行展開，做一些分享。

應用高可用架構設計

應用高可用的架構不是天然就有的，而是基於大量的生產實踐總結出來的。阿里透過編寫“安全生產指南”來分享這些經驗教訓，並進一步從這些經驗中抽象出一套方法論和價值體系，融入到基礎設施和產品中，以避免重複同樣的錯誤，尤其是面向失敗的架構設計（容量、容錯和容災）、變更管理中的三板斧（可灰度、可觀測、可回滾），設定牽引指標以快速響應故障，包括從故障發現到恢復的限時操作，建立應急體系的重要性，確保能在短時間內快速識別並應對故障，減少影響面。最後，透過不斷最佳化架構設計、變更管理和應急響應，形成一個全方位的應用高可用架構（安全生產體系），保障業務穩定執行。

其中，牽引指標的定義考慮了業務特性和使用者影響的可控性，它不是絕對考核指標，而是根據業務不同靈活調整的。透過架構設計原則、變更執行原則和應急處置原則三方面入手，確保安全生產框架的有效實施。此外，容量問題透過全鏈路壓測解決，容錯設計透過混沌工程驗證，容災則針對歷史案例和業務需求進行系統規劃。

容量管控

在容量管控上，在閘道器層統一接入所有流量，再根據既定規則分發至各個業務處理。然而，這種方式效率低下，因為需要各業務系統各自進行改造。為解決這一問題，提出在中介軟體層進行處理，透過在框架中設定檢查點，能夠在流量傳遞時識別並按照規則將其導向正確位置。

此外，強調資料安全的重要性，設定資料層的底線原則為防止資料洩露。透過這樣的多層分解和處理，實現了流量的可控性。我們在2013年實施了全鏈路壓測，能夠在真實高峰流量來臨前模擬實際情況，有效解決容量問題。全鏈路壓測幫助識別系統瓶頸和未達效能指標預期的部分，透過模擬發現不足，從而針對性解決。

容錯設計

在軟體研發過程中，即使設計理想且細緻，線上執行時仍會遇到未曾預料的問題。開發團隊經常遇到的一個問題是，某些情況下設計難以驗證，導致問題上線後才被發現。線上故障的出現往往是因為一些特定場景觸發了預設計時未考慮到的問題。故障修復後，由於缺乏有效的驗證手段，上線後仍可能存在問題。引入混沌工程，目的是在上線前對系統的容錯設計進行全面驗證，確保即使出現故障也能透過模擬手段驗證修復的有效性。

對於大部分企業，我們推薦更加原生、更加經濟的方式，例如透過雲產品的面向失敗的邏輯，像 MSE Nacos 的推空保護，雲原生 API 閘道器的過載保護、異常自動重啟都提升了系統的容錯能力。

容災架構

容災體系歷史悠久，對計算機領域尤其重要。資料中心層面，業務系統通常採用叢集級別容災，避免單點故障影響服務。企業業務出海，業務架構變得更加複雜，使得容災成為一個相對複雜的話題。我們透過將業務拆分並實現多活業務架構，提高應對資料中心級別故障的能力，確保業務的連續性。這裡列舉一些設計時的關鍵點。

流量管控，確保使用者行為可擴充套件至全球各國站點，透過技術架構圍繞流量進行管控，實現從使用者點選流量到平臺各環節的完全可控。
技術拆分，從入口流量的閘道器開始，覆蓋中介軟體（包括同步和非同步，RPC 和訊息）以及資料層，目的在於精確分發流量到正確位置。
發現問題，包括流量切分的不可控性和緊急安全漏洞時難以集中修復，導致需要統一管控流量，透過建立統一的閘道器層來管理所有流量的進入和分發。

中介軟體層的處理，在於能夠在流量傳遞時識別其位置，並按照規則將流量導向正確的地方，確保了效率和複用性。
資料層，考慮到資料安全底線原則，即使路由出現問題，也會直接去掉有問題的流量，確保資料不洩露，同時透過 CDN 和閘道器層即時計算和驗證流量，確保請求的準確性和安全性。

這裡我們分享透過來透過一個 MSE 雲原生閘道器例項同時關聯多個叢集，將同名服務合併，在多個服務端點之間做負載均衡。搭配閘道器的健康檢測功能，自動探測服務可用性，實現更高效的故障自動切流。

可灰度

使用者留存的關鍵是產品體驗，好的產品體驗是基於使用者需求持續打磨的結果。因此，提升發版頻率就成了保障體驗的關鍵。透過全鏈路灰度釋出，來建立灰度環境，控制應用釋出時出現問題的爆炸半徑，以小流量來驗證發版質量，逐步覆蓋到全部業務節點；加強無損上下線能力，降低應用釋出時的流量損失，在加大了軟體的釋出頻次，提升對業務的響應訴求的同時，降低發版引發的線上故障。

全鏈路灰度存在以下三類核心挑戰：

流量控制：如何精準地將部分流量引導到新版本服務。
鏈路一致性：如何確保灰度流量在整個呼叫鏈路上保持一致，避免新舊版本服務之間的混用。
監控與回滾：如何即時監控灰度釋出的效果，並在發現問題時快速回滾。

業內有三類實現方式，一是自研 Agent 技術，但門檻較高；二是基於 istio 來進行流量控制；三是藉助雲產品，例如 MSE 的微服務治理能力，透過 One Java Agent 方式實現業務的灰度釋出。

透過線上機器進行軟隔離，解決了物理成本高的問題，無需重新搭建環境或協調上下游團隊，降低協同成本。
利用流量隔離的方法建立新的通道，可以快速地將灰度業務隔離出來，提高灰度驗證的效率。
回滾機制作為預案，確保在灰度釋出出現問題時能夠迅速恢復，保障服務的穩定性和可靠性。

以上是 RPC 層的全鏈路灰度，當鏈路請求中存在訊息的時候，實現方式更加複雜。如果透過 One Java Agent 方式，實現流程如下發圖片。

訊息生產者掛載上 Java Agent 之後，agent 會自動修改傳送訊息的邏輯。如果識別到訊息屬於灰度流量，會自動將訊息加上灰度標，傳送到訊息服務端。訊息消費者在啟動過程中識別到灰度環境，會自動透過 Java Agent 修改 consumer group ，而且傳送訂閱規則時會自動訂閱只消費灰度的訊息。訊息的服務端會對過濾的規則進行識別和匹配，以保證只有灰度訊息會推送給灰度消費者。

可觀測

在流量激增的業務場景中，可觀測平臺扮演著至關重要的角色，為企業提供即時的應用服務健康監測、效能分析和故障診斷能力，實現對應用服務內部狀態的全面視覺化。藉助 SLS+CMS+ARMS 的端到端的可觀測能力，企業能夠快速識別潛在的效能瓶頸和故障點，研發運維團隊可以更好地理解流量模式、資源使用情況對整體系統健康的影響。構建原則包括：

實現可觀測性首先是統一所有觀測指標，形成三大支柱的統一檢視。
在實施可觀測性時，採取自上而下的方法，從最關心的業務指標開始，逐步細化到可即時發現故障的層面，確保既及時發現又避免過度敏感產生的誤報。
隨著業務的發展，意識到將可觀測性統一到一個平臺的重要性，以避免團隊之間水平不一和故障發現時間不可控的問題。
不統一可觀測性會導致一些問題無法及時被發現，如依賴關係中的問題，延長了故障排查和定位的時間。
可觀測性還涉及應急響應，透過大中小三屏系統來及時處理發現的問題。

提升軟體架構的安全能力

在全球化技術架構中，入口閘道器（API Gateway）是連線使用者與服務的關鍵元件。它不僅是流量的入口，也是安全防護的第一道防線。隨著全球化業務的擴充套件，入口閘道器面臨的安全威脅也日益複雜和多樣化。如何透過設計和最佳化入口閘道器，提升軟體架構的安全能力，成為全球化技術架構中的重要課題。面臨的挑戰有：