「云原生上云」后的聚石塔是如何应对 双11 下大规模应用挑战的

来源|阿里巴巴云原生公众号

主笔 | 在德（阿里巴巴技术专家）、佳旭（阿里巴巴技术专家）
联合做者 | 杭羽、照前、岭峰、大猿

云原生被认为是云计算的重要发展趋势，而且已经成为数字新基建必不可少的一个组成部分。每一年的阿里巴巴 双11 都是考验各类前沿技术的最佳“实战场”，而今年云原生技术在 双11 中的大规模应用，充分证实了云原生技术的动力与前景。

本文会系统讲解聚石塔在 2019 年 7 月份以阿里云容器服务为基础设施，进行云原生实践的探索和经验、带来的价值与改变，及其在 双11 中的应用，但愿对云原生化树立能够借鉴使用的案例和样板。

聚石塔业务背景与介绍

聚石塔最先上线于 2012 年，是阿里集团为应对电商管理和信息化挑战，帮助商家快速解决信息化建设与管理的瓶颈打造的一款开放电商云工做平台。它的价值在于汇聚了整个阿里系的各方资源优点，包括阿里集团下各个子公司的平台资源，如淘宝、天猫、阿里云等，经过资源共享与数据互通来创造无限的商业价值。

依托于聚石塔，各类业务类型（如 ERP、CRM、WMS 等业务）的服务商为淘宝、天猫等淘系的商家提供服务，服务商须要遵循聚石塔平台的发布规则、数据安全、稳定性建设等要求。这种关系决定了聚石塔平台的技术和架构，更直接决定服务商的技术演进方向和先进性。

聚石塔业务痛点

聚石塔承接的业务大类能够分为两个部分：

• 传统电商链路中，订单服务链路上的系统：好比 ERP 系统，CRM 系统，WMS 系统。
• 电商行业中直接面向客户的小程序场景，好比手淘与千牛客户端的小程序业务。

综合聚石塔的的业务类型，存在以下的业务痛点：

1. 标准化和稳定性问题

对于订单服务链路的系统而言，稳定性永远是最前面的“1”，一个系统抖动可能就会致使订单履约链路中断甚至形成资损以及客诉。稳定性和标准化是不分家的，相信你们对此对有强烈的感觉。而此类系统的开发语言不统一，有 Java、PHP、.Net 等；技术栈复杂，涉及 Windows 系统、Linux 系统、单体应用、分布式应用，可谓五花八门。所以须要一套跨语言、跨平台的通用 PaaS 平台来解决应用的标准化、运维的标准化问题，并提供通用的链路问题观测手段，来帮助服务商和平台规范发布运维操做，发现链路问题，消除稳定性隐患。

2. 突发流量下的弹性问题

对于应用小程序的业务系统而言，最大的挑战就是须要应对突发流量以及流量的不肯定性。尤为在 双11 期间，手淘端各种小程序插件会面临比平时多十倍甚至百倍的流量。面对这种不肯定性的流量洪峰，聚石塔须要一套能够实现流量预估、流量观测、流量控制以及标准应用快速扩缩容的 PaaS 平台。对于订单服务链路的系统而言，弹性能力也是关键点，在原来的架构下扩容须要经历建立虚拟机资源、部署并配置应用等诸多环节，服务商广泛感受流程长、效率低。以上咱们都总结为弹性能力的挑战。

3. 效率和成本的问题

聚石塔在云原生以前的应用部署基本都是基于 VM 直接部署进程，这种方式缺少进程间的资源隔离。同时当 ECS 数量变多，资源的统一管理就变得很是复杂，很容易形成资源争抢致使应用稳定性问题以及资源浪费致使的多余成本开销。同时，在传统的 VM 部署模式中，应用的扩缩容不只仅须要处理应用的代码包启动，还须要处理应用的端口冲突，应用所关联的存储资源分配，应用流量在 SLB 的挂载和摘除，应用配置的分发以及持久化，整个部署过程会变得很是耗时且容易出错。

聚石塔云原生落地方案

