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

以下内容根据演讲视频以及PPT整理而成。
观看回放 https://yq.aliyun.com/live/2783
本次分享主要围绕以下三个方面：
一、核心系统上云演进
二、上云挑战及变化
三、未来演进

一、核心系统上云演进

如下图左侧，最初阿里巴巴电商核心系统是不具备容灾能力的。随着核心系统的演进，慢慢具备了同城容灾能力，到今天阿里巴巴核心系统已经具备多单元，异地多活结构，可以实现灵活切流，具备极致高可用和容灾能力。同时在国内多个地域进行了部署，包括华东，华南及华北，而且具备国际化部署能力。

第一阶段：自建基础设施

在核心系统上云之前，阿里巴巴一般是自建基础设施，到2015年阿里巴巴核心系统已经具备中心同城容灾，多单元异地多活的能力。如果把阿里巴巴核心系统简化，如下图蓝色部分，运营商CDN是整个核心系统的入口，进来后有多地多个区域有多个机房，通过统一接入负载均衡，进入服务注册中心，通过中间件处理消息及事务，进入交易导购的应用，再通过缓存访问数据库。

第二阶段：核心系统双11弹性上云

从2015年到2018年内，阿里巴巴在双11期间的采取弹性上云策略。双11本身对阿里巴巴的业务系统是一个非常大的挑战，双11期间业务的峰值会达到平常峰值的几十倍。但是以业务资源成本来看，显然无法分配几十倍的业务资源成本支持双11当天的流量，从效率层面也是不现实的。因此在2015-2018年间，通过弹性上云策略将交易导购的应用短期扩容到阿里云ECS上，从而支持大促成本降低的目标。

第三阶段：核心系统全面上云

在2019年年初，阿里巴巴CTO，行颠提出在2019年将阿里巴巴核心系统全面上云的目标。实际上，在2019年双11前，阿里巴巴核心系统已经全面上云了。由于在核心系统的架构上具备同城容灾和多单元化部署的能力，从而给核心系统上云带来了极大的便利。以中心为例，首先在云上申请神龙ECS资源，通过中心的同城容灾，将中心一个机房的应用及统一接入层实现上云，在过程中通过服务注册中心，消息和中间件统一机房的设置，实现迁移的过程中业务无中断。

在云上部署并完成测试后，可以将流量迁移到云上机房。因为是同城容灾的架构，故可以将云下机房的流量的切断，切到云上机房。同时可以对中心其它机房进行相同的操作，完成流量迁移的过程。

同时单元化的部分也经过了类似的过程，整个实施过程投入了大半年的时间。核心系统全面上云是一次平台重构（replatforming），将基础平台都迁移到云上，从原来基于自建的策略改为现在所有应用，数据库等都基于云的核心系统。

为什么阿里要核心系统上云？
随着公有云技术的演进，公有云上很多产品的能力相比于传统基于自建的系统的能力有了显著的提升，比如云上神龙服务器，云上核心数据库，既吸收了阿里巴巴内部技术的创新，同时在对外服务客户的过程中，也在不断积累独特的创新能力。云上产品可以更好的支持阿里巴巴的业务。反过来，阿里巴巴内部的系统也具备一些独特的场景，如平时比较复杂的电商场景，可以对云上产品有更好的打磨效果。阿里系统通过核心系统的上云，不断的打磨云产品，从而使得云产品能力得到不断的提升。其次，通过核心系统的上云，可以让性能，成本及稳定性收益形成良性闭环。

二、上云挑战和变化

上云挑战

众所周知，阿里巴巴双11是对业务来说是一个独一无二的挑战。其中包括对容器规模的挑战，在大促期间，集群规模超过百万，单集群规模达到10000以上。2019年双11的数据库峰值能力达到54.5万笔订单每秒，数据库TPS达到8700万，实时计算Blink处理峰值达到25亿消息每秒，消息系统峰值达到1.5亿消息每秒。这些数值是对业务的极致性能和极致稳定性的要求，过去是依靠阿里巴巴集团*技术体系多年的打磨，那么如果上云，云产品是否能够支撑这样的极致要求同时提供红利？

计算存储

在上云之前，阿里巴巴计算是依靠传统的物理机+容器的架构。传统的架构面临几种架构缺陷，一方面是面临资源争抢的挑战，且隔离性较弱。同时会占用宿主机的资源，对系统算力造成损失，成本变高。另外，所需的IO引擎通过纯软件的方式实现，会遇到较大的性能瓶颈，尤其在双11期间，IO引起的性能问题一直是较大的挑战。其次，由于应用网络存储和设备共享导致容器相互影响，性能抖动等问题也是目前的主要挑战。

