阿里巴巴核心系统作为全球最大规模、峰值性能要求最高的电商交易系统，在 2018 年之前只通过混合云弹性上云方式，为双 11 节约大量成本。直到 2019 年，阿里巴巴实现了核心交易系统全面上云并经历了双 11 峰值的考验。

在今天由极客邦科技举办的 ArchSummit 全球架构师峰会 2019 北京站上，阿里巴巴研究员张瓅玶博士作了主题演讲《阿里巴巴核心系统上云：挑战和架构演进的思考》，以下内容为演讲整理。

核心系统上云之路

工程师时常把我们的系统用飞机来做比喻，乘客则是上面承载的业务。云也是一架这样的载客飞机，作为基础平台承载着千万家企业的业务。今年阿里巴巴实现了核心系统 100% 上云，这个过程实际上走了几年才达到今天的进展，而且这还不是结束，也只是阿里巴巴上云的一个开始。

阿里巴巴集团自身业务体量巨大，支撑其的互联网技术体系任务也非常繁重，再加上核心电商业务系统的复杂度，对技术带来的挑战可想而知。用王坚博士的话说，核心系统上云让阿里巴巴和客户真正坐上了同一架飞机。从 in-house 的基础设施、定制化的平台能力，到通用的云平台，从 cloud hosting 到 cloud native，这个过程面临着巨大的挑战，同时也是阿里巴巴自身和阿里云的架构演进升级的历程。

阿里巴巴的核心交易系统涉及到包括天猫、淘宝、河马、菜鸟、聚划算、咸鱼、飞猪等一系列业务，其背后的核心电商系统的架构演进经历了单机房架构、同城双机房架构再到目前的中心同城容灾，三地多单元多活架构。软件也分为应用、微服务 / 中间件和数据库。

阿里巴巴的上云步骤一共分为三个阶段：

第一阶段：在 2015 年之前未上云，全部采用内部的基础设施。

第二阶段：2015 开始，双 11 期间单元化的交易应用开始通过弹性使用云资源，实现成本节约的目标（注: 图中上云单元规模和实际上云规模不成比例）。

第三阶段：2018 年的 12 月，CTO 行癫决定阿里巴巴启动全面上云，随后组建了以毕玄为上云总架构师的架构组，确定了上云的方案和步骤。2019 年经过 1 年的努力，终于在双 11 前实现了核心系统的全面上云。这一年核心电商的中心和单元业务，包括数据库、中间件等组件，实现了全面上云和使用云的服务。通过弹性运化，以及离在线混部（图中未标识）等能力，使大促成本持续下降，到 2018 年，大促新增成本比前一年下降 17%，比早期方案下降 3/4。

这一年核心电商的中心和单元业务，包括数据库、中间件等组件，实现了全面上云和使用云的服务。全面上云也不只是将机器搬到云上，更重要的是 replatforming，集团的技术栈和云产品融合，应用通过神龙服务器 + 容器和 K8s 上云，数据库接入 PolarDB，中间件采用云中间件和消息产品，负载均衡采用云 SLB 产品等。

云已经成为了基础设施，无论是电商公司还是其他行业，都可以用云去做更多事情。

云化架构

以全面上云的 2019 年为例，2019 年双 11 的实测，集群的规模超过百万容器，单容器集群节点数量过万，数据库的峰值超过 54 万笔每秒，对应 8700 万查询每秒，而实时计算每秒峰值处理消息超过 25 亿条，消息系统 RocketMQ 峰值处理了超过每秒 1.5 亿条消息。

这些数据背后所代表的，就是上云过程中形成的巨大挑战。针对这些挑战，阿里巴巴集团从服务器、存储、网络、数据中心等基础设施方面做了针对性的应对。

自研神龙服务器

核心系统全面上云决定采用了神龙服务器。神龙服务器自研了 HyperVisor 虚拟化卡来替代软件虚拟化，从而实现无性能损耗的虚拟化架构。其特点在于：

高性能：去掉了虚拟化带来的 8% 的性能损耗；支持二次虚拟化：使多样虚拟化技术 (Kata, Firecracker 等) 的探索和创新成为可能。