针对上述的业务痛点，聚石塔开始探索技术演进方向以及系统性的解决方案，以便为淘系服务商带来服务上质的提高。云原生带来的技术红利，好比应用环境标准化、DevOps 思想、弹性伸缩、跨语言的服务化能力以及运维自动化等，都不只能够帮助聚石塔的服务商解决现存架构中的稳定性和成本问题，同时也能够帮助咱们引导服务商实现技术架构的升级。

所以，聚石塔进行了从新定位，主动拥抱云原生。总体来看，目前的聚石塔云原生技术底座基于阿里云容器服务，平台目标是赋能服务商应用架构的稳定性升级，打造基于云原生的、面向业务连接的 DevOps PaaS 平台。

那么，为何聚石塔会选择阿里云容器服务做为云原生基础设施呢？

阿里云容器服务 ACK（Alibaba Cloud Container Service for Kubernetes）是全球首批经过 Kubernetes 一致性认证的服务平台，提供高性能的容器应用管理服务，支持企业级 Kubernetes 容器化应用的生命周期管理。做为国内云计算容器平台的领军者，从 2015 年上线后，一路伴随并支撑 双11 发展。

ACK 在阿里巴巴集团内做为核心的容器化基础设施，有丰富的应用场景和经验积累，包括电商、实时音视频、数据库、消息中间件、人工智能等场景，支撑普遍的内外部客户参加 双11 活动；同时，容器服务将阿里巴巴内部各类大规模场景的经验和能力融入产品，向公有云客户开放，提高了更加丰富的功能和更加突出的稳定性，容器服务连续多年保持国内容器市场份额第一。

ACK 在今年 双11 期间稳如磐石，深度参与了 双11 众多领域的支撑：在阿里巴巴集团内部支撑电商后台系统 ASI，在零售云支撑聚石塔，在物流云支撑菜鸟 CPAAS，在中间件云原生支撑 MSE，在边缘云支持支撑 CDN 和边缘计算，并首度支持了数据库云原生化和钉钉音视频云原生化。

在过去的一年，ACK 进行了积极的技术升级，升级红利直接运用到了 双11 中，进一步提高了 ACK 的技术竞争力和稳定性，升级包括：高性能云原生容器网络 Terway 相比于社区社区提高 30%，高性能存储 CSI 引入 BDF 等的支持支撑数据库 5K 台神龙主机对数十 PB 数据实现高效卷管理，极致弹性 ASK，Windows 容器等首次在 双11 活动中参战并应用等等。规模化调度方面，ACK 高效稳定的管理了国内最大规模的数万个容器集群，是国内首个完成信通院大规模认证（1 万节点、1 百万 Pod）的厂商。规模化管理的技术和经验在 双11 中支撑了全网客户集群 APIServer 数十万的峰值 QPS。

所以，聚石塔选择 ACK 容器服务，不管是从技术角度，仍是业务角度，是很是合理的，双方的合做也是强强联合、相互赋能、共同成长。

下面内容会讲到聚石塔如何使用云原生中的技术能力来解决实际的业务痛点和问题。

1. 应用和发布标准化

聚石塔上汇集了上万的开发者，可是不论规模仍是技术能力都良莠不齐。所以，聚石塔亟需为用户提供一套能够屏蔽 Kubernetes 复杂性的、易用、灵活高效的发布系统，进而下降用户使用 Kubernetes 的门槛，帮助用户享用云原生的技术红利，同时知足做为管控方对于稳定性的要求。为了应对各类不一样业务形态的差别化，聚石塔经过标准化来解决，设计了一套通用的应用模型以及对应的发布规范。

1）应用模型

Kubernetes 的一个重要思想就是面向应用的 DevOps，聚石塔 DevOps 平台一开始就是以应用为中心的 Paas 平台，在应用模型的设计上，总体的设计原则是让开发者人员关注应用自己，让运维人员关注基础设施运维，从而让应用管理和交付变得更轻松和可控。

同时，为了知足客户需求的多样性，好比对于同一个应用，SaaS 服务商为不一样商家提供不一样规模的应用实例数量，或部署有差别性的代码，聚石塔在应用下支持了多环境，并支持对测试和正式环境的隔离。

2）发布

