作者：唐三、望宸，白玙、榆松、十眠、稚柳对本文亦有贡献。
登陆小红书，搜索 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 ，而且发送订阅规则时会自动订阅只消费灰度的消息。消息的服务端会对过滤的规则进行识别和匹配，以保证只有灰度消息会推送给灰度消费者。[2]
可观测
若尚未建立完善的可观测平台，遇到流量激增，容易产生数据采集性能不足带来的延迟或数据丢失，以及其他观测盲区，这些都会进一步导致下游依赖出错，例如基于监控指标的扩容慢，线上故障定位慢，网络优化不及时的情况。接下来，我们以可观测中文社区 https://observability.cn/ 举例，看看如何快速构建全球网络服务监控体系。
可观测中文社区的访问用户来自中国、新加坡、美国等不同国家、不同地域，因此网站运维团队，在日常维护过程中非常关注几个核心问题：
- 服务器宕机：服务器无法响应请求，导致网站无法访问，影响用户体验。
- 网络延迟：网络响应时间过长，导致页面加载缓慢，用户流失。
- DNS 解析问题：DNS 配置错误或更新延迟，导致用户无法找到网站。
- 依赖服务异常：网站依赖的第三方服务（如 API、数据库等）出现故障，影响网站的正常功能。
- SSL 证书问题：SSL 证书过期或配置错误，导致安全警告，影响用户信任度。
但由于人力投入限制，无法直接对网络日志进行体系化的监控与分析。为了能够更高效地构建网络质量监控，因此使用网络监控与分析能力。实践流程如下：
1）配置基础探测参数
登录云监控控制台，选择网络分析与监控的站点监控。在监控任务页签，单击创建任务。由于运维团队希望监控网站的可用性和性能，确保网站能够正常访问和响应。因此，我们在这里选择 PC 端的探测点，同时使用 HTTP(S) 的任务类型。在配置监测地址的同时，可以选择不同的 HTTP 请求方法，包括 GET、HEAD 和 POST。
![]()
HEAD 方法用于请求资源的头部信息，而不返回资源本身的内容。这意味着服务器会响应请求，但不会发送实际的数据体，只发送 HTTP 头部信息。POST 方法用于向指定资源提交数据，请求服务器进行处理（如提交表单或上传文件）。服务器处理完请求后会返回一个响应。GET 方法用于请求指定的资源，通常用于获取信息。请求参数附在 URL 中，作为查询字符串的一部分。
我们可以根据实际监控需求选择合适的 HTTP 请求方法。如果只需要检查资源的存在性和状态，建议使用 HEAD 方法；如果需要提交数据并获取响应，应使用 POST 方法。
2）选择所需的地域探测节点
结合自身业务以及目标用户所在区域选择不同的探测点，探测节点我们可以选择相应国家以及相关地域的探测点。
在探测点的使用过程中，我们会遇到一个问题，就是如何选择 IDC 探测点与 Last mile 探测点。IDC 探测点主要是部署在互联网数据中心的监控节点，这些探测点通常位于高速、高可用的数据中心网络环境中，能够帮助企业检测网络链路的性能和稳定性，适用于监控企业和数据中心之间的网络链路状况，以及对网络性能有较高要求的业务场景。Last Mile 探测点是部署在接近终端用户的网络环境中的监控节点这些监测点可以更好地模拟实际用户在访问业务时的网络体验，反映出用户在不同地理位置、网络环境和运营商网络下的实际访问情况。适用于监控终端用户的网络体验，帮助企业优化网络服务，提高用户满意度。我们可以根据实际监控需求选择探测点类型。
![]()
3）配置告警事件
网络监控与分析的核心关键，就是先于用户发现问题，因此配置告警至关重要。我们可以选择几个核心指标，比如可用探测点百分比、不可用探测点数量、错误码、响应时间，来配置告警。并根据自身业务特征来设定相关阈值。比如连续三个周期，可用探测点比例小于 90%，就进行电话+短信+邮件+WebHook 告警。
此外，除了自身的告警机制，我们还可以将告警事件与其他云产品进行组合使用。比如：我们可以配置相关的弹性伸缩规则，当报警发生时，会触发提前配置好的弹性伸缩的地域、弹性伸缩组和弹性伸缩规则。配置相应的日志服务，当报警发生时，会将报警信息发送至日志服务的日志库。甚至配置函数计算，当报警发生时，会将报警通知发送至函数计算进行格式处理。帮助我们更高效、更智能化的记录、处理告警以及进行相应运维动作。
![]()
4）查看监控大盘
在任务启动后，我们就可以等待探测点返回的数据。因为整个调用流程涉及到多个环节以及计时方式。
![]()
同时，网络监控与分析提供了默认大盘供开发者使用，可以从如地域、运营商等不同维度，更直观、高效的观看相关指标的趋势。比如全球可用性和响应延时大盘、全球地域探测大盘。
![]()
全球可用性和响应延时大盘分析
![]()
全球地域探测分析
5）详情分析
在查看大盘或者收到告警时，我们可能会发现某单次探测结果报错或者存在问题，我们可以通过详情分析进行进一步了解。与此同时，可能会有一些报错码。因为我们配置的是 HTTP(S) 任务，因此这里我们简单罗列了一下常见错误码，以便大家更高效的知晓业务问题在哪里。
![]()
提升软件架构的安全能力
在全球化技术架构中，入口网关（API Gateway）是连接用户与服务的关键组件。它不仅是流量的入口，也是安全防护的第一道防线。随着全球化业务的扩展，入口网关面临的安全威胁也日益复杂和多样化。如何通过设计和优化入口网关，提升软件架构的安全能力，成为全球化技术架构中的重要课题。面临的挑战有：
- DDoS 攻击：DDoS 攻击会带来大量的恶意流量，淹没入口网关，导致服务不可用。全球化架构的入口网关暴露在公网中，成为攻击者的主要目标。
- API 滥用与爬虫攻击：恶意用户可能通过滥用 API 接口或使用自动化爬虫工具，窃取数据或消耗系统资源，影响正常用户的访问体验。
- 数据泄露与隐私风险：入口网关处理大量用户请求，可能包含敏感信息（如身份凭证、支付信息等）。如果未采取足够的安全措施，可能导致数据泄露和隐私风险。
- 认证与授权漏洞：全球化架构中，用户可能来自不同地区，身份认证和授权机制需要支持多种标准和协议。如果设计不当，可能导致未授权访问或权限提升漏洞。
- 跨站脚本（XSS）与注入攻击：入口网关需要处理用户输入数据，如果未进行严格的输入验证和过滤，可能导致跨站脚本（XSS）或 SQL 注入等攻击。
为了应对上述挑战，可以通过以下策略在入口网关上提升安全能力：
![]()
- 细粒度权限控制：在入口网关上实施细粒度的权限控制，确保用户只能访问其权限范围内的资源。云原生 API 网关支持全局认证、路由配置认证和消费者鉴权，实现对 API 访问的控制、安全性保障和策略管理。下方展示了云原生 API 网关在认证鉴权领域的插件。
![]()
全球化是对技术架构的终极挑战，面临的不仅仅是技术的问题，而是包含了经济、文化等多因素差异的用户关系问题。积极借助遍布全球的云计算基础设施和云原生的架构设计原则，将能更加高效的构建高可用的全球化技术架构，支持全球业务的持续增长。
相关链接：
[1] 6 年技术迭代，一文详解阿里全球化出海 & 合规的挑战及探索
https://www.infoq.cn/article/2fbuwxxkr1ekfj0spihw
[2] 《RocketMQ 全链路灰度探索与实践》
