作者：vivo互联网服务器团队- Zhang Mengtao
随着经济全球化的趋势，业务逐渐覆盖海外更多国家和地区，如何快速的将内销业务复用到外销环境，是业务走向国际化的必经之路，同时在内销服务和外销服务共存的场景下，做好内外销业务的稳定迭代和快速拓展是走向全球化的必要前提，对于中台业务，项目进行全球共线有着非常重大的意义，能够有效提升组件复用率，并降低服务维护成本，本文将详细介绍 vivo 活动系统的全球化实践过程。

1 分钟看图掌握核心观点👇

图 1 VS 图 2，您更倾向于哪张图来辅助理解全文呢？

一、背景介绍

活动系统做的是一个可视化、插件化、一站式的综合运营系统，一句话描述就是：通过简单的拖、拉、拽配置操作快速搭建活动，大家可以通过下面这个动图看到活动的配置过程，非常便捷。

目前已经沉淀了图片、文本、抽奖、签到等非常多的玩法，同时也沉淀了通用的玩法中心、任务中心、奖品中心等等，其实活动系统的初衷就是为了同样的活动大家都可以快速的复用，不需要每次都定制，覆盖的业务范围遍布于大家的身边，抽奖、签到、关注公众号、关注企微、加入社群、分享等等。随着经济全球化的趋势影响，许多中国品牌纷纷开始在海外市场开疆扩土，各行业纷纷布局海外，vivo 活动系统业务也逐渐覆盖了海外更多国家和地区，包括泰国、新加坡、印尼等越来越多的国家。

二、国际化

在活动系统布局海外的过程中，会遇到各种各样的问题，主要有以下几个方面：

• 用户展示：从活动页面来看，我们需要解决不同地区的语言问题，同时由于世界各地存在不同的时区，服务也需要解决多时区的展示。
• 业务隔离：对于活动平台而言，随着业务拓展到更多的地区，平台业务方也越来越多，对于不同业务方的管理台权限隔离和管控需要进一步考虑；
• 数据存储：除此之外，国外很多地区都会有不同的数据管理规范，数据的分库分表和加密存储同样需要重点关注。

2.1 多语言

多语言是全球化过程中不可避免的问题，以下图为例，抽奖活动投放在不同国家需要展示中文、英文、泰文等多种语言。

传统的多语言方案比较简单，针对不同语言的配置文件，在活动上线前准备好并上传，管理员负责去维护 i18n 资源文件，用户侧需要使用多语言展示时直接获取，这样做的方案虽然简单，但是有两个明显的缺点：

• 维护繁琐，需要运营、开发、测试多种角色
• 翻译文件变更繁琐，变更需要发版上线

活动系统在传统多语言方案的基础上进行了升级，如下图所示，升级方案有几点优势：

• 集成了多语言系统，管理员的维护是在多语言平台进行的，操作便捷， 维护简单；
• 维护的数据一方面在数据库进行持久化，同时会维护在配置中心，性能更优，用户体验更好；
• 同时这样做可以沉淀通用的 SDK，支持其他服务快速接入，将配置做到平台化；
• 在线上环境变更也比较灵活，只需要直接在平台操作就可以。

2.2 多时区

解决完多语言的问题下面来看多时区的问题，针对不同时区时间不同，活动系统需要处理时间相关的展示，这种情况可以采用最简单的方案，运营配置时间即存储时间，用户侧展示的时候同一转换为当地时区，这是最直接的方案，但是存在以下几个缺点：

• 运营如果配置异地活动，需要自行转换时间再配置，增加了运营理解成本
• 同样的编码逻辑和同一个数据库会存在不同的时区，增加了开发的理解成本

（1）为了解决运营理解问题，可以将配置侧的时间直接转化为对应活动投放的地区时间，举例：活动准备投放在泰国，那么运营配置活动时，无论运营当前所处地区在任何国家，配置侧展示的活动时间都是泰国时区，这样可以有效减少运营理解成本，可能需要关注的是，配置时间可能会与电脑系统时间不符，这里一般建议在管理台同时展示下对应国家的时间。

