起源 |阿里巴巴云原生公众号
主笔 | 在德（阿里巴巴技术专家）、佳旭（阿里巴巴技术专家）
联结作者 | 杭羽、照前、岭峰、大猿
云原生被认为是云计算的重要发展趋势，并且曾经成为数字新基建必不可少的一个组成部分。每年的阿里巴巴 双 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 的利用流量监测和管制，基于业务指标的弹性伸缩，分布式应用压测与容灾等畛域持续摸索，将云原生的技术价值赋能给客户和业务，同时将电商垂直畛域的云原生技术实际反哺云原生社区。