稳定性的风险很大程度上来源于变动，Kubernetes 自带的滚动发布，虽然标准化了发布环节，但在发布期间没法暂停，即便服务起来了，可能功能和业务存在问题，最终也会随着滚动不断扩大影响面；对此，聚石塔设计了支持暂停的分批发布，经过提早批的“金丝雀”验证，从而提高系统的稳定性。

以一个“无状态”的应用为例，主要实现原理是，经过控制两个版本的 Deployment 的滚动，来作到可暂停和金丝雀验证。

同时，相对于其余 Paas 平台，聚石塔须要支撑更多的客户应用场景，还支持有状态应用（像 Zookeeper）以及守护进程应用（好比日志采集）的分批发布，以知足不一样客户基于成本和防锁定层面的需求。

而对于有状态应用，主要原理则是经过控制 Kubernetes StatefulSet 的 Partition 分区来作到分批和暂停。

另外，对于守护进程应用，则是经过对 DaemonSet 进行 Label 的调度来实现：

从而作到不一样类型的应用，获得统一的操做体感和变动稳定性保障。

2. 弹性：ACK/ASK + HPA

随着集群规模的增大，资源成本的消耗愈加明显，尤为对于流量波动较大的场景（例如电商场景），问题更加突出。用户不可能一直把集群资源保持在高水位上，大多数状况下用户都会把集群资源维持在足以应对平常流量的规模，并稍微冗余一部分资源，在流量高峰在来临前进行集群资源的扩容。

对于 Kubernetes 集群来讲，启动一个 Pod 是很快的，可是对于上述场景，启动 Pod 前须要提早扩容 ECS，使之加入集群后，才能进行扩容，而扩容 ECS 则须要数分钟的时间。

以上的弹性能力比较弱，操做繁琐，耗时过长，没法及时响应流量变化，而且依然会存在不少的资源浪费，消耗成本。

1）ACK/ASK 与 ECI

阿里云弹性容器实例（Elastic Container Instance），旨在用户无需管理底层服务器，也无需关心运行过程当中的容量规划，只须要提供打包好的 Docker 镜像，便可运行容器，并仅为容器实际运行消耗的资源付费。ECI 是 ACK 底层的一种资源形态，一个 ECI 能够看作一个 Pod，无需提早扩容 ECS，即可直接启动。

ECI 的价格与同等规格按量付费的 ECS 价格相近，且为按秒付费，ECS 为小时级别。若是用户仅须要使用 10 分钟，理论上 ECI 的成本是使用 ECS 的 1/6。

以下图所示，Kubernetes 集群经过 Virtual Node 使用 ECI，该技术来源于 Kubernetes 社区的 Virtual Kubelet 技术，无需提早规划节点容量，不占用已购买的 ECS 资源。

2）聚石塔结合 ECI 与 HPA

为了带给客户更好的体验，聚石塔基于阿里云 ACK/ASK，结合底层的 ECI 资源，以及原生 HPA 能力，为客户带来了更加灵活优质的弹性能力。

经过使用污点来控制一个应用的某一个环境是否但是使用 ECI，而且会优先使用集群中 ECS 资源，资源不足时才会使用 ECI，从而为用户解决额外成本。

同时聚石塔提供了标准的 HPA 能力，以及 cronhpa 能力，帮助用户实现根据指标的自动伸缩（例如根据 CPU 的使用状况自动伸缩 Pod 数量），以及定时伸缩的能力。

而且经过二者的结合，在流量动态变化的过程当中，无需手动购买 ECS，以及手动扩容 Pod，实现 0 运维成本。

以上能力在今年 618 前开始小范围推广，完美经过了 618 以及 双11 的考验，用户在 双11 期间单个应用使用 ECI 占比最高达到 90%，为用户节约了一半的计算成本。在 双11 期间 ECI 在电商业务场景下总体运行稳定，平均弹升时间在 15s 之内，相比 ECS 扩容至少须要 10 分钟，大大减小了扩容的时间成本，保证业务应对峰值流量的稳定性。

3. 应用监控