（2）为了解决开发理解问题，活动系统采用了优化后的多时区方案，无论是哪个国家、哪个时区，都统一转换为东八区时间作业务处理并存储，用户侧展示再统一按照当地时区转换。

在多时区的处理过程中，活动系统始终坚持一个原则：用户时区≠存储时区。以下图为例，国家 A 与国内时差为一小时，A 国时区为东七区，转换为东八区为九点，存储就是九点，页面展示查询时间再按照时差进行转换，A 国用户看到的仍然是正确的八点。这样做的好处可以减少运营理解成本，运营要配置泰国的活动，时间就是泰国的时间，开发层面关注的都是转换过后的东八区时间。

多时区模块还需要注意一个问题，对于一个国家有多个时区的场景，目前活动系统取默认时区作为标准，统一作单时区处理，并作活动说明。

2.3 多租户

2.3.1 权限管控

我们的多租户架构并非简单的“单一维度”隔离，而是采用了 “项目-国家”二维矩阵。这就像一个全球坐标，每个数据实体和用户访问都必须同时满足这两个维度的定位，才能被准确定位和授权。每个项目代表一个独立的业务实体、客户或内部业务线。数据、配置、用户、流程均以项目为最高级别容器进行隔离。相当于为每个租户建立了一座 “独立的虚拟大楼”。大楼之间地基、结构完全分离。这样管控有以下优势：

• 业务灵活性：敏捷扩展，新项目上线，只需复制一套“项目容器”；项目进入新国家，只需在该项目下激活并配置新的“国家分区”。互不干扰，快速部署。
• 管理精细化：权责清晰。 权限与数据视图精确匹配组织架构。区域经理只能管理本区域国家的业务，超管可纵览全局。
• 运营与成本：透明可控。 成本、性能、使用情况均可下钻分析，便于问题定位、资源优化和精准投入。

这确保了每个客户（项目）的数据获得最高级别的私密隔离，同时又能灵活地满足其在全球任何一个国家运营时，必须遵循的本地化合规要求。这套体系不仅是活动系统的技术底座，更是支撑活动系统业务安全、合规、高效全球化扩展的战略资产。

2.3.2 多机房部署

活动系统在内销的业务方都是在国内投放活动，随着海外地区不断地业务扩展，逐渐上线越来越多的国家和地区，对接的业务方也越多越多，遍布在不同的国家，如果都请求到某一个机房，那么请求的时延较高，导致用户体验会很差，页面加载速度非常受影响，针对海外地区业务方距离分散问题，活动系统采用多机房部署，对不同地区圈选机房范围，进行分机房部署并访问。全球业务采用多机房（多区域）部署是现代云原生架构的核心战略，其优势远不止于“灾备”，而是一套系统级竞争力。主要有以下 优势：

• 低延迟：不同地区的用户请求会通过 ng 通用规则进行转发，保证请求效率更好，实践得出多机房部署和请求方案可以有效减少请求时间 50%+。物理定律决定体验： 光速有限，数据在光纤中传输每 1000 公里会产生约 5 毫秒的延迟。将服务部署在用户所在区域，可大幅减少网络往返时间。
• 提升吞吐量与带宽效率：流量就近接入，避免了全球长途骨干网的拥堵，提升了整体网络吞吐能力，并节省了昂贵的跨境带宽成本。
• 合规：法律法规强制要求：如欧盟的 GDPR、中国的《网络安全法》、《数据安全法》等，要求特定国家/地区公民的数据必须存储和处理在该司法辖区内。
• 成本：云服务定价差异化： 不同区域的云计算资源（计算、存储）价格不同。通过智能调度，可将非实时计算任务分配到成本更低的区域执行。
• 增强业务敏捷性与市场拓展能力：计划进入一个新地区时，可提前在该区域部署一套最小化环境，快速进行本地化测试和合规准备，加速上线时间。新功能可先在某一个地理区域的机房发布，验证稳定性和用户反馈，再逐步推向全球，降低全盘风险。

