聚焦弹性问题，杭州铭师堂的 Serverless 之路

Posted 2023-04-10 阿里系统软件技术

目前网上教学需求的常态化，教师在线审阅作业需求量急剧增大，为了减轻老师的审批工作量，提升教学效率，杭州铭师堂教育基于 Serverless 创造性的开发了学习笔记评优系统, 提升弹性效率，并大幅度降低成本。

作者：王彬、朱磊、史明伟

得益于互联网的发展，知识的传播有了新的载体，使用在线学习平台的学生规模逐年增长，越来越多学生在线上获取和使用学习资源，其中教育科技企业是比较独特的存在，他们担当的不仅仅是教育者的角色，更是让新技术的创新者和实践者。作为一家在线教育高科技企业，杭州铭师堂成立十余年来一致致力于用“互联网+教育”的科技手段让更多的学生能享有优质的教育，促进他们的全面成长，在不断汇聚优质的全国各地教育资源的同时，杭州铭师堂深度聚焦教学效率的提升，深耕先进技术，促进其在学校教育智能化领域、个性化学习领域广泛应用。

目前网上教学需求的常态化，教师在线审阅作业需求量急剧增大，为了减轻老师的审批工作量，提升教学效率，杭州铭师堂教育基于 Serverless 创造性的开发了学习笔记评优系统, 提升弹性效率，并大幅度降低成本。

01 峰值流量破万后，如何更好处理任务处理的实时性问题？

杭州铭师堂业务涵盖全国 20 多个省份，成立十余年来，杭州铭师堂不断汇聚优质的全国各地教育资源，并展开先进科学技术在学校教育智能化领域、个性化学习领域的应用研究。在教育信息化 2.0 趋势下，公司致力于促进线上教育与线下教育的高度融合，以学校为核心场景，与学校携手共建互联网学习空间，为学校与学生提供学习解决方案，极大促进教学效率的提升。

K8s+ 消息，系统难以处理数据并行度问题

学生做完作业后，会将作业拍照，然后上传到作业批阅系统，后端系统此时会有多个动作：

1. 将作业照片上传到 OSS

2. 将用户作业信息落到数据库

3. 发送一条消息到阿里云消息队列 Kafka

其中第 3 步发送消息到阿里云消息队列 Kafka 后，通过消息队列 Kafka 的 connector 功能，驱动函数计算（简称 FC） 进行数据处理。函数计算作为业务的计算平台，承载了所有的处理逻辑，通过图像识别和数据分类算法，自动识别作业的完成情况。

在一年的大多数时间里，业务流量都比较平稳，但在寒暑假时，一般会迎来一年中的高峰，在过去的 2022 年暑假期间，平均每天需要处理 100 多万的作业图片处理，峰值流量更是达到了万级别。

作业图片的处理程序原先部署在 Kubernetes(简称 K8s)，程序通过订阅 Kafka 的 topic，获取数据路径，从 OSS 获取数据进行处理，这一部分涉及到数据并行度的处理，主要存在两方面问题：

1. Kafka 的消费端并发度受限于 topic 的 partition，消费端个数最多只能跟 partition 数齐平，消费端数量超过 Kafka topic partition 数会导致超过 partition 数目的消费端没法订阅数据，也就没有实际的意义；

2. 每个消费端消费到数据之后会将数据发到处理线程处理，处理线程在最好的情况下是可以根据业务流量动态调整，当然更多的线程就需要更多的资源，这又涉及到任务资源的水平扩容和垂直扩容问题。实际实现时杭州铭师堂消费端个数与 topic partition 保持一致，消费线程数经过调优之后保持了固定数量，在绝大多数时间里，程序能够很好的满足数据处理的的实时性要求，但对于高峰期，由于处理能力的限制，还是会经常出现任务积压的情况。

为了能够更好的实现任务处理的实时性要求，杭州铭师堂架构组寻求新的架构，经过对云产品的对比之后，最终选择了阿里云函数计算 FC。

02 兼顾弹性和成本，选定函数计算新方案

通过基于函数计算的新方案，很好的解决了老架构存在的问题，同时，开发迭代速度，运维效率和成本都得到了很大的优化，新老方案对比如下：

