一、营业发展历程

1.1 营业背景

从1999年阿里公司创立，阿里集团的环球化即已开始，公司的第一个营业单位Alibaba.com即是环球化营业，后续在09年公司成立10周年之际AliExpress Beta版本上线，标志着阿里的环球化走向TO C时代，再后来16年提出“接下来的20年，阿里巴巴集团要办事20亿消费者、创造1亿就业机会，帮助1000万家中小企业盈利”，公司也陆续收购Lazada（东南亚6国）、Daraz（南亚5国）、Trendyol（土耳其）等海外电商公司，由此正式拉开了环球化作为阿里集团三大战略（消费、云计算、环球化）之一的大航海时代。

2016年阿里环球化相关营业收购陆续完成后，阿里集团的环球化营业布局初步形成：

1.上图展示了当前阿里环球化营业重点覆盖的国家/地区，可以看到营业重点国家/地区横跨亚、欧、美三大洲，营业诉求差异导致手艺方案差异明显，一套端到端的手艺方案不可能完美支持所有的国家/地区，但是差异化的层次组合/定制被实践证明可行，这对我们【系统的标准化】提出了要求；

2.粗放收割的时代已经过去，在精细化运营时代，应对用户体验/合规监管，更靠近用户的手艺方案布局，是内陆体验构筑的基础，这又对我们【系统的轻量化】提出了要求；

3.随着数字化时代的日益深入，数字化/智能化正越来越深刻地影响和改变着人类社会的方方面面。作为环球化营业，不论我们的用户来自发达国家还是发展中国家，让数字/智能助力用户生活更美好，永远是我们坚持的目标，而这也对我们【系统的智能化】提出了要求。

1.2 环球化手艺系统迭代过程

为应对上述营业诉求，环球化手艺系统正式从集团手艺系统中孵化出来，并经过五个阶段的演进逐渐发展成为阿里巴巴集团内相对独立的手艺系统。

1.阶段一，鉴于国内淘宝、天猫、搜推等团队的系统，在6个月的时间搭建了全套支持Lazada的新电商内核系统。

2.阶段二，在这套电商内核系统上从事相应定制，搭建了全套支持Daraz的新电商系统。

3.阶段三，将这套电商内核和AE系统从事了深度融合，同时引入了淘宝、天猫等团队的优秀系统解决方案，形成了可同时支持内陆+跨境交易模式的国际化中台的雏形。

4.阶段四，以上述融合版本为基础，合并Lazada、Daraz、天猫淘宝海外，完成国际化中台手艺分支的4合1动作，最终形成了现在1个中台支撑N个站点的环球化新架构。

5.阶段五，国际化中台开源策略开始落地，历时1年多到2021年11月完成中台全链路开源，环球化营业和中台各自闭环迭代局面形成。

6.阶段六，未来已来，敬请期待。

接下来，我们会用一个系列文章，为大家讲清楚环球化手艺系统的寻衅和应对。在本文中，我们会首先和大家分享下环球化基础设施层的寻衅和手艺实践。

二、全球化基础设施层面面临的寻衅

从电商网站办事买卖家客户和网站经营两方面去分析，在环球范围内除了要满足用户访问网站的性能、可用性等基本要求外，环球化背景下还新增了环球布局、法律合规、数据断绝等要求，这些要求使我们的基础设施建设遇到了全新的寻衅，下面做一下举例说明：

·环球布局：无论是考量用户体验，还是考量监管合规，将基础设施从事环球化布局都是环球化营业必须要建设的基础才智，环球布局的基础设施也直接决定了环球化手艺系统的很多具体架构形态，同时环球布局的基础设施本身的建设维护也是巨大的寻衅。

·性能：这里说的性能指用户请求处理的时延，用户从发起请求到接收到响应的延时越短，代表性能越好。而环球互联网办事在延时上有天然的寻衅，即物理距离更长，机房可能在美国，而用户可能在澳大利亚。我们测试数据显示美国用户请求美国互联网办事一般的网络RTT是10ms以内，而俄罗斯用户请求美国西部机房的RTT在150ms到300ms之间不等，这直接导致用户的全屏加载时间会多出1秒钟，而1秒钟会造成转化率下降，甚至是用户流失。

