6年技术迭代，阿里全球化出海&合规的挑战和探索
这是阿里技术2022年的第22篇原创文章
（ 本文阅读时间：20分钟 ）
全球化技术根植于全球化业务，经过五个阶段的演进，逐渐发展成为阿里巴巴集团内相对独立的技术体系。本文会首先重点讲解全球化基础设施层的挑战和技术实践。
01
业务发展历程
业务背景
从1999年阿里公司创立，阿里集团的全球化即已开始，公司的第一个业务单元Alibaba.com即是全球化业务，后续在09年公司成立10周年之际AliExpress Beta版本上线，标志着阿里的全球化走向TO C时代，再后来16年提出“接下来的20年，阿里巴巴集团要服务20亿消费者、创造1亿就业机会，帮助1000万家中小企业盈利”，公司也陆续收购Lazada（东南亚6国）、Daraz（南亚5国）、Trendyol（土耳其）等海外电商公司，由此正式拉开了全球化作为阿里集团三大战略（消费、云计算、全球化）之一的大航海时代。
2016年阿里全球化相关业务收购陆续完成后，阿里集团的全球化业务布局初步形成：
上图展示了当前阿里全球化业务重点覆盖的国家/地区，可以看到业务重点国家/地区横跨亚、欧、美三大洲，业务诉求差异导致技术方案差异明显，一套端到端的技术方案不可能完美支持所有的国家/地区，但是差异化的层次组合/定制被实践证明可行，这对我们【系统的标准化】提出了要求；
粗放收割的时代已经过去，在精细化运营时代，应对用户体验/合规监管，更靠近用户的技术方案部署，是本地体验构筑的基础，这又对我们【系统的轻量化】提出了要求；
随着数字化时代的日益深入，数字化/智能化正越来越深刻地影响和改变着人类社会的方方面面。作为全球化业务，不论我们的用户来自发达国家还是发展中国家，让数字/智能助力用户生活更美好，永远是我们坚持的目标，而这也对我们【系统的智能化】提出了要求。
全球化技术体系迭代过程
为应对上述业务诉求，全球化技术体系正式从集团技术体系中孵化出来，并经过五个阶段的演进逐渐发展成为阿里巴巴集团内相对独立的技术体系。
阶段一，基于国内淘宝、天猫、搜推等团队的系统，在6个月的时间搭建了全套支持Lazada的新电商内核系统。
阶段二，在这套电商内核系统上进行相应定制，搭建了全套支持Daraz的新电商系统。
阶段三，将这套电商内核和AE系统进行了深度融合，同时引入了淘宝、天猫等团队的优秀系统解决方案，形成了可同时支持本地+跨境交易模式的国际化中台的雏形。
阶段四，以上述融合版本为基础，合并Lazada、Daraz、天猫淘宝海外，完成国际化中台技术分支的4合1动作，最终形成了现在1个中台支撑N个站点的全球化新架构。
阶段五，国际化中台开源策略开始落地，历时1年多到2021年11月完成中台全链路开源，全球化业务和中台各自闭环迭代局面形成。
阶段六，未来已来，敬请期待。
接下来，我们会用一个系列文章，为大家讲清楚全球化技术体系的挑战和应对。在本文中，我们会首先和大家分享下全球化基础设施层的挑战和技术实践。
02
全球化基础设施层面
面临的挑战
从电商网站服务买卖家客户和网站经营两方面去分析，在全球范围内除了要满足用户访问网站的性能、可用性等基本要求外，全球化背景下还新增了全球部署、法律合规、数据隔离等要求，这些要求使我们的基础设施建设遇到了全新的挑战，下面做一下举例说明：
全球部署：无论是考量用户体验，还是考量监管合规，将基础设施进行全球化部署都是全球化业务必须要建设的基础能力，全球部署的基础设施也直接决定了全球化技术体系的很多具体架构形态，同时全球部署的基础设施本身的建设维护也是巨大的挑战。
性能：这里说的性能指用户请求处理的时延，用户从发起请求到接收到响应的延时越短，代表性能越好。而全球互联网服务在延时上有天然的挑战，即物理距离更长，机房可能在美国，而用户可能在澳大利亚。我们测试数据显示美国用户请求美国互联网服务一般的网络RTT是10ms以内，而俄罗斯用户请求美国西部机房的RTT在150ms到300ms之间不等，这直接导致用户的全屏加载时间会多出1秒钟，而1秒钟会造成转化率下降，甚至是用户流失。
可用性：服务全球用户还有成本上的挑战，这个挑战会同时带来系统可用性上的挑战。如果仅从本地视角保障可用性，则我们需要在每个本地都建设双机房保障高可用，但这样就无法利用其它区域机房的闲置资源，整体成本也会非常高昂。而我们7*24小时的可用性要求建立在全球视角上，因此，如果能做到全球范围的异地容灾，就可以在成本可接受的范围内，较好地兼顾用户的可用性。
数据一致性：数据一致性挑战是指当有数据被全球多地用户共享且多地用户都会进行读写时，如何确保数据一致？举例：全球买全球卖的场景，买家在本地数据中心创建订单，卖家在其本地数据中心维护订单，如果是同一笔订单且买家与卖家在不同的数据中心，如何保证多地读写一致？当全球数据中心之间相互灾备时，也会存在多地读写的情况，如何保证数据一致。
另外近几年随着全球化部署架构的升级，存量机房逐步往云机房迁移，新业务的扩展以及合规的部署架构都以云做为基础设施，全球化业务都已经运行在了云上，同时云也提供了更丰富、灵活、无限的基础设施能力。在云基础设施之上，我们实践了适用于海外的多模式部署以及容灾架构，用于解决用户的体验、可用性、数据一致性问题；并通过定义合规架构，充分地满足了各国法律对于业务合规的要求；与此同时，通过云原生的架构理念定义了如何用云产品重塑软件研发的过程。
下面将结合全球化面临的挑战，从海外部署和容灾架构、数据合规、云原生架构实战三个角度详细说明全球化出海以及合规的实践。
03
基于云的出海落地实践
海外部署和容灾实战
✪ 阿里云基础设施
IAAS层：依托于阿里云全球一致的基础设施，我们搭建了涉及全球6大区域、13个物理机房、17个逻辑机房(AZ)的海外数字商业的基础设施，在享受弹性资源能力的同时却无需在多个国家/地区部署和维护数据中心。
PAAS层：依托于阿里云各类中间件/云产品进行全球部署，从而自上而下地解决全球化的一系列技术挑战。
✪ 全球化部署架构
基于本对本和跨境两种业务模式，我们有异地和同城两种部署架构，同时在一个区域机房内我们往往需要部署多国家多站点的业务，从而衍生出了多租户架构，下面将详细介绍我们在异地多活、同城双活、单区域多租户上的实践。
⍟ 区域化异地多活
AliExpress的核心需求是电商的全球买&全球卖，此外还要考虑到用户就近访问的网络延时、容灾场景等。在这种多区域部署的场景以及核心需求的制约下，区域化部署的总体原则就很明确了，即不同于Amazon以及Lazada的本地站点模式，不同区域之间必须保障数据的一致性。比如当来自不同区域的买卖家进行交易时，需要保障共享数据的一致性；当异地容灾时，用户区域进行迁移后，也需要保障不同区域服务统一用户的一致性。
网络层：用户根据DNS就近解析到最近的机房IDC，到达该机房的统一接入层。
接入层：需要桥接一个统一路由层来对用户归属进行强一致性纠偏，即在接入层调用路由服务，查询用户的归属并实现跨机房调度，来达到用户跨机房跳转的目的。
服务层：对于强一致性数据，例如支付、交易等，需要对统一路由层的用户归属进行保障性兜底，即如果统一路由层路由错误，那么MSE层也需要将服务跨机房调用回用户正确归属的机房进行消费；同时针对共享型数据的一致性问题，需要拓展出中心读写的跨机房服务调用功能；简而言之，在MSE层需要实现根据用户归属或者中心机房消费的跨机房调用功能。
数据库层：我们通过扩展其插件，实现了禁写功能，同样是对于用户归属错误和数据强一致性保障的兜底，即用户归属区域如果和实际调用区域不一致，我们将会对其禁写保护，来避免不同区域之间的数据脏写。
数据同步层：中心机房和区域机房之间数据进行双向同步，保障异地容灾的数据一致性，避免用户区域更改后的数据缺失情况。
⍟ 本对本同城双活
不同于AliExpress的全球买卖业务，Lazada/Daraz业务更聚焦在东南亚地区，采用的是本地买卖Local to Local模式，因此采用的是本对本同城双活部署架构。
同城双活容灾建设顾名思义在一个城市内的两个IDC进行灾备建设，目标是在一个IDC出现故障后能够快速切换至另外一个IDC上，保证业务可用。采用双单元部署架构，借助单元化来实现单元内流量自闭环隔离，数据库使用RDS三节点企业版来保障其高可用性。一旦发现故障灾备，可以从入口流量、统一接入层等快速切换至另外一个IDC上，保障业务可用。
⍟ 多租户架构
全球化业务的基本特点是多区域、多币种、多语言，为了实现经营策略精细化执行，基于这几个维度，可以确定业务经营单元，为了实现每个经营单元间的隔离和经营地域元数据标准化，需要提出面向业务经营区域的租户概念，而在技术架构层面需要提供统一的面向多区域的租户架构标准。每个经营单元的业务体量、业务形态都存在一定的差异，所以从部署架构上可以提供租户的物理隔离和逻辑隔离两种形态，在技术架构上需要提供配置隔离、数据隔离、流量隔离能力，在租户定义上需要保持统一的租户模型。基于统一的租户建立经营单元和技术架构之间的映射关系，从而能够以租户实现经营单元维度的开发、测试、部署、运维等研发活动，降低研发活动过程中经营单元之间的耦合，提升经营单元的独立性。
基于多租户架构设计理念，运行态内部的工作原理分为如下几个核心部分：
【流量染色】端上请求识别，确定是什么租户的流量，并对流量进行染色
【精确选址】基于流量染色，以及接入网关层的服务路由能力，精确选址到租户所在物理集群
【链路透传】集群单个服务实例内部，需要解决租户标的透传问题，以及跟上下游同步、异步交互过程中租户信息的透传
【资源隔离】在内部业务逻辑执行过程中，对任何资源的操作，都需要考虑隔离性问题，比如配置，数据，流量等
✪ 全球容灾解决方案
Region级和网络不可用：机房级不可用，外网入口无法抵达物理机房或者各个物理机房之间无法互通。
服务级不可用：外网/内网连通性正常，服务不可用。
数据层不可用：DB/缓存不可用。
网络容灾：用户的第一跳网络路由之外（如小区网络异常我们基本没有什么操作空间），在接下来的第2->N跳，我们分别可以建设网络运营商切换能力（多CDN厂商互切），机房链路切换能力（Region级别互切），机房入口运营商切换能力（IDC网络团队互切）等各种手段来尝试进行灾难恢复。
接入层容灾：在流量抵达阿里云机房，进入内部网关路由层后，按照用户粒度级别、Api粒度级别等多维度进行实时流量纠偏，秒级生效。在网络以及网关产品无异常的情况下，接入层容灾是日常态被应用、演练次数最多的容灾方案。
服务层容灾：对于某些强中心服务，例如库存、营销等单区域扣减服务，也需要建设其灾备能力。
数据层容灾：对于多活架构，在确保数据单一Master的基础上，确保容灾过程中数据不会脏写。对于合规场景，考虑某些Region不具备敏感数据，实现有限定场景下的合规容灾能力。
全球数据合规实战
✪ 全球合规领域介绍
对于互联网电商平台，整体风险合规领域非常宽泛，风险以及合规领域的差别，各自的内容大致如上图所示。合规一般主要涉及以下内容：数据合规、知识产权侵权、商品内容安全、交互内容安全、技术出口合规、APP合规等，这些内容也是当下监管关注的重点，除数据合规外，其他合规问题主要集中在个别业务场景，例如知产侵权、商品内容安全主要存在于商品域，交互内容安全则主要存在于买卖家沟通、直播等场景。
合规工作的重点是数据合规，几乎贯穿电商平台的所有场景，凡是涉及到数据处理的问题，都可以和数据合规相关，同时数据合规由于其监管的敏感性，对于平台来说属于业务熔断性风险。
✪ 数据合规要求与部署架构
根据个人数据封闭范围，跨境业务一般分为区域化架构方案、隐私数据封闭方案和个人数据封闭方案三种。本对本业务则采用独立单元封闭方案。
| 业务模式 | 方案 | 数据范围 |
| 跨境业务 | 1. 区域化架构 | 无针对性数据隔离，针对区域机房进行按需过滤 |
| 2. 隐私数据封闭 | 各区域隐私数据隔离，中心机房无区域非脱敏隐私数据 | |
| 3. 个人数据封闭 | 各区域个人数据隔离，中心机房无区域非脱敏隐私数据 | |
| 本对本业务 | 4. 独立单元封闭 | 类似全数据隔离，数据本地独立单元隔离，本地完成业务部署 |
✪ 本地存储解决方案
数据合规层面经常会面临一个直接的监管诉求：数据本地存储（不允许离境 or 本地留存备查）。甚至某些敏感业务存在更高的监管要求，会存在不允许使用公有云或者公有云资源高安全独立的情况。为此我们需要具备自建完整基础设施以满足合规建站需求的能力。
应用架构云原生化
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API等。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
对于全球化技术研发而言，除了将业务运行在云上，也需要进一步从自身业务研发的挑战以及痛点出发，结合云原生的技术以及相关的架构理念来解决业务研发、运维本身的效率问题。
✪ 传统应用架构面临的挑战
图 传统应用架构模式
上图描述了传统应用架构下的软件交付过程。从这整个过程中看，应用扮演了研发态的对象、交付态的载体、运行态的容器，软件能力所期望的所有能力都是通过在应用源码中声明式的引用，并且通过统一构建完成软件整体性交付，这个过程可以叫做软件的富应用（Fat Application）交付。
由于全球化平台最初是从实际的业务系统演进而来的（交易、营销、支付.....），所以平台也不例外，延续了传统的应用架构模式。但随着平台自身逐渐演进，以及平台之上的业务多样性发展，不管是从组织架构还是业务架构上都带来了很大的冲击，主要面临着如下三方面挑战：
应用架构不可持续：富应用交付模式下，在软件生产过程中，始终存在一个单点——应用，当应用所支撑的内容逐渐庞大和复杂的时候，那么它将是影响研发效率的关键点，也是影响整个国际化平台架构的可持续性的最大挑战。
研发交付不确定性：全球化平台和业务分层的研发模式在目的和变更节奏是不一致的。为解决这两者的差异，会导致应用自身逐渐臃肿和腐蚀，于是给日常研发迭代带来很大的不确定性和不可预见性。
运维能力缺乏标准：随着应用自身的复杂度增加，与之匹配的运维能力也会随之增加，而当前提倡的DevOps理念，也衍生出很多相关的产品和工具，但这些产品和工具的标准不统一，进而造成零散繁杂、无统一产品入口的现象，导致运维效率和理解成本不断增加。
针对上面的挑战，云原生技术提供给我们新的解题思路：
容器编排技术：通过云原生的容器编排技术将传统的软件交付过程演进为各个容器编排组合式交付，将单个应用交付拆分成多个模块灵活编排交付，从而推动全球化应用交付体系的演进。
交付物镜像化：应用不再是研发的唯一对象，而是打造镜像研发体系，基于镜像的不变性来确保交付内容的确定性，并实现平台能力镜像化，具有独立稳定的研发体系。
统一运维标准：借助云原生IaC/OAM等GitOps理念，通过统一的模式去收敛并定义云原生下的应用运维标准。并重新定义业务组织的SRE，通过统一视角去查询、分析、度量应用的运维能力现状和资源使用情况。
✪ 全球化云原生架构实践
⍟ 基于云原生的应用架构
结合上文提到的云原生解题思路，我们对整体的全球化研发交付过程进行了抽象，用于支撑更广义的全球化应用架构升级。这个过程中，我们也充分结合了云原生中先进的技术，并应用到全球化的场景中：
IaC：提供统一研发基础设施声明范式。为了将平台对业务依赖进行更好的解耦，降低平台认知成本，我们对站点应用的IaC进行了分层抽象标准定义，围绕全球化场景定义基础设施标准，从规格、日志采集、探针、hook、发布策略等进行统一收敛，降低业务接入IaC成本。
OAM：提供统一应用模型的定义。依托于OAM开发和运维关注点分离、平台无关与高可扩展、模块化应用部署和运维等特点，我们对业务和平台面向应用的标准进行规范定义，从而更好地链接应用开发者、运维人员、应用基础设施，让云原生应用交付和管理流程更加连贯一致。
GitOps：提供业务研发持续交付能力。基于云原生GitOps声明式理念，可以将外部依赖组件从能力集成到运维管控统一声明在工程之中，进而只需要基于统一的GitOps标准进行依赖能力的声明和定义，从而将组件能力的交付和管控交给底层的GitOps引擎，提升整个软件系统的完整性和可持续性。
ACK：提供资源统一调度引擎。我们基于阿里云的ACK容器服务，使用其提供的强大的容器编排、资源调度、和自动化运维等能力，实现对不同环境交付不同的业务模块功能，并且基于上层的流量调度，实现业务按需部署，按需调度。
容器编排：通过ACK容器灵活编排技术成功的将全球化应用架构再升级，将业务逻辑和基础设施、平台能力、公共富客户端在研发态进行完全隔离，在运行态业务进程和运维进程通过轻量化容器做到相对彻底的隔离，提升整体应用研发交付效率和业务形态的稳定性。
图 应用架构在容器态的集成
这里重点强调一下容器编排的实践。在全球化应用架构升级的过程中一共衍生出了三大类容器，如上图所示：
基础设施容器（Base Container），其中就包含运维容器、网关容器等应用所依赖的基础设施的能力；
临时容器（Temporary Container），该容器不具备任何生命周期，其作用就是为了将自身的研发产物通过Pod下的共享目录集成到主应用容器和业务容器内，完成整个能力的集成和被使用，主要由平台容器构成；
业务容器（Business Container），该容器和主应用容器一样，具备完整的生命周期，且通过gRPC完成和主应用的通信，主要由类目、多语等富客户端容器构成。
⍟ 基于云原生的运维体系
图 全球化应用架构中的运维体系
结合着应用架构的升级，全球化也对应用的运维体系进行了升级。借助云原生架构体系与IaC标准的声明式引用, 全球化统一了多种应用运维能力的使用，并且通过基础设施的强大能力实现了效率提升, 包括但不限于：
应用发布: 智能发布决策、原地升级、滚动升级、分批发布
弹性容量: 自动弹性、定时弹性、CPUShare
批量运维：应用容器的原地重启、容器置换、日志清理、JavaDump
轻量化容器: 运维容器独立、Sidecar编排
多容器交付部署: 端口冲突、进程冲突、文件目录共享
可观测与稳定性: 应用生命周期、启动异常诊断、白屏化、容器视角监控
图 云资源BaaS化
在这个运维体系中，全球化也引入了云原生的BaaS能力。BaaS提供一整套面向终态的、关注点分离(Application、Infrastructure)的解决方案，打通了阿里云及中间件资源的生产、计量计费、身份授权、消费流程，将IaC作为入口提供端到端的使用体验。全球化通过引入BaaS能力, 实现了SRE对应用云资源使用的统一度量管理, 同时研发人员可以通过BaaS实现多种资源的一致性声明式使用, 大大降低了使用成本。
图 Java进程生命周期规范化
为了提升云原生环境下的应用自愈能力, 我们也统一了Java应用在K8s Pod中的生命周期规范，将应用启动、运行(存活与就绪)、停服等不同阶段进行标准化定义, 并通过IaC和SDK的模式开放给业务使用，实现Java应用生命周期和容器生命周期的一致性绑定。
04
总结与展望
技术服务于业务，全球化技术根植于全球化业务，在“让天下没有难做的生意”的业务方向上，我们还有很多事情没有做好。同样，虽然历经多年建设，全球化技术体系也还有非常多不完善的地方，也还有非常多技术挑战待克服，我们依然在路上。