通过以上对比可以看出，函数计算对于杭州铭师堂学习笔记评优系统还是非常合适，在解决弹性痛点的同时，资源成本，开发运维效率都得到了一定的提升。

03 杭州铭师堂的 Serverless 落地之路

在技术架构的实施过程中，最初也遇到了一点问题：

Java 冷启动的问题：第一个问题是语言的问题，原来的后端程序采用 Java 微服务框架，整个服务中有多个接口，刚开始直接将整个服务部署到函数计算。由于 Java 程序启动的特性，加上整个服务框架加载的模块和数据较多，导致冷启动时间比较长，触发冷启动时没法很好的满足业务接口响应要求。

对于这个问题，杭州铭师堂开发同学主要做了两个迭代，首先将代码粒度拆细，在函数计算平台部署真正的处理代码，第二步，将 Java 语言的代码替换成 TypeScript。替换成 TypeScript 一是因为开发同学比较熟悉 TypeScript，二是因为 Node.js 启动速度很快。通过这两次迭代，使得函数的弹性效率大大提升，冷启动的情况下也能够达到 50ms 内完成单次请求。

资源利用率问题：第二个问题是资源的利用率，由于把函数逻辑拆分很细，单个请求对 CPU 和 Memory 的需求都很小，微了提高利用率，选择开启函数计算的单实例多并发，通过 PTS 的压测，在并发度和资源上的到了很好的平衡，资源利用率高达 70%+。

超出预期的惊喜：执行时间快和弹性效率高

通过解决这两个问题，整体开发流程顺利，项目上线后也达到不错的效果，在一些小的方面还有超出预期的表现，主要惊喜来自于执行时间快和弹性效率高。

执行时间快：在原来服务部署在 K8s 时，业务高峰期，单个请求响应时间在 100～200ms 左右，放到函数计算后，在高峰期，请求处理时间也能够维持在 50ms 左右，这是大大超出预期的，分析其中的原因主要是函数计算运行资源比较独立，每个实例处理固定的并发上限，超过部分通过弹出新的实例承载，所以高峰期请求脉冲到来时，也不会出现资源争抢。

弹性效率高：之前在架构设计时，很担心函数计算的冷启动问题，因为冷启动涉及到软硬件资源的初始化。但在实际运行表现看，这点担心也是可以忽略的。函数计算后端机器是神龙服务器，单台机器配置很高，单台机器可以切分出很多的运行实例，并且函数计算在镜像拉取，实例热备方面都有优化，运行实例拉起速度非常快，再加上 Node.js 启动速度的优势，在遇到冷启动时，请求也能够在 100ms 以内响应，这一点对于实时业务非常友好。

业务接口上线到函数计算后，很好的解决了之前高峰期的堆积问题，并且通过函数计算内置的监控和日志服务，在出现问题时，可以更好的辅助问题的排查，最重要的一点，通过函数计算的实时弹性，不再需要提前规划资源和部署冗余服务，使得资源成本也有一定降低。

04 为客户带来更多价值，杭州铭师堂继续探索 Serverless

通过这次项目，函数计算在杭州铭师堂内部的应用得到了更大的推广，将高脉冲和高资源要求的接口剥离出原服务，统一放到函数计算平台承载，对内部系统完成了一次 Serverless 架构的升级。

在整体使用过程中，杭州铭师堂架构团队也对函数计算提出了一些不足点：

产品集成割裂：在调用链路中，Kafka 数据通过 Kafka connector 触发函数计算的调用，Kafka 触发器与函数计算的使用界面有点割裂，具体表现为 Kafka 侧的订阅消费情况在 Kafka 控制台显示，函数计算的调用和监控需要跳转到函数计算，当出现问题时，排查问题需要两边控制台跳转，使用体验很不友好。

部署系统对接不够顺滑：杭州铭师堂经过多年发展，内部有成熟的 CICD 系统，中间加入函数计算之后，需要将函数计算纳入到自有的 CICD 系统中，这方面起初采用函数计算的 Open api，后来经过升级采用了 Serverless Devs 工具，虽然对接体验有了一定提升，细节方面还需要继续打磨。