·可用性：办事环球用户还有成本上的寻衅，这个寻衅会同时带来系统可用性上的寻衅。如果仅从内陆视角保障可用性，则我们需要在每个内陆都建设双机房保障高可用，但这样就无法利用其它地区机房的闲置资源，整体成本也会非常高昂。而我们7*24小时的可用性要求建立在环球视角上，因此，如果能做到环球范围的异地容灾，就可以在成本可接受的范围内，较好地兼顾用户的可用性。

·数据一致性：数据一致性寻衅是指当有数据被环球多地用户共享且多地用户都会从事读写时，如何确保数据一致？举例：环球买环球卖的场景，买家在内陆数据中心创建订单，卖家在其内陆数据中心维护订单，如果是同一笔订单且买家与卖家在不同的数据中心，如何保证多地读写一致？当环球数据中心之间相互灾备时，也会存在多地读写的情况，如何保证数据一致。

另外近几年随着环球化布局架构的升级，存量机房逐步往云机房迁移，新营业的扩展以及合规的布局架构都以云做为基础设施，环球化营业都已经运行在了云上，同时云也提供了更丰富、灵活、无限的基础设施才智。在云基础设施之上，我们实践了适用于海外的多模式布局以及容灾架构，用于解决用户的体验、可用性、数据一致性问题；并通过定义合规架构，充分地满足了各国法律对于营业合规的要求；与此同时，通过云原生的架构理念定义了如何用云产品重塑软件研发的过程。

下面将结合环球化面临的寻衅，从海外布局和容灾架构、数据合规、云原生架构实战三个角度详细说明环球化出海以及合规的实践。

三、鉴于云的出海落地实践

3.1 海外布局和容灾实战

3.1.1 阿里云基础设施

·IAAS层：依托于阿里云环球一致的基础设施，我们搭建了涉及环球6大地区、13个物理机房、17个逻辑机房(AZ)的海外数字商业的基础设施，在享受弹性资源才智的同时却无需在多个国家/地区布局和维护数据中心。

·PAAS层：依托于阿里云各类中间件/云产品从事环球布局，从而自上而下地解决环球化的一系列手艺寻衅。

3.1.2 环球化布局架构

鉴于本对本和跨境两种营业模式，我们有异地和同城两种布局架构，同时在一个地区机房内我们往往需要布局多国家多站点的营业，从而衍生出了多租户架构，下面将详细介绍我们在异地多活、同城双活、单地区多租户上的实践。

地区化异地多活

AliExpress的核心需求是电商的环球买&环球卖，此外还要考虑到用户就近访问的网络延时、容灾场景等。在这种多地区布局的场景以及核心需求的制约下，地区化布局的总体原则就很明确了，即不同于Amazon以及Lazada的内陆站点模式，不同地区之间必须保障数据的一致性。比如当来自不同地区的买卖家从事交易时，需要保障共享数据的一致性；当异地容灾时，用户地区从事迁移后，也需要保障不同地区办事分裂用户的一致性。

·网络层：用户根据DNS就近解析到最近的机房IDC，到达该机房的分裂接入层。

·接入层：需要桥接一个分裂路由层来对用户归属从事强一致性纠偏，即在接入层调用路由办事，查询用户的归属并实现跨机房调度，来达到用户跨机房跳转的目的。

·办事层：对于强一致性数据，例如支付、交易等，需要对分裂路由层的用户归属从事保障性兜底，即如果分裂路由层路由错误，那么MSE层也需要将办事跨机房调用回用户正确归属的机房从事消费；同时针对共享型数据的一致性问题，需要拓展出中心读写的跨机房办事调用功能；简而言之，在MSE层需要实现根据用户归属或者中心机房消费的跨机房调用功能。

·数据库层：我们通过扩展其插件，实现了禁写功能，同样是对于用户归属错误和数据强一致性保障的兜底，即用户归属地区如果和实际调用地区不一致，我们将会对其禁写保护，来避免不同地区之间的数据脏写。

·数据同步层：中心机房和地区机房之间数据从事双向同步，保障异地容灾的数据一致性，避免用户地区更改后的数据缺失情况。

本对本同城双活