在享受 Kubernetes 云原生技术带来快速发布、弹性伸缩等便利的同时，如何作到可监控可运维也是聚石塔的核心挑战。一个合格的监控系统须要具体准确性、实时性、可用性，提供分析和解决问题的洞察力。传统的监控方案，大部分是自顶向下的，配置一个监控的任务、采集端点，应用的生命周期与监控任务生命周期一致，采集目标也是固定的，不管应用如何重启、变化，对于采集任务而言只要采集端点没有变化，那么任何的变化都是生命周期中的正常现象。与传统应用相比，基于 Kubernetes 的云原生应用容器实例是动态调度的、生命周期短，容器上层更是难以监控的如 Deployment、负载均衡 Service 等抽象，此外，还须要底层 ECS 计算资源、实例生命周期、Kubernetes 集群自身以及集群核心组件的各个维度的监控。基于上述考虑，聚石塔充分打通阿里云云原生监控中间件产品，为聚石塔云应用提供了分层一体化监控解决方案。

以事件监控为例，介绍下阿里云事件中心如何在聚石塔 PaaS 平台落地。

事件中心

聚石塔借助阿里云日志服务提供的集群事件采集、索引、分析、告警等能力，将集群和云应用上的各类事件进行监控和告警。事件的范围涵盖全部 Kubernetes 原生 event、集群组件 event 以及其余各类定制的检查。一般比较关心的是会影响云应用正常运行的一些异常状况，好比 Node 节点不可用、资源不足、OOM 等，好比 Pod 实例容器重启、驱逐、健康检查失败、启动失败等。PaaS 平台上云应用实践过程。

• 用户为集群一键安装 NPD 组件，为集群和应用分别配置告警规则，设置关注的事件类型和通知方式便可。
• 集群上全部事件自动采集到 SLS 日志服务，日志服务上的告警规则由咱们根据事件类型和用途自动配置。
• 日志服务告警回调以后，由咱们统一分析处理后进行消息推送。

事件监控和告警功能，不只能在平常帮助用户排查和定位自身应用问题，也为平台对各个应用的运行状况有较好的了解，从而制定个性化的优化方案以及大促保障方案。此外，对于集群底层的组件，也能够经过配置相应的规则进行告警通知，这次 双11 大促，聚石塔为核心集群自动配置了集群 DNS 组件的告警，以便及时扩容或者切换更高可用的 DNS 方案，从而确保业务稳定。

4. DNS 生产环境优化实践

因为聚石塔的用户大可能是电商或小程序的场景，流量波动明显，而且开发语言多样化，有些语言没有很好的链接池，致使每一次请求都须要进行一次 DNS 解析。Kubernets 默认的 CoreDNS 在高并发时会遇到性能瓶颈，部分用户在平常活动中，已经遇到了 DNS 性能的问题，更不要说 双11 期间，所以聚石塔对 DNS 的性能作了深刻的优化，确保 双11 的稳定性。

1）Node Local DNS

默认的 CoreDNS 方式是采用的 Deployment 方式部署的无状态服务，集群中的 Pod，经过 service 对其进行访问。经过上述流程能够看到，DNS 解析须要跨节点请求，性能不是很高，在高并发的场景下，容易达到瓶颈。

为了进一步提升性能，阿里云提供了 ack-node-local-dns。原理以下，经过 DaemonSet 的方式，将 DNS 解析的服务在每一个节点上启动一个实例，同时设置相应的 转发规则，将 Pod 发出的 DNS 的请求转发到各自节点上对应的 DNS 解析服务，从而避免了跨节点的访问，很大程度上提升了性能。

聚石塔对该插件进行了相应封装，可使用户无感知的在两种方式间进行切换。

2）Sidecar DNS

对于 ECI 的场景，因为不存在真实的宿主机，所以没法采用上述 Node Local DNS 的方案提升 DNS 性能，同时各个节点上的服务数量不一样，而且不一样应用对的 dns 解析并发量的不一样，在极端的场景下可能会出现 DNS 解析并发量分布不均，从而致使部分节点上 DNS 解析出现问题。

基于以上场景，聚石塔结合 Kubernetes 提供的 sidecar 能力，提供了 sidecar dns。原理以下图所示。

经过在 Pod 容器组中加入 DNS 解析服务容器。实现容器组中，其余容器全部的 DNS 解析请求均经过 sidecar dns 获取。sidecar dns 能够看作是业务容器的缓存，只为自身所在的 Pod 提供服务，不会存在负载分配不均的问题，而且能够为 ECI 提供相应的 dns 解决方案。