在2019年完成迁云之后，计算层使用神龙+容器服务作为最佳计算基础设施。神龙的特点是通过对网络和存储硬件基础的虚拟化，将原来宿主机的开销卸载到单独的子系统上，虚拟机的卸载使得物理机的资源都为业务负载所用。同时让物理机上的容器相互之间不会因为共享IO通道产生干扰，对长尾延迟及资源的生长情况有显著的改善。在2019年双11期间，在高负载压力下的某电商应用QPS提升了30%，同时资源的利用率也有显著的提升，CPU利用率提升了80%，降低了延迟时长。

下图对比了物理机部署和神龙部署的延迟情况，可以发现当业务负载逐渐提升时，神龙延迟的下降是非常明显的，而传统的物理机由于资源的争抢会导致延迟时长快速上升。

云化存储

云化存储也给阿里巴巴核心系统上云的演进带来了积极的影响。一方面，云上的高密度，弹性能力，长尾延迟的优化，对于应用的性能和稳定性带来了大幅度的提升。

另一方面，在云上实现了存储计算的分离，不需要再去管理，规划和存储，从而给整体应用架构带来了大幅度的简化。下图左侧展示了单体应用的架构，包含应用、本地文件系统、本地磁盘。迁移到云上后采用云化的存储实现存储计算分离，架构变成了类似如下图右侧，业务只需关注应用，通过存储虚拟化访问云存储。在存储计算分离后，阿里巴巴硬件采购更灵活，只需要做计算量的采购，不需要考虑磁盘容量问题。在应用层面，所关心的维度也变少了，目前只需要关心CPU和内存水位，提高了资源分配成功率和资源利用率。最后，存储的分离使得应用的迁移效率更高，提升了可移性，无须迁移本地数据。

网络性能

在上云之前，阿里巴巴的架构是企业内部网的架构。由于上云的迁移是持续的过程，所以需要构建高速的混合云网络。云上云下对传流量较大，因此在云上采用了云专线的方式实现云上云下的高速互通，同时具备城域网架构支持良好的可扩展性。但同时也面临跨安全域full-mesh互通的问题，阿里通过对整个安全域和安全组的设置，进行了很好的解决。整个过程中，云上的xGW网关和软硬件结合的交换机能力也使得上云之后的网络性能有了大幅度的提升。

资源管理和规划

在上云之后，以双11和618大促为例，在3年前，阿里巴巴需要为大促峰值做单独的资源准备，而且这些资源很难立刻被完全释放掉，一般消化时长需要按年进行统计。，供应链及企业的弹性来说是一个较大的痛点。阿里巴巴也做了很多容器化，统一调度，混部等方案，这些本质上属于云化的过程。当真正上云后，云会提供一个产品化的解决方案。当资源池规模呈指数级别增长时，资源可以即买即用，用户不用关注架构优化问题，也不需要关心供应链问题，弹性资源池能力有了大幅度提升。

上云之前的资源规划如下图，业务实际需求是一个曲线，当有大促活动时，需求会极速增长。但交付时是按照粗颗粒度进行物理机的采购，而采购往往是批量采购，并且需要提前采购物理机。下图绿色线条下的面积是实际机器库存。上云之后即使还是按照绿色线条做容量规划，并且上交阿里云，但实际的规划可以很好的贴近业务需求，少批量多次的弹性采购，从而大幅度减少冗余资源。下图右侧绿色和橙色间的面积是优化节约的资源。

混部方案变化

下图展示了在上云之前在阿里巴巴集团内部，将大数据和电商应用通过混合部署，从而节省成本的方案。但受限于机房资源的规划，会产生很多空闲资源或不具备条件的资源。上云之后，可以使用云提供的产品化方案，充分使用资源，通过相对简单的云化技术方案，达到业务无降级的效果。

三、未来演进

解决问题
上云已成为趋势，但核心系统上云对大企业来说还是会面临很多挑战。阿里巴巴在2019年完成了核心系统的上云，相信对其它企业也可以慢慢克服这些挑战，并且完成上云。但核心系统上云只是下一个开始，并不是终态。阿里巴巴技术团队下一阶段将主要解决以下问题，首先是持续提升研发运维效率，让业务更快迭代，这是每一个公司技术团队最核心的使命。同时需要不断优化，从而减低资源成本。最后，保证安全生产和稳定性。

新架构演进