不同于AliExpress的环球买卖营业，Lazada/Daraz营业更聚焦在东南亚地区，采用的是内陆买卖Local to Local模式，因此采用的是本对本同城双活布局架构。 

同城双活容灾建设顾名思义在一个城市内的两个IDC从事灾备建设，目标是在一个IDC出现故障后能够快速切换至另外一个IDC上，保证营业可用。采用双单位布局架构，借助单位化来实现单位内流量自闭环断绝，数据库使用RDS三节点企业版来保障其高可用性。一旦发现故障灾备，可以从入口流量、分裂接入层等快速切换至另外一个IDC上，保障营业可用。

多租户架构

环球化营业的基本特点是多地区、多币种、多语言，为了实现经营策略精细化执行，鉴于这几个维度，可以确定营业经营单位，为了实现每个经营单位间的断绝和经营地域元数据标准化，需要提出面向营业经营地区的租户概念，而在手艺架构层面需要提供分裂的面向多地区的租户架构标准。每个经营单位的营业体量、营业形态都存在一定的差异，所以从布局架构上可以提供租户的物理断绝和逻辑断绝两种形态，在手艺架构上需要提供配置断绝、数据断绝、流量断绝才智，在租户定义上需要保持分裂的租户模型。鉴于分裂的租户建立经营单位和手艺架构之间的映射关系，从而能够以租户实现经营单位维度的开发、测试、布局、运维等研发活动，降低研发活动过程中经营单位之间的耦合，提升经营单位的独立性。

鉴于多租户架构设计理念，运行态内部的工作原理分为如下几个核心部分：

·【流量染色】端上请求识别，确定是什么租户的流量，并对流量从事染色

·【精确选址】鉴于流量染色，以及接入网关层的办事路由才智，精确选址到租户所在物理集群

·【链路透传】集群单个办事实例内部，需要解决租户标的透传问题，以及跟上下游同步、异步交互过程中租户信息的透传

·【资源断绝】在内部营业逻辑执行过程中，对任何资源的操作，都需要考虑断绝性问题，比如配置，数据，流量等

3.1.3 环球容灾解决方案

·Region级和网络不可用：机房级不可用，外网入口无法抵达物理机房或者各个物理机房之间无法互通。

·办事级不可用：外网/内网连通性正常，办事不可用。

·数据层不可用：DB/缓存不可用。

·网络容灾：用户的第一跳网络路由之外（如小区网络异常我们基本没有什么操作空间），在接下来的第2->N跳，我们分别可以建设网络运营商切换才智（多CDN厂商互切），机房链路切换才智（Region级别互切），机房入口运营商切换才智（IDC网络团队互切）等各种手段来尝试从事灾难恢复。

·接入层容灾：在流量抵达阿里云机房，进入内部网关路由层后，按照用户粒度级别、Api粒度级别等多维度从事实时流量纠偏，秒级生效。在网络以及网关产品无异常的情况下，接入层容灾是日常态被利用、演练次数最多的容灾方案。

·办事层容灾：对于某些强中心办事，例如库存、营销等单地区扣减办事，也需要建设其灾备才智。

·数据层容灾：对于多活架构，在确保数据单一Master的基础上，确保容灾过程中数据不会脏写。对于合规场景，考虑某些Region不具备敏感数据，实现有限定场景下的合规容灾才智。

3.2环球数据合规实战

3.2.1 环球合规领域介绍

对于互联网电商平台，整体风险合规领域非常宽泛，风险以及合规领域的差别，各自的内容大致如上图所示。合规一般主要涉及以下内容：数据合规、知识产权侵权、商品内容安全、交互内容安全、手艺出口合规、APP合规等，这些内容也是当下监管关注的重点，除数据合规外，其他合规问题主要集中在个别营业场景，例如知产侵权、商品内容安全主要存在于商品域，交互内容安全则主要存在于买卖家沟通、直播等场景。

合规工作的重点是数据合规，几乎贯穿电商平台的所有场景，凡是涉及到数据处理的问题，都可以和数据合规相关，同时数据合规由于其监管的敏感性，对于平台来说属于营业熔断性风险。

3.2.2 数据合规要求与布局架构

