【笔记】不一样的双11 技术，阿里巴巴经济体云原生实践（下）

最新推荐文章于 2022-09-21 18:04:26 发布

azach64

最新推荐文章于 2022-09-21 18:04:26 发布

阅读量625

点赞数

本文链接：https://blog.csdn.net/C_Python_/article/details/104142856

版权

本文详细介绍了阿里巴巴在双11期间的云原生技术实践，包括Serverless如何在不同场景落地，如CSE的Serverless计算平台在毫秒级伸缩和成本优化上的解决方案，以及全链路可观测性、安全容器和云原生安全软件供应链的探讨。文章揭示了面对流量高峰时如何通过技术手段确保稳定性和效率，以及在成本和性能间找到平衡。

摘要由CSDN通过智能技术生成

CSE：Serverless 在阿里巴巴双11 场景的落地

云计算时代，Serverless 作为云原生重要技术组成部分，一开始便承载了太多的使命 —— 承诺了云计算时代最典型并极具挑战的多维度服务指标： 无服务运维、极速弹性伸缩、按量付费等。这些极具挑战并富有吸引力的服务指标带给了行业极大的想象空间，但任何技术红利的普及并不是一蹴而就，或者像宣称的那样美好。Serverless 在阿里巴巴落地的时候，同时面临了两类诉求不同的用户：

第一类是积极拥抱 Serverless 愿意将其代码修改成 FaaS 形态的用户，这类用户以 BFF（Backend For Frontend）层为典型，这类用户的代码天生具备良好的轻量、无状态等特性。
第二类则是存量应用，存量应用作为目前商业系统的核心组成部分，是最需要享受 Serverless 服务红利，但也是最难享受到这些服务红利的群体，面对 Serverless 严格的无状态要求，以及客户对系统稳定性、业务正确性的担忧，存量应用的改造代码设计的难度和成本太高，因此他们希望能够在不更改代码结构的前提下享受 Serverless 红利。

Book 模式会按照应用的峰值进行部署，且业务 Owner 在进行容量评估时往往会留有余地，导致资源池利用率低。CSE 采用 Serverless 按需模式进行部署，通过快速弹缩、分时复用和高密度部署来大幅度降低成本。
在这里插入图片描述
假设业务单次请求的 SLA 在 50ms，如果业务启动时间能做到 50ms 以下，就可以等待请求到来时再按需进行扩容，反之则只能根据水位进行 Book。启动时间越短，扩容时机可推迟到越晚，缩容时机可提前至越早，成本越低。

但现实情况是，大多数在线业务的启动时间都在分钟级，甚至有的达到 30 分钟。在线业务一般基于HSF 和潘多拉框架进行研发，同时会依赖大量的中间件富客户端以及其它部门提供的二方包，启动过程中包含了大量的初始化工作，比如网络连接、缓存加载、配置加载等。
因在线业务的启动瓶颈在于业务自身的代码，像 AWS Lambda、函数计算等 Function 场景对 IaaS或 Runtime 框架的弹性优化手段，在在线业务的场景下基本没有用武之地。在无法侵入业务代码的前提下，如何将业务启动时间从分钟级优化至秒级甚至毫秒级是 CSE 研发阶段重点攻坚的方向。

Zizz 方案基于一个核心和一个假设：
核心是热备（Standby）：既然应用的冷启动时间如此长且很难优化，那么提前启动一批实例进行Standby，在流量峰值临时进行上线接流，在流量低谷时进行离线处理（服务发现层面的离线）；
假设是离线的实例功耗非常低：如果热备的实例需要占据全部的物理资源，那么与 Book 模式并没有本质的区别。但理论上，处于离线状态的实例没有前端流量的驱动，应该仅存在少量的后台任务在运行。所以对于 Standby 的实例，可以将其换入一个低功耗的状态，将 CPU 和内存的规格降至很低，以极低的成本进行 Standby，为分时复用和高密度部署带来更高的灵活性。

基于这两点，CSE Zizz 研发了几种核心技术：
一种基于弹性堆的低功耗技术；
基于内核态和用户态的 Swap 能力的内存弹性技术；
基于 Inplace Update 的实例规格动态升降配技术。

在嵌入式领域， 低功耗运行模式被广泛接受，包括 OS 设计和应用设计。针对 OS 在设计阶段都会考虑到系统低功耗运行的情况，而对于应用，也会在设计和开发阶段考虑到低功耗运行的情况，通常应用会注册系统低功耗运行事件，在应用收到系统的低功耗运行事件之后，会进行一系列逻辑处理使自己进入低功耗运行状态。基于这样的启发，在未来云计算环境下，应用的运行模式应该也需要支持类似的设计，这也是在 CSE Zizz 方案中引入应用低功耗运行时的概念，从而使整个 Zizz 方案更好地适配Serverless 场景需求。 Zizz 低功耗运行时核心技术主要包括下面三个部分。
CPU 低功耗
按照 Zizz 架构设计，进入低功耗模式，我们会对实例的资源配置进行降级；针对 CPU 资源，我们维护一个低功耗 CPU Pool（CPU Set），CPU Pool 初始值是 1C，会随着加入这个 CPU Pool 中低功耗实例的数量，增加其 CPU Core 的数量，这样同一个 Node 上的多个低功耗实例争抢一个 CPUPool 中的资源。从 CPU 资源利用角度，多个低功耗实例构成了一个分时复用 CPU 资源的低功耗Serverless 场景。
内存低功耗
经过探索和论证，我们认为 Linux Swap 技术能够完成这样的使命。Linux Swap 向系统提供了一种透明的与进程运行时无关的内存扩展能力：根据系统当前内存压力，将系统的匿名内存按照 LRU 访问活跃度从低到高依次换出到外部低速存储介质，从而达到扩展系统可用内存的目的；在具体换出过程中，系统会根据 Swap 子系统的其它设置，根据当前内存 Anonymous 和 Filecache 的占比，将不活跃的 Anonymous 内存 Page 换出到外部低速存储设备上；从系统内存的角度来看，Swap 是一个扩展低速内存 Pool；从成本的角度，Swap 提供了一种低成本的进程运行时上下文；面向未来，