未来，杭州铭师堂将与阿里云函数计算团队一道在集成，体验和技术深度等方面持续深耕，一起探索 Serverless 在实际业务的落地，以科技服务教育，用互联网改变教育，让中国人都有好书读。

开始使用函数计算

函数计算是事件驱动的全托管计算服务。使用函数计算，客户无需采购与管理服务器等基础设施，只需编写并上传代码或镜像。函数计算即可准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。

函数计算主要包含服务、函数、运行环境、触发器、层、应用中心等功能组件，具体产品组件架构图如下所示。

函数计算底层借助阿里云基础设施，如神龙服务器，网络通信，存储，安全组件等，构建安全，可靠，高性能的服务。弹性伸缩，负载均衡，流量控制，租户隔离，容灾等能力采用自研系统，保证了函数计算的计算密度，弹性效率，计费精度等核心竞争力。

函数计算的使用流程如下：

1. 创建函数，编写代码。

2. 将第 1 步中编写好的代码以函数的形式部署到函数计算。

3. 函数计算支持通过触发器快速构建事件驱动架构业务流程的能力。

4. 函数计算支持按请求付费的模式，在函数有调用时，后端会弹出真实的计算资源，当同时有多个请求打到函数计算，函数计算会并发的弹出多个计算实例进行并行处理，每个启动计算实例都会保持一定时间的在线，超过一定时间，系统会回收计算实例。

5. 最终收费时，按照实际函数运行的时间收费。

通过函数计算的平台，客户只需要专注业务代码，面向函数极简编程（可选多种编程语言），通过函数计算提供的 SDK，Serverless Devs 工具，丰富的云产品事件驱动触发器，可以快速构建完整的调用链路。开发者不再需要直面 IaaS 资源和容器资源，通过将云上业务拆分到函数级别，多个函数组成服务，多个服务构建应用，让开发者从小处处着手，快速实现业务落地。

整体调用链路如下：

处理步骤细节：

1. 用户提交作业出发提交流程，将请求打到后端服务。

2. 后端服务将用户提交的作业图片上传到 OSS，并将 OSS 地址作为一条消息发送到 Kafka。

3. 函数计算的 Kafka 触发器实时的感知 Kafka topic，当有新数据到达，实时触发函数处理。

4. 函数计算函数获取到触发请求中的数据，从 OSS 获取数据，并对数据进行处理，将处理结果发回到 Kafka topic。

5. 后端程序订阅 Kafka topic，对处理结果进行存储和下一步的展示。

点击此处，直达函数计算！

云原生体系下 Serverless 弹性探索与实践

简介： SAE 通过对弹性组件和应用全生命周期的不断优化以达到秒级弹性，并在弹性能力，场景丰富度，稳定性上具备核心竞争力，是传统应用 0 改造上 Serverless 的最佳选择。

作者：竞霄

Serverless 时代的来临

Serverless 顾名思义，是一种“无服务器”架构，因为屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现。在 Serverless 架构下，开发者只需要关注于上层应用逻辑的开发，而诸如资源申请，环境搭建，负载均衡，扩缩容等等服务器相关的复杂操作都由平台来进行维护。在云原生架构白皮书中，对Serverless 的特性有以下概括：

• 全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作；
• 通用性，能够支撑云上所有重要类型的应用；
• 自动的弹性伸缩，让用户无需为资源使用提前进行容量规划；
• 按量计费，让企业使用成本得有效降低，无需为闲置资源付费。

回顾整个 Serverless 的发展历程，我们可以看到从 2012 年首次提出 Serverless 概念为起点，再到  AWS 推出 Lambda 云产品的这段时间内，人们对 Serverless 的关注度出现了爆发式的增长，对无服务器的期待和畅想逐渐引爆整个行业，但 Serverless 的推广和生产落地的过程却不容乐观，Serverless 理念与实操生产的过程中存在 Gap，挑战着人们固有的使用体验和习惯。

阿里云坚信 Serverless 将作为云原生之后确定性的发展方向，相继推出了FC,SAE 等多款云产品来覆盖不同领域，不同类型的应用负载来使用 Serverless 技术，并且不断在推进整个 Serverless 理念的普及与发展。