根据个人数据封闭范围，跨境营业一般分为地区化架构方案、隐私数据封闭方案和个人数据封闭方案三种。本对本营业则采用独立单位封闭方案。

营业模式

方案

数据范围

跨境营业

1. 地区化架构

无针对性数据断绝，针对地区机房从事按需过滤

2. 隐私数据封闭

各地区隐私数据断绝，中心机房无地区非脱敏隐私数据

3. 个人数据封闭

各地区个人数据断绝，中心机房无地区非脱敏隐私数据

本对本营业

4. 独立单位封闭

类似全数据断绝，数据内陆独立单位断绝，内陆完成营业布局

3.2.3 内陆存储解决方案

数据合规层面经常会面临一个直接的监管诉求：数据内陆存储（不允许离境 or 内陆留存备查）。甚至某些敏感营业存在更高的监管要求，会存在不允许使用公有云或者公有云资源高安全独立的情况。为此我们需要具备自建完整基础设施以满足合规建站需求的才智。

3.3 利用架构云原生化

云原生手艺有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的利用。云原生的代表手艺包括容器、办事网格、微办事、不可变基础设施和声明式API等。这些手艺能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生手艺使工程师能够轻松地对系统作出频繁和可预测的重大变更。

对于环球化手艺研发而言，除了将营业运行在云上，也需要进一步从自身营业研发的寻衅以及痛点出发，结合云原生的手艺以及相关的架构理念来解决营业研发、运维本身的效率问题。

3.1传统利用架构面临的寻衅

图 传统利用架构模式

上图描述了传统利用架构下的软件托付过程。从这整个过程中看，利用扮演了研发态的对象、托付态的载体、运行态的容器，软件才智所期望的所有才智都是通过在利用源码中声明式的引用，并且通过分裂构建完成软件整体性托付，这个过程可以叫做软件的富利用（Fat Application）托付。

由于环球化平台最初是从实际的营业系统演进而来的（交易、营销、支付…..），所以平台也不例外，延续了传统的利用架构模式。但随着平台自身逐渐演进，以及平台之上的营业多样性发展，不管是从组织架构还是营业架构上都带来了很大的冲击，主要面临着如下三方面寻衅：

·利用架构不可持续：富利用托付模式下，在软件生产过程中，始终存在一个单点——利用，当利用所支撑的内容逐渐庞大和复杂的时候，那么它将是影响研发效率的关键点，也是影响整个国际化平台架构的可持续性的最大寻衅。

·研发托付不确定性：环球化平台和营业分层的研发模式在目的和变更节奏是不一致的。为解决这两者的差异，会导致利用自身逐渐臃肿和腐蚀，于是给日常研发迭代带来很大的不确定性和不可预见性。

·运维才智缺乏标准：随着利用自身的复杂度增加，与之匹配的运维才智也会随之增加，而当前提倡的DevOps理念，也衍生出很多相关的产品和工具，但这些产品和工具的标准不分裂，进而造成零散繁杂、无分裂产品入口的现象，导致运维效率和理解成本不断增加。

针对上面的寻衅，云原生手艺提供给我们新的解题思路：

·容器编排手艺：通过云原生的容器编排手艺将传统的软件托付过程演进为各个容器编排组合式托付，将单个利用托付拆分成多个模块灵活编排托付，从而推动环球化利用托付系统的演进。

·托付物镜像化：利用不再是研发的唯一对象，而是打造镜像研发系统，鉴于镜像的不变性来确保托付内容的确定性，并实现平台才智镜像化，具有独立稳定的研发系统。

·分裂运维标准：借助云原生IaC/OAM等GitOps理念，通过分裂的模式去收敛并定义云原生下的利用运维标准。并重新定义营业组织的SRE，通过分裂视角去查询、分析、度量利用的运维才智现状和资源使用情况。

3.2 环球化云原生架构实践

3.2.1 鉴于云原生的利用架构

结合上文提到的云原生解题思路，我们对整体的环球化研发托付过程从事了抽象，用于支撑更广义的环球化利用架构升级。这个过程中，我们也充分结合了云原生中先进的手艺，并利用到环球化的场景中：