从下图可以看出，用户请求会根据 ng 进行统一转发，保证转发到就近机房，有效节省资源并提升用户体验。

2.4 数据存储

由于不同业务方的用户数据量非常大，这里对于数据存储会进行租户隔离，保证数据可用性，采用数据隔离有以下几点 好处：

• 数据安全：与现有悟空存储隔离，进行单独数据库权限管控，提搞数据安全；
• 服务稳定：数据存储物理隔离后，当单一数据库异常不影响其他数据库，提高服务稳定性；
• 可靠：对一数据库的操作，不影响其他库，避免误删，串数据等问题。

同时针对隔离区数据规范，活动系统会针对敏感数据进行定级，同时针对高等级数据进行统一代理加解密，保证数据安全性。

三、全球共线

3.1 为什么要做全球共线？

随着活动系统海外业务逐渐稳定，外销项目的维护和迭代也需要耗费不少的人力，虽然业务类似，但是内销和外销是作为两个项目单独维护，那是否能够将业务作全球共线一起维护呢？下面以两个场景为例：

场景一：内销上线了一个抽奖活动，新加坡也想做一个？

内销上线了一个抽奖活动，先投放在内销地区，上线后发现活动运营情况很好，也深受用户喜爱。所以外销地区也想复用这个抽奖活动，但是内外销作为多个服务在维护，外销服务相对独立，那么就需要参照内销已有的业务再次开发组件，不仅耗费人力，活动复用性也会很差，同时这样的场景往往具有时效性，其他地区急于复用推广，但是同样的活动却需要重复的开发，由此产生全球共线的想法。

场景二：同一个活动类型在不同地区分别长时间维护？

如果同样的抽奖活动在不同地区分别上线后，后续会分别迭代，那么会出现差异化越来越明显的问题，可能随着人员更替变得难以维护，例如同样的抽奖活动分别迭代后可能会出现以下场景：

• 国家 A 新增了特殊规则
• 国家 B 新增了奖品类型
• 国家 C 优化了接口性能
• 国家 D 新增了数据看板

虽然一开始的抽奖活动都是基本一致的，但是随着不同地区不同版本的迭代，活动的玩法逐渐多变，规则也不统一，项目人员维护起来的难度逐渐增大，如果出现人员更替，可能需要耗费很多的精力去分析和回顾，如果做到了全球共线，这些问题都会被解决。

3.2 全球共线要解决哪些问题？

先来看下共线的目标，只有一个:一套代码，统一架构，全球部署。

要做到用一套代码部署在全球各个国家和地区，去投放我们的活动，整体的架构方案可以参照下图：

从图中可以看出，无论是哪个国家哪个地区的请求，都会统一请求共线后的全球服务，经过统一的多语言和多时区转换，走通用转发请求外部相关依赖，数据存储方面也会统一处理，从活动系统角度来看，需要解决以下两个主要问题：

3.2.1 请求域名如何统一？

如果对于不同机房都采用不同的域名进行请求，那么多域名分发方案跨区域访问维护繁琐，新增地区需要新增域名适配，增加成本。所以活动系统在共线过程中采用统一域名处理。目前的业务可以通过域名拼接地区码或者 Header 头携带地区码解决，两种方案都可以解决多地区统一域名转发问题，考虑到活动系统依赖地区码、语言码、时区作通用处理，所以采用 Header 头携带地区码方案。

X-I18n-Code : loc = ${地区码}; lan = ${语言码}; tz = ${时区}

在 header 中新增请求头，加入地区码、语言码、时区，请求过程中添加上下文，便于逻辑处理。在请求转发层面，就可以根据请求头的国家码直接配置转发规则，转发到对应的机房并请求，不仅解决了域名不断增加的问题，还有效保证全球共线一套服务的基础上，请求也能统一转发处理。