就当前 Serverless 整个市场格局而言，阿里云已经做到了 Serverless 产品能力中国第一，全球领先，在去年 Forrester 评测魔力象限中可以明显的看到阿里云在 Serverless 领域已经与 AWS 不相上下，于此同时，阿里云 Serverless 用户占比中国第一，在 2020 年中国云原生用户调研报告中整个阿里云 Serverless 用户占比已经达到了66%，而在 Serverless 技术采用情况的调研中表明，已经有越来越多的开发者和企业用户将 Serverless 技术应用于核心业务或者将要应用于核心业务之中。

Serverless 弹性探索

弹性能力作为云的核心能力之一，所关注的问题是容量规划与实际集群负载间的矛盾，通过两幅图的对比可以看到，如果采用预先规划的方式进行资源安排，会由于资源准备量和资源需求量的不匹配导致资源浪费或者资源不足的情况，进而导致成本上的过多开销甚至业务受损，而我们期望极致弹性能力，是准备的资源和实际需求的资源几乎匹配，这样使得应用整体的资源利用率较高，成本也随业务的增减和相应的增减，同时不会出现因容量问题影响应用可用性的情况，这就是弹性的价值。

弹性其实现上分为可伸缩性和故障容忍性,可伸缩性意味着底层资源可以参照指标的变化有一定的自适应能力，而故障容忍性则是通过弹性自愈确保服务中的应用或实例处于健康的状态。上述能力带来的价值收益在于降成本的同时提升应用可用性，一方面，资源使用量贴合应用实际消耗量，另一方面，提升峰值的应用可用性，进而灵活适应市场的不断发展与变化。

下面将对当前较为普遍的三种弹性伸缩模式进行阐述和分析。

首先是 IaaS 弹性伸缩，其代表产品是各云厂商云服务器弹性伸缩，如阿里云ess,可以通过配置云监控的告警规则来触发相应的 ECS 增减操作，同时支持动态增减 Slb 后端服务器和 Rds 白名单来保证可用性，通过健康检查功能实现弹性自愈能力。ESS 定义了伸缩组的概念，即弹性伸缩的基本单位，为相同应用场景的 ECS 实例的集合及关联 Slb,Rds, 同时支持多种伸缩规则，如简单规则，进步规则，目标追踪规则，预测规则等，用户的使用流程为创建伸缩组和伸缩配置，创建伸缩规则，监控查看弹性执行情况。

Kubernetes 弹性伸缩，这里主要关注于水平弹性 hpa，其代表产品为 K8s 以及其所对应的托管云产品，如阿里云容器服务，K8s 做为面向应用运维的基础设施和 Platform for Platform,提供的内置能力主要是围绕着容器级别的管理和编排来展开的,而弹性能力聚焦于对底层 Pod 的动态水平伸缩，K8s hpa 通过轮询 Pod 的监控数据并将它与目标期望值比较进行，通过算法实时计算来产生期望的副本数，进而对 Workload 的副本数进行增减操作，用户在实际使用上需要创建并配置对应的指标源和弹性规则以及对应的 Workload，可以通过事件来查看弹性的执行情况。

最后介绍一下应用画像弹性伸缩，其主要用于互联网公司内部，如阿里 ASI 容量平台。容量平台提供容量预测服务和容量变更决策服务，指导底层容量变更组件如 AHPA/VPA 实现容量弹性伸缩，并根据弹性结果修正容量画像。以画像驱动为主 + 指标驱动为辅实现弹性伸缩能力，通过提前伸缩 + 实时修正来降低弹性伸缩风险。整个弹性伸缩会借助odps和机器学习能力对实例监控等数据进行处理并产生应用画像，如基准画像，弹性画像，大促画像等，并借助容量平台来完成画像注入，变更管控和故障熔断等操作。用户使用流程为应用接入，基于历史数据/经验生成对应的容量画像，实时监控指标修正画像，并监控查看弹性执行情况。