在阿里巴巴上云过程中，双 11 期间压力测试显示，高负载压力下的电商应用，实现 30% 的 QPS 上升，而 rt 也有明显下降，长尾 rt 下降尤其明显。同时，云化的神龙服务器，促进了运维管理的自动化和在线率水平的提升。阿里巴巴认为，神龙是容器的最佳载体，神龙 + 服务是无服务器化基础设施的最佳载体。

存储方面，走向了全面云化存储，也即全面存储计算分离。

上云也带来了大规模使用云存储产品：盘古（盘古 2.0），实现了集团业务的更大规模的存储计算分离。存储计算分离即业务逻辑执行在计算集群上面，存储部署在存储集群上面。计算和存储集群之间通过高速网络连接。随着数据处理对存储需求和计算需求在规模、速度、容量和成本等维度的不断变化，计算与存储分离可以最大限度地解耦并使这两类不同的关键资源相对独立地扩展和演进，获得更好的弹性、资源效率，同时可以让应用更容易的获得分布式存储的可靠性。

上云过程中，盘古 2.0 的升级也带来更好的 io 长尾延迟的稳定性，通过慢盘黑名单、backup read、动态 timeout 等关键技术大幅度的改进了长尾延迟。

网络：高速混合云

原有的集团安全域，由现有的集团自建网络为主体逐渐转变为以云上集团的虚拟网络为主体，以 VPC 的方式实现网络隔离混合云网络：为了实现集团网络与云上 VPC 内业务单元的互通，采用了云专线产品方案，组成了混合云网络。云专线方案中的虚拟网络网关（xGW 集群），采用硬件化 HGW 集群。

数据中心：自建网络迁移上云

数据中心自建网络迁移到 VPC，在上云过程中，实现了云 VPC 最大规模提升 4 倍。安全组性能大幅度优化，企业级安全组最大容量提升 25 倍。在公司内部，各业务自建的网络之间是相互独立的。随着全站云化，网络安全域的形态也随之发生变化，TB 级别的云上云下网络流量对穿，从软件实现的 XGW 升级到软硬结合的 HGW，单节点性能提升 20 倍。

另外，值得指出的是，资源、账号和权限体系对接互通是上云的重要环节。

上云架构未来演进：云原生

上云已成为趋势，但是核心系统上云只是下一个开始。

企业上云今天已经成为广泛接受的必然趋势，Rightscale state of the cloud report 2019 显示，94% 企业已经在使用云，其中公有云 91%，on prem 70%。企业的数字化转型的过程中，利用云的能力的过程也分为不同的阶段，一般来说也会是走过和阿里上云类似的过程：首先是弹性使用云的资源，实现部分业务上云，Cloud-hosting。在此过程中，一般是非核心系统使用云资源。然后涉及到核心系统的云化，这里发生的变化不仅仅是上云的应用的数量，更是底层基础设施整体使用云平台的能力的过程。

在阿里巴巴看来，未来是云原生化的。

什么是云原生？从技术角度讲，云原生技术是一系列的应用构建和运维最佳实践的集合。云原生技术的生命力在于它聚焦于给用户带来价值，这些价值分为几个方面：

容器和资源的编排，如 K8s、Container，带来的运维效率提升，和资源利用率的提升。中心化的编排可以很好的充分编排资源降低企业成本。分布式系统的可以弹性扩展的能力 Scalability 以及可靠性。尽管互联网技术发展了几十年，到今天，分布式、可扩展、可靠的系统，仍然是很难构建的。也得益于云原生领域开放技术和云的快速发展，一切正在变得越来越容易。开放治理和开放的技术，改变了云厂商和用户之间的信赖关系，越来越多的企业信赖开放标准的云服务。同时云原生也降低了迁云的成本。云原生技术所倡导的持续交付，聚焦于企业真正关注的价值，即迭代创新的速度，time to market。

从上云视角看，云原生（Cloud native）化是最大化使用云的能力，使企业聚焦于业务的实践。

为什么这么说？我们以阿里核心系统演进为例说明云原生化和使用云的能力的关系。

阿里巴巴的应用上云前仍然存在应用和基础设施耦合问题，由于采用自建软件基础设施，配置管理、发布升级、监控观测、流量治理等与业务应用耦合在一起，对于运维效率、研发演进效率和稳定性都带来了挑战。我们在上云过程中看到，实现标准的云基础设施和业务应用的全面解耦，将会带来全面的研发运维效率提升。

那么，使用 in-house 自建基础设施就一定不行吗？

