SAE 实现应用发布全过程可观测

2025-04-27
浙江
本文字数：2902 字
阅读完需：约 10 分钟

本文作者：丛霄、久氢、章进

导读：本文通过剖析阿里云 Serverless 应用引擎（以下简称 SAE ）用户使用过程中存在的“发布过程慢，发布效率低，实例启动过程黑盒”等痛点，采取分步骤可视化的解法，帮助用户看到问题、理解问题，最后解决问题，提升使用 SAE 平台的体验。

用户痛点剖析

当业务的规模上量后，应用数量会爆炸式增长，而“应用发布”作为一个高频的操作，是业务运维人员每天会面临的操作。通过与一些 SAE 的企业级客户的交流，目前在 SAE 上的应用发布存在着以下几个痛点：

应用部署的发布过程通常较慢，最快也要 5 分钟，最慢可能半小时，严重拖慢了业务开发效率。
应用部署的详情透出的信息过于简单，用户想知道具体哪里慢，平台封装了部署的步骤，没有对用户透出更多有用的细节, 每次用户发布过程中盯着发布单状态变化，也只是干等，并不知道具体执行了哪些步骤。

SAE 发布单详情界面

实例启动过程黑盒，实例是承担业务的核心，而每次应用变更动作，都围绕着实例展开，但目前实例的状态变化存在着可用信息不足、实时性较差等问题。

实例列表界面

SAE 作为一款全托管的容器化应用平台，核心特性就是简化应用的部署和运维操作，给到用户简单易用，平滑顺畅的使用体验。

然而， “简单”不代表着“简化”，SAE 的客户群体和业务类型众多，平台侧封装过多意味着灵活性的丧失，平台侧暴露过多也会造成用户额外的心智负担。在同一款产品形态中同时满足多种客户多种业务的诉求，是我们在做每一个功能优化、产品设计时都需要考虑的问题。

解决方案

发现用户的痛点后，我们进行了一些思考和设计，通过可观测、可解释、可优化的解决思路，我们进行了一些优化。

可观测：看到具体的问题

如何将必要的有用信息提供给用户，既能解决用户问题，也不会造成额外的疑虑。 SAE 是应用维度的 PaaS 平台，一个应用下面管理了不同的资源。围绕实例和发布单两个核心资源，如何对资源进行可视化，让用户能直白地看到具体的每次发布、变更具体在哪个节点、步骤有问题，是可观测需要回答的。

我们对实例和发布单两个实体结构和状态流转进行了分析。

SAE 发布单是一个异步的发布流程处理引擎，用户的发布方式可以选择灰度发布或分批发布。在一个 ChangeOrder 下分为不同的 Pipeline 批次，一个 Pipeline 批次下面又分为不同的执行步骤 Task，一个 Task 又分为不同的 Stage。可以看到整体是一个树形的结构。

虽然发布单整体结构复杂，但是我们仅将我们认为有效的信息透出给用户，对用户屏蔽了一部分的复杂性。通过统计分析，发布单步骤中耗时最长的是 Pipeline 下面的 Task，而 Task 中耗时最长的又是 “执行应用部署”这个子 Task。

所以，可观测问题的核心就是这么让用户清晰地看到：哪个 Task 耗时最长，具体耗时长在哪里？于是在发布单列表界面可以通过透出历史发布单的耗时统计数据，Task 耗时 Top 排序，能让用户清晰的看到问题所在。

而分析完“执行应用部署” Task 耗时最长后，我们又分析了具体这个步骤的耗时，就是批次发布中实例消耗的时间。所以我们捞取了每个发布批次相关联的实例，并对实例启动过程进行了可观测数据处理。

实例数据处理整体框架如下图所示：

K8s 资源数据采集

通过定制化 sae-kube-eventer 组件将 ASI 集群中所有事件上报至 SLS tenant-events logstore 中，事件元数据中会包含 sae 应用 appid 等信息。
通过定制化 sae-kube-exporter 组件将 ASI 集群中所有 pod 状态变化历史 yaml 完整元数据上报至 SLS sae-pod-queue logstore 中。

实例数据处理

事件消费：主要是按照 SAE 应用实例级别从 SLS 日志库中查询并消费原始数据
事件过滤：实例原始数据量很多，且很多事件冗余，这里会先将内置 initcontainer 以及内置 sidecar 事件过滤，并对重复事件进行聚合
事件生成：针对不同类型的数据消费处理之后，根据固定的事件结构模型生成事件

可解释：理解问题在哪里

在第一步可观测完成后，用户还需要能理解问题。从可观测数据源上看，原始数据采集的是标准的 K8s Event，具有可解释性。同时，在设计上，我们通过将发布过程和实例启动过程按照时间线形式展示，能更清晰的看到不同步骤间的时间分布。

但是在 K8s 中，实例的状态变化有多种，我们通过抽取关键信息，聚合相似事件，精简实例的状态描述，按照更容易让用户理解的方式进行了可视化的展示。在实例启动耗时里，我们向用户透出了以下处理后的实例状态阶段，便于用户可以直观看到不同阶段的耗时：

资源调度中：调度器调度实例到具体节点的耗时时间
实例准备中：节点初始化实例资源以及内置 init container 和内置 sidecar 容器拉取镜像、启动等平台侧耗时
开始拉取镜像：用户业务主容器镜像拉取时间
镜像拉取结束：成功拉取业务主容器镜像
容器已创建：业务主容器创建时间
容器进程已启动：业务主容器进程启动耗时
实例就绪：实例已准备就绪，可以承接业务流量

可优化：能解决问题

可观测不是目标，最终目标是能帮助用户解决问题。在第二部可解释完成后，用户能清楚的看到问题，并且能区分出哪里是平台侧耗时，哪里是用户侧耗时。

针对不同阶段的问题，SAE 也提供了可优化的手段：

1. 应用部署分批部署慢：通过配置更合理的分批部署参数，可以有效减少分多批发布下的整体发布时长。

2. 拉取镜像慢：SAE 已经对平台公共镜像做了缓存，可大幅降低镜像拉取时间。而对于用户自身镜像，也提供了镜像加速能力，基于 DADI 块设备镜像存储实现按需加载，大大缩短了拉取镜像的时间。用户可以使用 ACREE 标准版或企业版镜像仓库，开启镜像加速功能。目前 SAE 镜像加速功能已经全量支持，能大大减少大镜像拉取的耗时，优化应用发布实例启动速度，用户可以按需开启。