5. Windows 场景落地

全球范围内来看，Windows 的市场份额还不容小觑，在 StackOverflow 2020 最新的开发者调研中，在最受欢迎的的框架、开发包和工具中，.Net 的占比超过了 35%；在最受欢迎的编程语言中，C# 虽然有所下滑，仍保持在 30% 以上。随着云原生的接受度愈来愈高，愈来愈多的传统行业也对容器等云原生技术的呼声愈来愈高，迫切须要更好的支持。

1）限制

Kubernetes 最早是在 1.14 版本 GA 实现了 Windows Server 2019 上进程容器的调度，随着后面的不断迭代，Windows 容器在调度、安全、网络、存储和镜像管理等模块上都有了很大的进步，正在慢慢对齐 Linux 容器的功能并尽最大努力保持对异构容器管理的统一性。但咱们仍是能看到 Windows 容器有不少的限制，这种限制更多的是来自于操做系统层面的。

• 隔离不完全

目前 Windows 容器的实现模式分为："进程容器"和"Hyper-V 容器"。"进程容器"是经过任务名管理来模拟资源隔离的，因此这种隔离是不完全的，最多见的限制就是无法 OOM kill。而"Hyper-V 容器"是经过内核隔离技术来实现，所以这种隔离是最完全的。

Kubernetes 默认支持的是"进程容器"，其实说"只支持"都不为过，为何呢？由于目前能支持"Hyper-V 容器"的运行时只有 Dokcer EE，而又受限于其实现，"Hyper-V 容器"不能支持 Multiple Container one Pod 的场景，再加上微软把节点上能够跑"Hyper-V 容器"的数目也 License 化，这就极大的阻碍了"Hyper-V 容器"Kubernetes 化的进程。

• 升级难平滑

为了提升迭代效率，加速功能沉淀，微软在 2017 年推出一种新的系统发布里程："半年通道版"（Semi-Annual Channel）。相比于"长通道版"（Long-Term Servicing Channel），"半年通道版"是按照半年一次来进行 release 的，所 release 的内核是彻底兼容当前所支持的 "长通道版"的操做系统。比方说，Windows Server 1809 SAC，Windows Server 1903 SAC ，Windows Server 1909 SAC 等都属于 Windows Server 2019 LTSC。

比起"长通道版"，显然"半年通道版"来得更加敏捷高效，可是转而来的是更复杂的升级管理。

• 严格内核版本要求的"进程容器"：因为进程容器是经过任务名模拟的，这就致使了容器的 base 镜像内核版本必须等于节点内核版本。换句话说，1903 SAC 的容器是无法跑在 1809 SAC 的节点上，反之亦然。
• 有限兼容的"Hyper-V 容器"："Hyper-V 容器"的向后兼容是有限制的。比方说，在 2004 SAC 的容器上，经过 Hyper-V 技术建立的容器，只能兼容 2014 SAC，1909 SAC 和 1903 SAC，而没法运行 1809 SAC。
• 安全管理困境：当碰到安全补丁的时候，问题会变得更麻烦，除了节点要打安全补丁之外，容器也要从新re-package。详情能够参看：https://support.microsoft.com/en-us/help/4542617/you-might-encounter-issues-when-using-windows-server-containers-with-t。

• 文件难管理

目前的 Windows 容器的文件管理比较 tricky。因为 Docker EE 只实现了主机目录级别的挂载，这就致使 Windows 要读写某个文件的时候，必须把其整个目录挂载进来。于此同时，因为主机的 ACL 管理不能被投影到容器内，这就致使了 Windows 容器对文件的权限修改是不能被主机所接收的。

在 Secret 资源的管理上，在 Linux 上请求挂载的 Secret 资源会被暂存到内存里面，但因为 Windows 不支持挂载内存目录，因此 Secret 资源的内容会被放置在节点上。这就须要一些额外的机制来对 Secret 资源作控制。

2）展望

不过随着这几年的努力，咱们正在迎来一个更加稳定和成熟的 Kubernetes Windows 解决方案。