阿里巴巴集团的基础设施也是由专门的团队维护的，也在一定意义上实现了基础设施和应用的解耦。不是所有的 in-house 的基础设施就不云原生。事实上，云原生技术的很多发源地，比如 Google 内部的基础设施很好地实现了和应用的解耦并带来了业界领先的研发运维效率。

但是一般来说，由于内部开发容易忽视基础设施和应用的边界而实现了过多的非标功能或者倾向于采用更快速落地的方案，这些容易带来基础设施和应用的更多耦合，不利于长期的演进和效率。例如阿里的容器化虽然带来了应用发布的标准化的优势，但是在容器化过程中我们采用了富容器方案加快容器化进程，使容器支持了很多虚拟机使用模式（启停、原地更新等），带来了容器的可迁移性比较差，容器运行生命周期可变带来运维成本等。因此运维效率、稳定性和业务的演进效率，在这种耦合中，都受到了不同程度损失。所以云原生化的关键路径，是实现应用和基础设施的解耦，并且通过采用标准化的云产品方式来支持。

那么基础设施和业务的边界应该在哪里？

阿里巴巴认为边界是在不断的变化过程中，真正的判断标准是业务关注的边界而非架构边界，基础设施应无须业务持续关注和维护。例如，使用了容器服务，是否能让业务无须关注底层资源？也未必，取决于资源的弹性能力是否有充分的支持（否则业务仍需时刻关注流量和资源压力），也取决于可观测性（否则问题的排查仍需关注底层环境）的能力。因此，能够让业务无须持续关注的基础设施本身是一次重要技术演进。

无服务器化的基础设施，具有以下三个特点：

阿里核心系统的云原生化演进

阿里巴巴集团的核心系统的云原生架构演进，将继续朝着基础设施解耦，业务研发运维效率提升，成本下降的整体目标推进。具体来说，围绕几个重点的方向工作正在展开：

节点托管的 K8s 服务

实现节点运行环境全托管的标准 K8s 基础设施，实现资源和节点运行环境解耦：通过全托管的节点计算资源，业务无须管理服务器降低运维成本。今年双 11 集团实现了上海单元的 ASI 升级，带来发布扩容效率提升、运行时更稳定容器自愈率提升的效果。未来一年将实现核心系统整体 ASI 化。

Service Mesh 化

实现网络、流量管理配置下沉基础设施，与应用充分解耦。Mesh 化带来的价值：

软件基础设施和业务解耦，各自独立演进；全链路精准流量控制和资源动态隔离；提供对应用透明的云安全特性（安全特性解耦）。

应用和基础设施全面解耦

阿里巴巴集团核心系统通过云原生化，实现应用基础设施全面解耦，将有效解决此前存在的运维、研发效率及可迁移性、稳定性风险，这也是云原生带来的技术赋能。像下图所表示的，应用的关注对象，从繁杂的基础设施耦合组件，到只需要关于业务逻辑本身。

应用交付的标准化：OAM

今天应用的交付仍然面临挑战：目前云上进行应用管理，需要面对的是差异性的云基础设施能力和多样化的运行环境, 需要分别对接和管理，如 SLB、日志、网络环境、后端依赖等。

今年，阿里云和微软云 Azure 联合发布了一个全新的项目，叫做 Open Application Model OAM：开放应用模型。是业界第一个云原生应用标准定义与架构模型。在这个模型下，应用的开发人员、运维人员和支持 OAM 模型的平台层，就可以通过一个标准的 OAM 应用描述来进行协作。

通过上云，最大化的使阿里巴巴的业务使用云的技术，通过技术架构的演进使业务更好的聚焦于自身的发展而无须关于通用底层技术，使业务研发效率提升，迭代速度更快是技术人的真正目标。正如阿里巴巴集团上云项目的代号所说的，“云创未来”，通过技术创造新的价值和机会，通过技术创新带来更好的未来。

嘉宾介绍

张瓅玶，花名谷朴，阿里云原生应用平台集群管理团队负责人，研究员。2017 年加入阿里巴巴。之前在 Google 的基础设施事业群的集群管理部门工作了 5 年多，并领导了资源管理和优化团队，负责 Borg 以及基础存储资源的优化，负责了 FlexBorg, Autoscaling 等多个产品。加入 Google 前在加州大学伯克利分校从事智能系统的研究工作。本科和博士毕业于清华大学。