「云原生上云」后的聚石塔是如何应对 双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 的应用流量监测和控制，基于业务指标的弹性伸缩，分布式应用压测与容灾等领域继续探索，将云原生的技术价值赋能给客户和业务，同时将电商垂直领域的云原生技术实践反哺云原生社区。