从对比可以看出各产品弹性伸缩功能模式上从抽象来讲基本相同，均由触发源，弹性决策和触发动作组成，触发源一般依赖外部监控系统，对节点指标，应用指标进行采集处理，弹性决策一般基于周期性轮询并算法决策，有部分基于历史数据分析预测以及用户定义的定时策略，而触发动作为对实例进行水平扩缩，并提供变更记录与对外通知。各个产品在此基础上做场景丰富度，效率，稳定性的竞争力，并通过可观测能力提升弹性系统的透明度，便于问题排查和指导弹性优化，同时提升用户使用体验与粘性。

各产品弹性伸缩模型也存在这一定的差异，对于 IaaS 弹性伸缩，其作为老牌弹性伸缩能力，沉淀时间长，功能强大且丰富，云厂商间能力趋于同质化。弹性效率相较容器受限，且强绑定各自底层 Iaas 资源。Kubernetes 作为开源产品，通过社区力量不断优化迭代弹性能力和最佳实践，更符合绝大部分开发运维人员诉求。对弹性行为和api进行高度抽象，但其可扩展性不强，无法支持自定义需求。而应用画像弹性伸缩具有集团内部特色，根据集团应用现状和弹性诉求进行设计，且更聚焦于资源池预算成本优化，缩容风险，复杂度等痛点。不易拷贝扩展，特别对于外部中小客户不适用。

从终态目标上，可以看出公有云与互联网企业方向的不同：

• 互联网企业往往由于其内部应用具有显著流量特征，应用启动依赖多，速度慢，且对整体资源池容量水位，库存财务管理，离在线混部有组织上的诸多诉求，因而更多的是以容量画像提前弹性扩容为主，基于 Metrics 计算的容量数据作为实时修正，其目标是容量画像足够精准以至于资源利用率达到预期目标。
• 公有云厂商服务于外部客户，提供更为通用，普适的能力，并通过可拓展性满足不同用户的差异化需求。尤其在 Serverless 场景，更强调应用应对突发流量的能力，其目标在于无需容量规划，通过指标监控配合极致弹性能力实现应用资源的近乎按需使用且整个过程服务可用。

Serverless 弹性落地

Serverless 作为云计算的最佳实践、云原生发展的方向和未来演进趋势，其核心价值在于快速交付、智能弹性、更低成本。

在时代背景下，SAE 应运而生，SAE 是一款面向应用的 Serverless PaaS 平台，支持 Spring Cloud、Dubbo 等主流开发框架，用户可以零代码改造直接将应用部署到 SAE，并且按需使用，按量计费，可以充分发挥 Serverless 的优势为客户节省闲置资源成本，同时体验上采用全托管，免运维的方式，用户只需聚焦于核心业务开发，而应用生命周期管理，微服务管理，日志，监控等功能交由SAE完成。

弹性的竞争力主要在于场景丰富度，效率，稳定性的竞争力，先讲一下SAE在弹性效率上的优化。

通过对 SAE 应用的整个生命周期进行数据统计和可视化分析，其包含调度，init container 创建，拉取用户镜像，创建用户容器，启动用户容器&应用这几个阶段，示意图中对其耗时的占比进行了简化。我们可以看到整个应用生命周期耗时集中于调度，拉取用户镜像，应用冷启动这几个阶段。针对于调度阶段，其耗时主要在于 SAE 当前会执行打通用户 VPC 操作，由于该步骤强耦合于调度，本身耗时较长，且存在创建长尾超时，失败重试等情况，导致调度链路整体耗时较长。

由此产生的疑问是可否优化调度速度？可否跳过调度阶段 ? 而对于拉取用户镜像，其包含拉取镜像与解压镜像的时长，特别是在大容量镜像部署的情况下尤为突出。优化的思路在于拉取镜像是否可以优化使用缓存，解压镜像是否可以优化。而对于应用冷启动，SAE 存在大量单体和微服务的 JAVA 应用，JAVA 类型应用往往启动依赖多，加载配置慢，初始化过程长，导致冷启动速往往达到分钟级。优化的方向在于可否避免冷启动流程并使用户尽量无感，应用无改造。