• 在运行层面，ContainerD 会加速替代 Docker EE。目前社区在 ContainerD 上集成了 HCS v2，实现了对单独文件的挂载和容器优雅退出的管理，在 v1.20 上将会实现对 GPU 和 GMSA 的支持。另外，咱们也能够看到实现"Hyper-V 容器"和"特权容器"也已位列 roadmap。
• 在镜像层面，微软在努力的削薄基础镜像层，从 1809 SAC 到 2004 SAC，整个 Windows Server Core 减小了将近一半的大小，可是功能却愈来愈丰富，这是让人很是惊喜的。这也为后期的"Hyper-V 容器"打下来良好的基础。
• 在功能层面，随着 privileged proxy 模式的兴起，不少以前无法容器化运行的方案都找到了合适的解决方式。比方说，CSI Windows 的实现方案，就是借力于 https://github.com/kubernetes-csi/csi-proxy 的实现。
• 在运维层面，借助于 Kubernetes 的能力，彻底能够打造一套 CICD 流来解决掉升级平滑的问题。

聚石塔上的传统电商链路中，订单类的各种 ERP、CRM、WMS 等系统，使用 Windows 技术栈开发的占了一半以上。如何帮助 Windows 场景下的系统进行云原生升级改造，对咱们也是一个全新的挑战。半年来，聚石与阿里云 ACK 技术团队一块儿作了许多尝试，使用阿里云 ACK 集群 + Windows 节点池做为底层基础设施，聚石塔 PaaS 已经可以提供完整的发布部署、负载均衡、基础监控、扩缩容等功能。在今年的 双11 大促中，已经有很多客户的系统运行在 Windows 容器之上，平稳渡过 双11 的业务高峰。

固然，Windows 场景下还有其余一些特性暂不支持，好比 NAS 共享存储、日志采集、弹性伸缩、事件监控等，双11 以后，聚石塔与与阿里云 ACK 会继续一块儿努力，为 Windows 容器的成熟和市场化贡献更大的技术和业务价值。

云原生带来的业务和技术价值

在正在进行中的 2020 年 双11 大促中，聚石塔云应用 PaaS 已经落地开花，聚石塔的核心服务商的核心系统也基本完成了云原生化的改造。

在 双11 第一波高峰中，构建在阿里云 ACK 之上的聚石塔云原生规模达到了上万核 CPU，上千个集群，承载 2 万个 Pod。基于 Kubernetes，聚石塔 PaaS 封装的应用与运行环境的标准化，发布部署以及流量变动流程标准化已经成为聚石塔服务商平常软件交付流程中必不可少的一部分，经过这些努力聚石塔最大限度的减小了 双11 期间没必要要的应用变动，将聚石塔的变动数量减小为平常的十分之一，保证线上系统稳定性；同时咱们推进聚石塔 PaaS 上的核心应用完成了基于阈值（CPU，内存，load）以及基于集群事件（好比 Pod 驱逐，节点不可用）的监控告警，实现了线上问题先于客户发现，及时解决止损；对于小程序的突发流量应用场景，聚石塔在普通 Kubernetes 集群内引入了 vnode 和 ECI 的技术，保证集群资源不足的状况下，能够实现 Pod 的秒级快速应急弹缩，应对突发的流量洪峰。

云原生带来的价值不止于此，基于聚石塔的用户反馈，云应用 PaaS 广泛给开发者带来了 30% 以上的研发效能提高，应用的扩缩容甚至实现了小时级到秒级的时间缩短；同时基于容器的运行环境以及计算资源标准化抽象，给大多数用户带来了 30% 以上的计算资源成本节约。基于云原生的架构与运维规范也推进了服务商自身的软件架构升级，好比从单体应用向分布式应用的升级，从垂直扩缩的有状态应用向可横向扩缩的无状态应用的升级。

云原生在电商垂直业务下的实践才刚刚起航，后续聚石塔还将持续在云原生技术领域深耕，在应用运维标准化 OAM，应用链路的可观测性，基于 Mesh 的应用流量监测和控制，基于业务指标的弹性伸缩，分布式应用压测与容灾等领域继续探索，将云原生的技术价值赋能给客户和业务，同时将电商垂直领域的云原生技术实践反哺云原生社区。