作者｜唐三、望宸，白玙、榆松、十眠、稚柳对本文亦有贡献。

登陆小红书，搜索 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）是连接用户与服务的关键组件。它不仅是流量的入口，也是安全防护的第一道防线。随着全球化业务的扩展，入口网关面临的安全威胁也日益复杂和多样化。如何通过设计和优化入口网关，提升软件架构的安全能力，成为全球化技术架构中的重要课题。面临的挑战有：

• DDoS 攻击：DDoS 攻击会带来大量的恶意流量，淹没入口网关，导致服务不可用。全球化架构的入口网关暴露在公网中，成为攻击者的主要目标。
• API 滥用与爬虫攻击：恶意用户可能通过滥用 API 接口或使用自动化爬虫工具，窃取数据或消耗系统资源，影响正常用户的访问体验。
• 数据泄露与隐私风险：入口网关处理大量用户请求，可能包含敏感信息（如身份凭证、支付信息等）。如果未采取足够的安全措施，可能导致数据泄露和隐私风险。
• 认证与授权漏洞：全球化架构中，用户可能来自不同地区，身份认证和授权机制需要支持多种标准和协议。如果设计不当，可能导致未授权访问或权限提升漏洞。
• 跨站脚本（XSS）与注入攻击：入口网关需要处理用户输入数据，如果未进行严格的输入验证和过滤，可能导致跨站脚本（XSS）或 SQL 注入等攻击。

为了应对上述挑战，可以通过以下策略在入口网关上提升安全能力：

• DDoS 防护
  

• • 流量清洗：通过云安全产品，使用全球分布的流量清洗中心，过滤恶意流量，确保合法流量能够到达入口网关。
    
  • 限流与速率限制：在入口网关上实施速率限制，限制每个用户或 IP 地址的请求频率，防止恶意用户通过高频请求耗尽系统资源。
    

• 弹性扩展：通过云原生 API 网关的自动扩展机制，动态调整入口网关的计算资源，应对突发的流量增长，避免因资源不足导致的服务中断。
  
• API 监控与审计：
  

• • 实时监控：在入口网关上集成实时监控工具，检测异常的 API 调用行为（如高频请求、异常参数等），及时发出警报。
    
  • 日志审计：记录所有 API 调用的日志，定期进行审计分析，发现潜在的安全威胁。
    

• 数据合规性
  

• • 数据本地化：根据用户所在地区的法律法规，将敏感数据存储在当地的数据中心中，避免跨境数据传输带来的合规风险。
    
  • 隐私保护协议：在入口网关上实施隐私保护协议（如 GDPR 的“隐私设计”原则），确保用户数据的合法处理。
    

• API 安全防护：使用云原生 API 网关的安全插件，实现
  

• • 设置黑白名单：通过配置黑名单和白名单，来拒绝或允许特定IP的访问请求，支持在网关全局、域名和路由级别配置IP黑名单和白名单，满足访问控制的精细化需求，确保了更灵活和更安全的访问管理。下方展示了云原生 API 网关在安全防护领域的插件。
    
    

• 细粒度权限控制：在入口网关上实施细粒度的权限控制，确保用户只能访问其权限范围内的资源。云原生 API 网关支持全局认证、路由配置认证和消费者鉴权，实现对 API 访问的控制、安全性保障和策略管理。下方展示了云原生 API 网关在认证鉴权领域的插件。
  

• 全球化是对技术架构的终极挑战，面临的不仅仅是技术的问题，而是包含了经济、文化等多因素差异的用户关系问题。积极借助遍布全球的云计算基础设施和云原生的架构设计原则，将能更加高效的构建高可用的全球化技术架构，支持全球业务的持续增长。

[1] 6 年技术迭代，一文详解阿里全球化出海 & 合规的挑战及探索

https://www.infoq.cn/article/2fbuwxxkr1ekfj0spihw

来源 | 阿里云开发者公众号

作者 | 唐三、望宸