首先 SAE 采用了原地升级能力，SAE 起初使用了 K8s 原生的 Deployment 滚动升级策略进行发布流程，会先创建新版本 Pod，再销毁旧版本 Pod 进行升级，而所谓原地升级，即只更新 Pod 中某一个或多个容器版本、而不影响整个 Pod 对象、其余容器的升级。其原理是通过 K8s patch 能力，实现原地升级 Container，通过 K8s readinessGates 能力，实现升级过程中流量无损。

原地升级给SAE带来了诸多价值，其中最重要的是避免重调度，避免 Sidecar 容器（ARMS,SLS,AHAS）重建,使得整个部署耗时从消耗整个 Pod 生命周期到只需要拉取和创建业务容器，于此同时因为无需调度，可以预先在 Node 上缓存新镜像，提高弹性效率。SAE 采用阿里开源 Openkruise 项目提供的 Cloneset 作为新的应用负载，借助其提供的原地升级能力，使得整个弹性效率提升 42%。

同时 SAE 采用了镜像预热能力，其包含两种预热形式：调度前预热，SAE 会对通用的基础镜像进行全节点缓存，以避免其频繁的从远端进行拉取。与此同时对于分批的场景支持调度中预热，借助 Cloneset 原地升级能力，在升级的过程中可以感知到实例的节点分布情况，这样就可以在第一批部署新版本镜像的同时，对后面批次的实例所在节点进行镜像预拉取，进而实现调度与拉取用户镜像并行。通过这项技术，SAE 弹性效率提升了 30%。

刚才讲述的优化点在于拉取镜像部分，而对于解压镜像，传统容器运行需要将全量镜像数据下载后再解包，然而容器启动可能仅使用其中部分的内容，导致容器启动耗时长。SAE 通过镜像加速技术，将原有标准镜像格式自动转化为支持随机读取的加速镜像，可以实现镜像数据免全量下载和在线解压，大幅提升应用分发效率，同时利用 Acree 提供的 P2P 分发能力也可以有效减少镜像分发的时间。

对于 Java 应用冷启动较慢的痛点，SAE 联合 Dragonwell 11 提供了增强的 AppCDS  启动加速策略，AppCDS 即  Application Class Data Sharing，通过这项技术可以获取应用启动时的 Classlist 并 Dump 其中的共享的类文件，当应用再次启动时可以使用共享文件来启动应用，进而有效减少冷启动耗时。映射到 SAE 的部署场景，应用启动后会生成对应的缓存文件在共享的 NAS 中，而在进行下一次发布的过程中就可以使用缓存文件进行启动。整体冷启动效率提升 45%。

除了对整个应用生命周期的效率进行优化外，SAE 也对弹性伸缩进行了优化，整个弹性伸缩流程包括弹性指标获取，指标决策以及执行弹性扩缩操作三部分。对于弹性指标获取，基础监控指标数据已经达到了秒级获取，而对于七层的应用监控指标，SAE 正在规划采用流量透明拦截的方案保证指标获取的实时性。而弹性决策阶段，弹性组件启用了多队列并发进行 Reconcile，并实时监控队列堆积，延时情况。

SAE 弹性伸缩包括强大的指标矩阵，丰富的策略配置，完善的通知告警机制及全方位可观测能力,支持多种数据源：原生的 MetricsServer，MetricsAdapter，Prometheus，云产品 SLS,CMS,SLB 以及外部的网关路由等，支持多种指标类型：CPU、MEM、QPS、RT、TCP 连接数，出入字节数，磁盘使用率，Java线程数，GC 数还有自定义指标。对指标的抓取和预处理后，可以自定义配置弹性策略来适配应用的具体场景：快扩快缩，快扩慢缩，只扩不缩，只缩不扩，DRYRUN，自适应扩缩等。

同时可以进行更为精细化的弹性参数配置,如实例上下限，指标区间，步长比例范围，冷却、预热时间，指标采集周期和聚和逻辑，CORN 表达式，后续也会支持事件驱动的能力。弹性触发后会进行对应的扩缩容操作，并通过切流保证流量无损，并且可以借助完善的通知告警能力（钉钉，webhook,电话，邮件，短信）来实时触达告知用户。弹性伸缩提供了全方位的可观测能力，对弹性的决策时间，决策上下文进行清晰化展现，并且做到实例状态可回溯，实例 SLA 可监控。

