随着经济全球化的趋势，许多中国品牌开始在海外市场开疆扩土，vivo 活动系统业务也逐渐覆盖了海外geng多国家和地区，包括泰国、新加坡、印尼等。

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

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

内销上线了一个抽奖活动，先投放在内销地区，上线后发现活动运营情况hen好，也深受用户喜爱。所以外销地区也想复用这个抽奖活动，但是内外销作为多个服务在维护，外销服务相对独立，那么就需要参照内销Yi有的业务 开发组件，不仅耗费人力，活动复用性也会hen差。

哈哈，你懂的，这样的场景往往具有时效性，其他地区急于复用推广，但是同样的活动却需要重复的开发，由此产生全球共线的想法。

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

**提升吞吐量与带宽效率：**流量就近接入，避免了全球长途骨干网的拥堵，提升了整体网络吞吐Neng力，并节省了昂贵的跨境带宽成本。

**低延迟：**不同地区的用户请求会通过 ng 通用规则进行转发，保证请求效率geng好，实践得出多机房部署和请求方案Ke以有效减少请求时间 %。

**业务灵活性：**敏捷 ，新项目上线，只需复制一套“项目容器”；项目进入新国家，只需在该项目下激活并配置新的“国家分区”。互不干扰，快速部署。

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

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

传统的多语言方案比较简单，针对不同语言的配置文件，在活动上线前准备好并上传，管理员负责去维护 i18n 资源文件，用户侧需要使用多语言展示时直接获取，这样Zuo的方案虽然简单，但是有两个明显的缺点：翻译文件变geng繁琐，变geng需要发版上线；维护繁琐，需要运营、开发、测试多种角色。

活动系统在传统多语言方案的基础上进行了升级，如下图所示，升级方案有几点优势：集成了多语言系统，管理员的维护是在多语言平台进行的，操作便捷， 维护简单；维护的数据一方面在数据库进行持久化，同时会维护在配置中心，性Nenggeng优，用户体验geng好；

针对不同时区时间不同，活动系统需要处理时间相关的展示，这种情况Ke以采用Zui简单的方案，运营配置时间即存储时间，用户侧展示的时候同一转换为当地时区，这是Zui直接的方案，但是存在以下几个缺点：运营Ru果配置异地活动，需要自行转换时间再配置，增加了运营理解成本；同样的编码逻辑和同一个数据库会存在不同的时区，增加了开发的理解成本。

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

为了解决运营理解问题，Ke以将配置侧的时间直接转化为对应活动投放的地区时间，这样Ke以有效减少运营理解成本。

由于不同业务方的用户数据量非常大，这里对于数据存储会进行租户隔离，保证数据可用性，采用数据隔离有以下几点好处**数据安全：**与现有悟空存储隔离，进行单独数据库权限管控，提高数据安全性；**业务隔离：**对于活动平台而言，随着业务拓展到geng多的地区，平台业务方也越来越多，对于不同业务方的管理台权限隔离和管控需要进一步考虑；**合规：**法律法规强制要求：如欧盟的 GDPR、中国的《网络安全法》、《数据安全法》等，要求特定国家/地区公民的数据必须存储和处理在该司法辖区内。

为什么百度不收录？这个问题其实挺常见的，说实话，hen多网站dou会遇到这种情况。

一般来说有可Neng是因为网站内容质量不够高，或者是网站结构不够友好，导致搜索引擎爬虫难以抓取和索引网站内容，也有可Neng是因为网站刚刚建立，还没有被搜索引擎收录，或者是因为网站被搜索引擎惩罚等等原因， 这是一个挺复杂的问题，需要具体情况具体分析，你得好好检查一下你的网站，有可Neng是因为你的网站 sitemap 没有提交给百度，或者是 robots.txt 文件设置有问题，又或者是网站内容重复度太高等等原因导致的，当然也有可Neng是因为百度的算法调整，导致你的网站不再符合收录标准等等，不对不对，应该说是有hen多种可Neng性的！

具备业务全球化思维：共线后的服务就是一个服务单独维护，无论是产品、开发、测试等每个项目角色，在以后迭代的每个场景dou需要考虑上线所有地区的场景。

充分考虑外部依赖：服务的外部依赖往往非常多，在共线过程中要充分考虑不同依赖在不同地区的资源差异性。

由于活动系统外部依赖在不同地区的情况不同，会出现以下三种场景：场景一：依赖的服务Yi经完成全球共线，也就意味着对应依赖的服务全球只有一套，无论哪个机房douNeng够支持业务调用，这是Zui好的场景，因为不需要任何的额外处理，活动系统Ke以直接用同样的调用逻辑调用外部服务。场景二：依赖的服务在对应地区未上线，这种情况需要考虑多种因素，若业务非常紧急，依赖侧来不及开发版本上线支持，Ke以作临时转发规则到可用机房进行处理，非紧急情况不建议；场景三：依赖的服务在对应地区Yi上线，但是每个地区的调用不一致，这是Zui复杂的场景，因为活动系统需要根据不同地区兼容依赖侧的差异性，这里为了减少共线服务中出现过多的定制化开发，Ke以将外部调用统一转发，根据不同的地区码调用相应的外部服务。

Ru果对于不同机房dou采用不同的域名进行请求，那么多域名分发方案跨区域访问维护繁琐，新增地区需要新增域名适配，增加成本。所以活动系统在共线过程中采用统一域名处理。目前的业务Ke以通过域名拼接地区码或者 Header 头携带地区码解决，两种方案douKe以解决多地区统一域名转发问题，我们采用 Header 头携带地区码方案，在 header 中新增请求头X-I18n-Code : loc = ${地区码}; lan = ${语言码}; tz = ${时区}, 加入地区码、语言码、时区等信息，便于逻辑处理。在请求转发层面就Ke以根据请求头的国家码直接配置转发规则，这样不仅解决了域名不断增加的问题，还有效保证全球共线一套服务的基础上, 请求也Neng得到统一的处理.