全球化技术根植于全球化业务，通过五个阶段的演进，逐步倒退成为阿里巴巴团体内绝对独立的技术体系。本文会首先重点解说全球化基础设施层的挑战和技术实际。
一、业务倒退历程
1.1 业务背景
从 1999 年阿里公司创建，阿里团体的全球化即已开始，公司的第一个业务单元 Alibaba.com 即是全球化业务，后续在 09 年公司成立 10 周年之际 AliExpressBeta 版本上线，标记着阿里的全球化走向 TO C 时代，再起初 16 年提出“接下来的 20 年，阿里巴巴团体要服务 20 亿消费者、发明 1 亿就业机会，帮忙 1000 万家中小企业盈利”，公司也陆续收买 Lazada（东南亚 6 国）、Daraz（南亚 5 国）、Trendyol（土耳其）等海内电商公司，由此正式拉开了全球化作为阿里团体三大策略（生产、云计算、全球化）之一的大航海时代。
2016 年阿里全球化相干业务收买陆续实现后，阿里团体的全球化业务布局初步造成：
- 上图展现了以后阿里全球化业务重点笼罩的国家 / 地区，能够看到业务重点国家 / 地区横跨亚、欧、美三大洲，业务诉求差别导致技术计划差别显著，一套端到端的技术计划不可能完满反对所有的国家 / 地区，然而差异化的档次组合 / 定制被实践证明可行，这对咱们 【零碎的标准化】 提出了要求；
- 粗放收割的时代曾经过来，在精细化经营时代，应答用户体验 / 合规监管，更凑近用户的技术计划部署，是本地体验构筑的根底，这又对咱们 【零碎的轻量化】 提出了要求；
- 随着数字化时代的日益深刻，数字化 / 智能化正越来越粗浅地影响和扭转着人类社会的方方面面。作为全球化业务，不管咱们的用户来自发达国家还是发展中国家，让数字 / 智能助力用户生存更美妙，永远是咱们保持的指标，而这也对咱们 【零碎的智能化】 提出了要求。
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 数据合规要求与部署架构
依据集体数据关闭范畴，跨境业务个别分为区域化架构计划、隐衷数据关闭计划和集体数据关闭计划三种。本对本业务则采纳独立单元关闭计划。
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 利用生命周期和容器生命周期的一致性绑定。
四、总结与瞻望
技术服务于业务，全球化技术根植于全球化业务，在“让天下没有难做的生意”的业务方向上，咱们还有很多事件没有做好。同样，尽管历经多年建设，全球化技术体系也还有十分多不欠缺的中央，也还有十分多技术挑战待克服，咱们仍然在路上。