一、交易发展历程

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运用生命周期和容器生命周期的一致性绑定。

四、总结与展望

技巧效劳于交易，全世界化技巧根植于全世界化交易，在“让天下没有难做的生意”的交易方向上，我们还有很多事情没有做好。同样，虽然历经多年建设，全世界化技巧系统也还有非常多不完善的地方，也还有非常多技巧挑拨待克服，我们依然在路上。