SAE 弹性能力在场景丰富度上也有着相应的竞争力，这里重点介绍一下 SAE 当前支持的四种场景：

• 定时弹性：在已知应用流量负载周期的情况下进行配置，应用实例数可以按照时间，星期，日期周期进行规律化扩缩，如在早 8 点到晚 8 点的时间段保持 10 个实例数应对白天流量，而在其余时间由于流量较低则维持在 2 个实例数甚至缩 0。适用于资源使用率有周期性规律的应用场景，多用于证券、医疗、政府和教育等行业。
• 指标弹性：可以配置期望的监控指标规则，SAE 会时应用的指标稳定在所配置的指标规则内，并且默认采用快扩慢缩的模式来保证稳定性。如将应用的cpu指标目标值设置为 60%，QPS 设置为 1000，实例数范围为 2-50。这种适用于突发流量和典型周期性流量的应用场景，多用于互联网、游戏和社交平台等行业。
• 混合弹性：将定时弹性与指标弹性相结合，可以配置不同时间，星期，日期下的指标规则，进而更加灵活的应对复杂场景的需求。如早 8 点到晚 8 点的时间段 CPU 指标目标值设置为 60%，实例数范围为 10-50，而其余时间则将实例数范围降为 2-5，适用于兼备资源使用率有周期性规律和有突发流量、典型周期性流量的应用场景，多用于互联网、教育和餐饮等行业。
• 自适应弹性：SAE 针对流量突增场景进行了优化，借助流量激增窗口，计算当前指标在这个时刻上是否出现了流量激增问题，并会根据流量激增的强烈程度在计算扩容所需的实例时会增加一部分的冗余，并且在激增模式下，不允许缩容。

稳定性是 SAE 弹性能力建设的过程中非常重要的一环，保证用户应用在弹性过程中按照预期行为进行扩缩，并保证整个过程的可用性是关注的重点。SAE 弹性伸缩整体遵循快扩慢缩的原则，通过多级平滑防抖保证执行稳定性，同时对于指标激增场景，借助自适应能力提前扩容。SAE 当前支持四级弹性平滑配置保证稳定性：

• 一级平滑：对指标获取周期，单次指标获取的时间窗口，指标计算聚和逻辑进行配置
• 二级平滑：对指标数值容忍度，区间弹性进行配置
• 三级平滑：对单位时间扩缩步长，百分比，上下限进行配置
• 四级平滑：对扩缩冷却窗口，实例预热时间进行配置

Serverless 弹性最佳实践

 

SAE 弹性伸缩可以有效解决瞬时流量波峰到来时应用自动扩容，波峰结束后自动缩容。高可靠性、免运维、低成本的保障应用平稳运行，在使用的过程中建议遵循以下最佳实践进行弹性配置。

• 配置健康检查和生命周期管理

建议对应用健康检查进行配置，以保证弹性扩缩过程中的应用整体可用性，确保您的应用仅在启动、运行并且准备好接受流量时才接收流量 同时建议配置生命周期管理 Prestop，以确保缩容时按照预期优雅下线您的应用。

• 采用指数重试机制

为避免因弹性不及时，应用启动不及时或者应用没有优雅上下线导致的服务调用异常，建议调用方采用指数重试机制进行服务调用。

• 应用启动速度优化

为提升弹性效率，建议您优化应用的创建速度，可以从以下方面考虑优化：

• 软件包优化：优化应用启动时间，减少因类加载、缓存等外部依赖导致的应用启动过长
• 镜像优化：精简镜像大小，减少创建实例时镜像拉取耗时，可借助开源工具 Dive，分析镜像层信息，有针对性的精简变更
• Java 应用启动优化：借助 SAE 联合 Dragonwell 11 ，为 Java 11 用户提供了应用启动加速功能

• 弹性伸缩指标配置

弹性伸缩指标配置，SAE 支持基础监控，应用监控多指标组合配置，您可以根据当前应用的属性（CPU敏感 /内存敏感 /io 敏感）进行灵活选择。