如果将上云之前的阶段分为两大阶段，第一个阶段是弹性使用云资源，在2018-2019年间，阿里巴巴在双11期间使用了云资源降低成本。第二阶段是2019年开始核心系统上云，真正以云为平台。下一阶段将是云原生化，那么什么是云原生？

云原生

从价值的角度来说，云原生化是企业应用架构的一次升级，云原生是构建和运行可弹性扩展、容错性好、易于管理的系统的最佳实践。一方面，云原生化通过容器和资源的编排，带来效率和资源利用率的提升。另一方面，通过微服务化分布式系统的可弹性，带来整个应用扩展与可靠性的提升。此外，云原生化的开放标准带来了无供应商锁定的特点。同时持续交付带来了创新迭代速度的提升。这些价值是阿里巴巴非常看重的，同时也希望可以获取到这些红利。

云原生上云之痛

从上云视角看，云原生（Cloud native）化是最大化使用云的能力，以开放标准重构阿里巴巴技术体系和架构，让企业聚焦于业务的实践。但同时因为云原生上云是对整体体系的挑战，因此会面临以下几种痛点。首先，传统面向富容器、定制化的运维和监控体系迁移到标准化体系，应用架构向微服务化转变，此类运维体系升级对企业来说也是不小的挑战。随着容器化的普遍深入，给企业提供标准化的运维体系，可以极大的降低云原生上云成本。其次，在更深入使用云产品过程中，应用所依赖的中间件和后端服务也要迁移，同时发生了应用架构的变化，此时云上所提供的很多标准的基础设施可以极大的降低成本，技术人员可以更多的聚焦在自身业务技术及能力，无需在基础设施和产品上投入大量人力。第三，在升级过程中会不可避免的面临组织挑战，如果之前企业有in-house自建和维护团队，是否可让他们参与业务系统的开发，同时可以实现人员效率的提升。

应用与基础设施全面解耦

将云原生之前的一个典型的应用架构拆分后，如下图，带有富容器模式的特点，与基础设施有深度的耦合，包括监控Agent、日志Agent、系统进程、命令通道、中间件、本地缓存，最上面才是业务猪进程。此类架构会使得应用与基础设施间存在强耦合，从而使得配置管理复杂，发布升级慢，可迁移性不高。在上云时，架构本身的运维及研发演进效率也会受到影响。

因此针对这种高耦合性，需要全面的对应用和基础设施进行解耦。即通过应用架构的演进，将业务应用与运维，可观测性，中间件等逐渐分离，也称为轻量化容器和不可变基础设施的分离。同时，过去的复杂度来自流量的复杂度和网络的管理和配置，通过服务网格化的演进，可以很好的将业务进程与基础设施的网络的进程解耦开来。通过这些演进可以使得应用更多的关注自身的逻辑和主容器，让流量、运维和可观测性变成云基础设施的一部分，进而可以使用标准的云产品进行替代。

无服务器化
如果进一步可以让业务的runtime更无服务器化，则业务会变得更轻量，效率也会进一步提升。上云的深入本质上是走向无服务器化，无需管理底层服务器资源，实现从0到无限的资源弹性，按需计费。以上是无服务器化的基础设施可以提供的价值，对应用与运维和研发的效率都有很大的帮助。

云原生上云的价值红利
云原生上云对企业的价值红利，一方面是通过云上的标准产品的标准化、快速演进给企业带来技术红利。云厂商和社区都在大量的投入云原生技术，如阿里巴巴，谷歌，微软都已投入在社区开发标准的云原生技术的建设中，这会给云原生软件生态带来红利，如容器、微服务、K8s、服务网格都是近几年得到了快速的成长。云原生技术领域将成为云厂商竞争和投入的主战场。云传统的优势包括规模、稳定性，成本等，这些已经逐渐发挥到极致。通过容器、微服务云原生技术开始向上接触到了应用负载的感知，持续的创新给研发和运维带来效率上的优势，从而不断的获得客户的认可。在云厂商将云原生技术作为竞争和投入的主战场可以使得云产品逐渐的成熟，为客户带来更大的价值。随着云原生的技术的发展，应用部署逐渐走向云边端一体化，这对企业管理跨环境云边端应用带来了极大的便利。

云技术体系的演进，云原生技术和产品的发展，云产商对云原生的投入，使得阿里巴巴相信云原生上云是阿里巴巴下一步主要的方向。阿里巴巴相信核心系统通过上云的深化，可以获得更大的技术红利，同时获得研发和运维效率的提升。在稳定性和成本优化的基础上，相信云原生也是其它企业未来技术演进道路上值得考虑的一个方向。