·IaC：提供分裂研发基础设施声明范式。为了将平台对营业依赖从事更好的解耦，降低平台认知成本，我们对站点利用的IaC从事了分层抽象标准定义，围绕环球化场景定义基础设施标准，从规格、日志采集、探针、hook、发布策略等从事分裂收敛，降低营业接入IaC成本。

·OAM：提供分裂利用模型的定义。依托于OAM开发和运维关注点分离、平台无关与高可扩展、模块化利用布局和运维等特点，我们对营业和平台面向利用的标准从事规范定义，从而更好地链接利用开发者、运维人员、利用基础设施，让云原生利用托付和管理流程更加连贯一致。

·GitOps：提供营业研发持续托付才智。鉴于云原生GitOps声明式理念，可以将外部依赖组件从才智集成到运维管控分裂声明在工程之中，进而只需要鉴于分裂的GitOps标准从事依赖才智的声明和定义，从而将组件才智的托付和管控交给底层的GitOps引擎，提升整个软件系统的完整性和可持续性。

·ACK：提供资源分裂调度引擎。我们鉴于阿里云的ACK容器办事，使用其提供的强大的容器编排、资源调度、和自动化运维等才智，实现对不同环境托付不同的营业模块功能，并且鉴于上层的流量调度，实现营业按需布局，按需调度。

·容器编排：通过ACK容器灵活编排手艺成功的将环球化利用架构再升级，将营业逻辑和基础设施、平台才智、公共富客户端在研发态从事完全断绝，在运行态营业进程和运维进程通过轻量化容器做到相对彻底的断绝，提升整体利用研发托付效率和营业形态的稳定性。

图 利用架构在容器态的集成

这里重点强调一下容器编排的实践。在环球化利用架构升级的过程中一共衍生出了三大类容器，如上图所示：

·基础设施容器（Base Container），其中就包含运维容器、网关容器等利用所依赖的基础设施的才智；

·临时容器（Temporary Container），该容器不具备任何生命周期，其作用就是为了将自身的研发产物通过Pod下的共享目录集成到主利用容器和营业容器内，完成整个才智的集成和被使用，主要由平台容器构成；

·营业容器（Business Container），该容器和主利用容器一样，具备完整的生命周期，且通过gRPC完成和主利用的通信，主要由类目、多语等富客户端容器构成。

3.2.2 鉴于云原生的运维系统

图 环球化利用架构中的运维系统

结合着利用架构的升级，环球化也对利用的运维系统从事了升级。借助云原生架构系统与IaC标准的声明式引用, 环球化分裂了多种利用运维才智的使用，并且通过基础设施的强大才智实现了效率提升, 包括但不限于：

·利用发布: 智能发布决策、原地升级、滚动升级、分批发布

·弹性容量: 自动弹性、定时弹性、CPUShare

·批量运维：利用容器的原地重启、容器置换、日志清理、JavaDump

·轻量化容器: 运维容器独立、Sidecar编排

·多容器托付布局: 端口冲突、进程冲突、文件目录共享

·可观测与稳定性: 利用生命周期、启动异常诊断、白屏化、容器视角监控

图 云资源BaaS化

在这个运维系统中，环球化也引入了云原生的BaaS才智。BaaS提供一整套面向终态的、关注点分离(Application、Infrastructure)的解决方案，打通了阿里云及中间件资源的生产、计量计费、身份授权、消费流程，将IaC作为入口提供端到端的使用体验。环球化通过引入BaaS才智, 实现了SRE对利用云资源使用的分裂度量管理, 同时研发人员可以通过BaaS实现多种资源的一致性声明式使用, 大大降低了使用成本。

图 Java进程生命周期规范化

为了提升云原生环境下的利用自愈才智, 我们也分裂了Java利用在K8s Pod中的生命周期规范，将利用启动、运行(存活与就绪)、停服等不同阶段从事标准化定义, 并通过IaC和SDK的模式开放给营业使用，实现Java利用生命周期和容器生命周期的一致性绑定。

四、总结与展望

手艺办事于营业，环球化手艺根植于环球化营业，在“让天下没有难做的生意”的营业方向上，我们还有很多事情没有做好。同样，虽然历经多年建设，环球化手艺系统也还有非常多不完善的地方，也还有非常多手艺寻衅待克服，我们依然在路上。