可以通过对基础监控和应用监控对应指标历史数据（ 如过去6h, 12h, 1天,7天峰值，P99,P95 数值）进行查看并预估指标目标值，可借助 PTS 等压测工具进行压测，了解应用可以应对的并发请求数量、需要的 CPU 和内存数量，以及高负载状态下的应用响应方式，以评估应用容量峰值大小。

指标目标值需要权衡可用性与成本进行策略选择，如

• 可用性优化策略 配置指标值为40%
• 可用性成本平衡策略 配置指标值为50%
• 成本优化策略 配置指标值为70%

同时弹性配置应考虑梳理上下游，中间件，db等相关依赖，配置对应的弹性规则或者限流降级手段，确保扩容时全链路可以保证可用性。

在配置弹性规则后，通过不断监视和调整弹性规则以使容量更加接近应用实际负载。

• 内存指标配置

关于内存指标，考虑部分应用类型采用动态内存管理进行内存分配（如 Java jvm内存管理，Glibc Malloc 和 Free 操作），应用闲置内存并没有及时释放给操作系统，实例消耗的物理内存并不会及时减少且新增实例并不能减少平均内存消耗，进而无法触发缩容，针对于该类应用不建议采用内存指标。

• Java 应用运行时优化：释放物理内存，增强内存指标与业务关联性

借助 Dragonwell 运行时环境，通过增加 JVM 参数开启 ElasticHeap 能力，支持 Java 堆内存的动态弹性伸缩，节约 Java 进程实际使用的物理内存占用。

• 最小实例数配置

配置弹性伸缩最小实例数建议大于等于2，且配置多可用区 VSwitch，防止因底层节点异常导致实例驱逐或可用区无可用实例时应用停止工作，保证应用整体高可用。

• 最大实例数配置

配置弹性伸缩最大实例数时，应考虑可用区 IP 数是否充足，防止无法新增实例。可以在控制台 VSwitch 处查看当前应用可用 IP，若可用IP较少考虑替换或新增 VSwitch。

• 弹性到达最大值

可以通过应用概览查看当前开启弹性伸缩配置的应用，并及时发现当前实例数已经到达峰值的应用，进行重新评估其弹性伸缩最大值配置是否合理。若期望最大实例数超过产品限制（当前限制单应用50实例数，可提工单反馈提高上限）

• 可用区再均衡

弹性伸缩触发缩容后可能会导致可用区分配不均，可以在实例列表中查看实例所属可用区，若可用区不均衡可以通过重启应用操作实现再均衡。

• 自动恢复弹性配置

当进行应用部署等变更单操作时，SAE 会停止当前应用的弹性伸缩配置避免两种操作冲突，若期望变更单完成后恢复弹性配置，可以在部署时勾选系统自动恢复。

• 弹性历史记录

SAE 弹性生效行为当前可通过事件进行查看扩缩时间，扩缩动作，以及实时，历史决策记录和决策上下文可视化功能，以便衡量弹性伸缩策略的有效性，并在必要时进行调整。

• 弹性事件通知

结合钉钉，Webhook,短信电话等多种通知渠道，便于及时了解弹性触发状况。

 最后分享一个采用 SAE 弹性伸缩功能的客户案例，在 2020 新冠疫情期间，某在线教育客户业务流量暴涨 7-8 倍，硬件成本和业务稳定性面临巨大风险。如果此时采用传统的 ECS 架构，客户就需要在非常短的时间内做基础设施的架构升级，这对用户的成本及精力都是非常大的挑战。但如果采用 SAE，用户 0 改造成本即可享受 Serverless 带来的技术红利，结合SAE的多场景弹性策略配置，弹性自适应和实时可观测能力，保障了用户应用在高峰期的业务 SLA，并且通过极致弹性效率，节省硬件成本达到 35%。

综上，弹性发展方向上，尤其是在 Serverless 场景，更强调应对突发流量的能力，其目标在于无需容量规划，通过指标监控配合极致弹性能力实现应用资源的近乎按需使用且整个过程服务可用。SAE 通过对弹性组件和应用全生命周期的不断优化以达到秒级弹性，并在弹性能力，场景丰富度，稳定性上具备核心竞争力，是传统应用 0 改造上 Serverless的最佳选择。

原文链接
本文为阿里云原创内容，未经允许不得转载。