3.2.2 地区资源差异如何解决？

由于活动系统外部依赖在不同地区的情况不同，会出现以下三种场景：

场景一：依赖的服务已经完成全球共线，也就意味着对应依赖的服务全球只有一套，无论哪个机房都能够支持业务调用，这是最好的场景，因为不需要任何的额外处理，活动系统可以直接用同样的调用逻辑调用外部服务。

场景二：依赖的服务在对应地区未上线，这种情况需要考虑多种因素，若业务非常紧急，依赖侧来不及开发版本上线支持，可以作临时转发规则到可用机房进行处理，非紧急情况不建议；如果是非必要上线功能涉及，可以临时减少功能调用，保证活动主体正常上线，业务侧兼容外部能力的缺失，同时可以推送外部服务上线，这里要注意的是，若依赖侧未上线，可以推动依赖侧进行共线，至少保证功能一致，比如接口定义等，这样可以有效减少活动系统的兼容成本，也是共线过程中的重要思路。

场景三：依赖的服务在对应地区已上线，但是每个地区的调用不一致，这是最复杂的场景，因为活动系统需要根据不同地区兼容依赖侧的差异性，这里为了减少共线服务中出现过多的定制化开发，可以将外部调用统一转发，根据不同的地区码调用相应的外部服务。

综上，对于已经全球共线的服务对接，不需要额外处理；对于在个别地区还未上线的外部依赖服务，可以根据紧急程度作处理，最好的方案是推送依赖侧作共线并上线。对于同一个依赖在不同地区能力不统一的场景，也是最复杂的场景，活动系统需要根据不同地区分别转发处理，可以参照下图：

从图中可以看出，外部依赖都统一走通用转发处理，在解决资源差异过程中要注意以下几点：

• 优先使用配置解决，减少定制化处理

• 优先走通用转发服务，增加编码可读性

• 当服务无法一次性共线时注意依赖兼容性，避免影响服务启动和运营

• 对于未上线的外部依赖服务，推动服务共线，减少兼容成本

• 通用转发逻辑虽然可以单独作为一个服务专门用于中转，但是容易出现请求压力大，可以直接沉淀为通用 SDK 使用

3.3.3 共线后的服务如何维护？

先来看共线之前的内外销服务迭代情况：内外销服务是分别维护，相当于两个服务，大多服务先从内销开始发展，内销逐渐稳定后，业务扩展到外销，参照已有的内销服务建立外销服务，外销服务的初始状态相当于内销服务的一个分支，但是随着版本不断地迭代，业务不断地扩展，内销和外销变成了相对独立的两个服务，只有业务上会有一些相似的组件。

再来看共线后的服务迭代：一条主线，作为单个服务迭代。可以从下图看出，无论是内销还是外销，无论是哪个地区哪个国家，全球都只有一个服务，一套代码全球部署，相应地，每次版本迭代都会涉及所有的机房。

共线后需要注意一个问题，如果版本只涉及内销机房，其他机房暂时不部署？当然不可以，尽量每次版本迭代部署所有机房，原因如下：

• 代码变更积攒，增加测试成本，容易引发问题
• 数据库、配置变更在不同地区不一致，埋下隐患

虽然单次迭代成本增高，长期发展成本降低，大大提升外销活动复用率。同时共线后项目成员要养成全球化思维，业务思考、架构设计、测试点检等考虑多地区。

四、总结

项目在全球共线过程中，需要注意以下三点：

• 保证现有业务稳定：全球共线对现有的服务改动较大，注意充分考虑存量场景的兼容和回归，可以考虑分阶段完成。
• 充分考虑外部依赖：服务的外部依赖往往非常多，在共线过程中要充分考虑不同依赖在不同地区的资源差异。
• 具备业务全球化思维：共线后的服务就是一个服务单独维护，无论是产品、开发、测试等每个项目角色，在以后迭代的每个场景都需要考虑上线所有地区的场景。