分享人｜竞霄
直播地址：0 基础晋级 Serverless 高手课 — 云原生体系下 Serverless 弹性探索与实践
本篇内容将从四个部分为大家介绍云原生体系下Serverless弹性探索与实践。
- Serverless时代的来临
- Serverless弹性探索
- Serverless弹性落地
- Serverless弹性最佳实践
一、Serverless时代的来临
Serverless顾名思义是一种无服务器的架构，是云计算时代的一种架构模式。Serverless架构能够让开发者在架构应用的过程中无需关注计算资源的获取和运维，从而降低运维成本，缩短上线的时间。
在Serverless架构下，开发者只需要关注上层的业务逻辑开发，而如Server的资源申请、环境搭建、负载均衡、扩缩容、监控、日志、告警、容灾、安全和权限等，都可以交给Serverless平台来关注。
1. Serverless的4大特性
在云原生架构白皮书中对Serverless的特性有4点概况，分别是：
- 全托管的计算服务，意味着用户只需要编写代码来构建业务应用，而无需关注同质化的、复杂繁重的、基于服务器的开发和运维。
- 通用性，是指Serverless支持所有应用的类型。
- 自动的弹性伸缩，即用户无需为资源进行预先的容量规划，
- 按量计费，可以将企业的使用成本降低，让企业无需为闲置的资源付费。
2. Serverless的发展历史
2012年首次提出Serverless概念作为Serverless发展的起点，到2014年AWS推出Lambda云产品，这段时间内是Serverless关注度最高的阶段，出现了爆发式的增长，对无服务器的期待和畅想引爆了整个IT行业。
但是Serverless的推广和生产落地是不容乐观的，因为Serverless的理念和实操存在Gap，挑战着人们固有的认知和运维习惯。而阿里云坚信Serverless将作为云原生之后非常确信的发展方向，因此相应的推出了阿里云函数计算FC和阿里云SAE
Serverless应用引擎两款云产品，来覆盖不同的用户负载类型来使用Serverless技术，并且不断的推进Serverless理念的普及和发展。
3. Serverless市场概况
基于Forrester Wave FaaS 2021第一季度的调研显示，阿里云Serverless产品能力在整个Serverless市场领域，中国排名第一并且全球领先。另外，信通院2020年中国云原生用户调查报告显示，阿里云Serverless用户占比中国第一，占比比例高达66%，其中35%是阿里云函数计算FC的产品占比，而阿里云SAE的占比高达31%。同样通过这个报告显示，Serverless技术已经被广泛使用到企业的核心业务应用中，包括“已在核心业务应用”、“已在非核心业务应用”、“已在测试环境应用“三种情况占比30%，另外有11%的企业正在研究和学习环境应用。
二、Serverless弹性探索
弹性能力作为云的核心能力之一，它所关注的是容量规划和实际集群负载之间的矛盾。
如下图对比可见，如果使用左侧原来采取的预先规划资源的方式，会产生规划资源和实际使用资源不匹配的情况，并造成资源浪费或资源不足的情况，进而使企业的成本增加和浪费。而右侧极致弹性能力，是资源使用量与实际需求量几乎保持一致，是按需匹配的。这样可以使资源的整体使用率提高，同时避免了资源的浪费，为企业节省了不必要的成本。
弹性能力可以分为可伸缩性和故障容忍性两个部分。可伸缩性是指底层资源可以按照上层指标变化而具有一定的自适应能力。相当于IaaS可以随着流量的增加而相应的增加，反之亦然。故障容忍性是指通过弹性自愈来保证服务和实例处于持续健康的状态，以保持整体的高可用。
以上两种弹性能力带来的价值收益在于降低成本的同时可以提升应用的可用性。一方面，资源使用量贴合应用实际消耗量；另一方面，提升峰值的应用可用性，劲儿灵活适应市场的不断发展和变化。
1. 弹性探索：IaaS弹性伸缩
IaaS弹性伸缩的代表产品是各个云厂商的云产品，如阿里云的弹性伸缩ess。它的整体使用是通过配置云监控，也是阿里云的监控服务，通过云监控的报警规则来出发相应的ecs的增减操作。如当ecs实例整体的CPU大于80%的时候，会相应增加ecs实例；当小于30%的时候，也会相应减少。同时支持动态增减slb后端服务器组。这样可以保证整体架构的稳定性。
Ecs作为IaaS的基本单位，弹性伸缩能力使其能够伸缩规则自动增减，并提供健康检查功能实现弹性自愈能力。
用户的使用流程是：
- 创建伸缩和伸缩配置（弹性伸缩的基本单位为相同应用场景的ecs实例的集合及关联slb和rds）
- 创建伸缩规则（基于定时任务/告警任务实现，具体分为简单规则、进步规则、目标追踪规则和预测规则）
- 监控查看弹性执行情况
2. 弹性探索：kubernetes弹性伸缩（水平）
Kubernetes水平弹性伸缩代表产品是原生的k8s hpa以及所对应的托管云产品，比如阿里云的容积服务。k8s作为面向应用运维的基础设施和Platform for Platform，提供的内置能力主要是围绕着容器级别的管理和编排来展开的，而弹性能力聚焦于对底层pod的动态水平伸缩。它的原理是k8s hpa允许pod中监控数据，并将它们与对应的期望值做比较，然后通过内置算法来算出期望的目标实际数，然后再来指导操控对应的工作负载，来改变实际数实现不断进行弹性伸缩的流程。
用户的使用流程是：首先创建workload，然后创建hpa（配置指标源和弹性策略），再然后事件查看弹性执行情况。
3. 弹性探索：应用画像弹性伸缩
应用画像弹性伸缩主要是应用于互联网公司内部，比如阿里的容量平台。容量平台提供容量预测服务和容量变更决策服务。如下图所示，它会预先通过odps大数据能力，对这个有应用的监控指标数据和实际数据进行预处理，然后生成应用的画像数据，这里画像分为基准画像、弹性画像和大促画像，再然后通过容量平台进行变更管控、故障熔断和画像准入等。具体的容量平台执行vpa的具体操作，然后再指导具体的odps不断的学习。这样就形成了一个闭环的操作。
用户使用流程是：
- 应用接入
- 生成容量画像（基于历史数据/经验，生成大促画像、弹性画像和基准画像）
- Metrics指标修正画像
- 监控查看弹性执行情况
通过上面的介绍可以看到，应用画像弹性伸缩和前两种的弹性伸缩差别比较大，它是以画像驱动为主、Matric驱动为辅的一种弹性伸缩能力。它的目标是不断修正用户画像，从而使用户画像不断的来与实际情况吻合。
4. 弹性探索：弹性模式对比
三种弹性产品从弹性伸缩功能模式上抽象来讲基本相同，都是由触发源、弹性决策和触发动作组成的。
触发源，一般依赖于外部的监控系统，它可以对节点指标和应用指标进行采集处理；弹性决策一般基于周期性轮询并算法决策，有部分基于历史数据分析预测以及用户的定时策略。触发动作是对实例进行水平扩缩，并提供变更记录于对外通知。
在此基础上做场景丰富度、效率、稳定性的竞争力，并通过可观测的能力提升弹性系统的透明度，便于问题排查和指导弹性优化，同时提升用户的使用体验和粘性。
以上是三个弹性产品的相同点，下面来介绍下不同点。
IaaS弹性伸缩作为老牌的弹性伸缩能力，沉淀时间长、功能强大且丰富。但是云厂商间能力区域同质化，而且与各个云厂商的IaaS产品强绑定，弹性效率相较容器受限。
Kubernates弹性伸缩，作为开源产品通过社区力量不断优化迭代，弹性能力和最佳实践更符合绝大部分开发运维人员的诉求。但是它需要对于弹性行为和api进行高度抽象，可扩展性不强，无法啊支持自定义的需求。
应用画像弹性伸缩，是阿里巴巴集团内部的特色产品，可以根据集团应用现场和弹性诉求进行设计，更聚焦于资源池预算成本优化、缩容风险和复杂度等痛点。缺点是不易拷贝扩展，特别对外部中小客户不适用。
从终态目标来看，可以看出公有云和互联网企业的发展方向不同：
互联网企业往往由于其内部应用具有显著流量特征，应用启动以来多、速度慢，且对整体资源池容量水位、库存财务管理、离在线混部有组织上的诸多诉求，因而更多的是以容量画像提前弹性扩容为主，基于Metrics计算的容量数据作为实时修正，其目标是容量画像足够精准以至于资源利用率达到预期目标。
公有云厂商服务于外部客户，提供更为通用且具有普适能力，并通过可拓展性满足不同用户的差异化需求。尤其是在Serverless场景，更强调应用应对突发流量的能力，其目标在于无需容量规划，通过指标监控配合极致弹性能力实现应用资源的近乎按需使用且整个过程服务可用。
三、Serverless弹性落地
1. Serverless应用引擎简介
Serverless应用引擎实现了Serverless架构+微服务的完美结合，支持多种微服务框架、多种部署渠道（UI、Jenkins/云效、插件等）、多种部署方式（war、jar、镜像），核心场景主要面向在线应用：微服务应用、web应用和多语言应用。
Serverless作为云计算的最佳实践、云原生的发展方向和未来的演进趋势，它的核心价值在于快速交互、智能弹性和更低成本。在这个背景下SAE就应运而生了。
SAE是首款面向应用的Serverless平台，支持Spring Cloud、Dubbo、HSF、web等主流应用开发框架。用户可以零改动将应用部署到框架上，并且是按需使用按量计费的机制。当下是按照CPU Memory来进行按量计费的，可以充分发挥Serverless的优势，为用户节省闲置资源成本。同时体验上采用了免运维的方式，用户只需要聚焦于核心业务逻辑开发上，无需关注如有应用生命周期管理、微服务管理、日志、监控等等运维层面。
下图是用户视角的SAE架构图，通过此图可以看到，它支持各种应用类型。
SAE后端分为两层，上层是应用管理层，有应用生命周期管理、多发布策略、弹性伸缩、应用监控、一键启停和Dragonwell；下层是微服务治理层，包括服务注册发现、配置管理、负载均衡、优雅下线、限流降级和服务安全等。
底层是平台提供的Kubernetes集群，SAE给用户部署的应用实际就是映射到k8s中的对应资源里。SAE的多组能力是通过系统隔离、数据隔离、网络隔离和服务隔离等一系列隔离来实现的。为的就是让多个用户跑在一个k8s上。
2. 弹性效率：分析
对SAE应用的整个生命周期进行数据化统计和可视化分析，可以看一下下图最上面的整体应用启动。也就是pod创建分为几个流程：
首先是调度，即把某个应用调到某个具体的node上；
然后是init container创建，比如监控组件通过init container进行预拉取，然后再进行部署；
其次是拉取用户镜像、创建用户容器、启动用户容器&应用和应用运行。
通过上图不同流程对应的颜色条的长短，可以看到不同流程环节所用耗时的长短。显而易见，应用创建耗时集中在三个环节：调度、拉取用户镜像和应用冷启动。
- 调度，当前会执行打通用户VPC操作，由于该步骤强耦合于调度，本身耗时比较长且存在创建时间长尾超时、失败重试等情况，导致调度链路整体耗时比较长。
- 拉取用户镜像与解压镜像的时长，特别是在大容量镜像的部署情况下尤为突出。
- 应用冷启动，由于SAE存在大量单体和微服务的Java应用，Java类型应用往往启动依赖比较多，加载配置慢，初始化过程长，导致冷启动速度达到分钟级。
以上三个耗时长的环节，是否有可能优化或跳过调度阶段、拉取用户镜像使用缓存和避免冷启动流程呢？针对这几个问题，有如下解答。
3. 弹性效率：原地升级
SAE在初期采用滚动升级策略，即新创pod后销毁老pod，以这种+1和-1方式进行升级。而原地升级，是只更新pod中一个或多个容器版本，而不影响整个对象对于容器的升级。对比滚动升级来看，原地升级的pod还是原来的pod不变，只是将内部某个container的镜像给换了。
通过原地升级的能力，给SAE带来了诸多价值，其中最主要的就是避免了能力重建，从而使整个部署耗时从原来整个pod的生命周期，缩短到现在只需要拉取、创建和启动用户容器，弹性效率提升了42%。
同时因为无需调度，所以可以实现预先在Node上缓存镜像，提高弹性效率；也可以保持IP不变，避免因IP变化导致依赖组件如注册中心感知延迟；最后可以减少重建Pod对调度器、注册中心和业务上下游的压力。
一方面借助阿里开源OpenKruise原地升级的能力提升应用整体部署效率；另外一方面将云产品SAE实践经验回馈开源，共同打造通用标准的无状态应用负载的大规模使用实践。
4. 弹性效率：镜像预热
镜像预热包括两种形式，一个是调度前预热，一个是调度中预热。调度前预热SAE会对基础镜像进行混村，即每个节点对于基础镜像都已完成预拉取，这样就避免了从远端拉取。另外对于分批场景，在原地升级能力的基础上，可以在调度中进行运作。因为原地升级node是不变的，在第一批部署之后，余下的几批是在那个节点上就直接在那个节点上拉取镜像，这样在部署这个节点的时候可以做到预拉取，进而实现拉取用户镜像和调度，这其实是并行的措施，可以通过这个技术将弹性效率提升30%。
5. 弹性效率：镜像加速
镜像加速是解压镜像。传统容器运行中需要将全量的计划进行下载后后再解压。然而容器启动中实际上往往只需要一部分内容，不需要全量拉取，这就导致容器的启动耗时比较长。
标准镜像采用的是tar.gz格式，无法随机读取。镜像加速功能实际上是将镜像自动转化为一个加速镜像，即带自定义索引支持随机读取的镜像。然后这样就可以实现整个镜像的按需加载和在线解压了，这样就大幅度的提升了应用的分发效率。同时借助acr内部仓库的P2P镜像分发能力，实现无需从远端而是通过用户自己的节点进行啊去镜像，这就大大提升了整体的效率。
6. 弹性效率：Dragonwell 11
对于Java应用冷启动慢的痛点，SAE联合了Dragonwell 11增强了CDS使用加速策略。阿里巴巴Dragonwell 11是一个Java gdk的开源版本，它对原有的open gdk进行了增强。
首先介绍一下什么是AppCDS，它的全称是App Class Data Sharing，即数据共享机制。通过这个技术，可以获取到应用启动过程中依赖的Class list，并把它当成一个共享文件，这样在下次启动时候可以通过这个共享文件来完成。
映射到SAE部署场景，应用启动初次是需要启动一遍，然后就会生成对应的缓存文件，缓存文件保存在NAS中，然后在下一批或是重启应用的时候就可以用这个缓存文件了。借助这个方式，整体的冷启动效率可以提升45%。
7. 弹性效率：自动扩缩
上面介绍了应用的生命周期优化，这里再介绍下对于弹性组件的自动扩缩进行优化。整个弹性伸缩包括了几个步骤，首先是弹性指标获取，其次是弹性决策，最后是执行扩缩操作，即POD创建。
基于此，弹性组件自动扩缩进行了哪些优化呢？
首先是流量透明拦截方案。对于四层指标已经达到了秒级；对于七层指标，借助流量透明拦截方案来实现七层指标的秒级获取。同时，对于弹性决策，采用了多队列并发reconcile，实时监控堆积，延时情况来实现整个自动扩缩的可决策。
8. 弹性能力：架构
下面介绍一下SAE整体的弹性能力。
SAE弹性伸缩包括强大的指标矩阵策略配置以及完善的通知告警机制和全方位观测能力，支持多种数据源，通过数据源提供的监控或应用监控指标，都可以作为弹性伸缩的输入。
对于弹性组件进行拉取或是预处理之后执行具体的弹性策略。弹性策略也有很多种，比如整体快扩快缩，或是只扩不缩，自适应伸缩等等。
除了伸缩弹性策略还有自定义的精细弹性配置。自定义惊喜弹性配置是指，可以在整体的上下限最大和最小配置值，以相应指标区间维持稳定状态。或是直接大于某个区间上限再扩，低于某个区间的下限再缩等等。
采集周期和聚合逻辑，支持定时策略。通过弹性配置策略和自定义的弹性配置，就会触发具体的弹性行为。在执行动态切流来保证整体的弹性过程中所有实例访问状态都是正确的，以及后面的伸缩通过告警能力能够把伸缩情况通知到具体的负责人。全方位观测能力对于整体的决策时间、决策上下文所用记录等等，都可以实现可监控。
上述的弹性能力，支持多个场景。下图所列的四个常用场景分别是：定时弹性、指标弹性、符合弹性和自身弹性。
定时弹性：
定时弹性比较适用于应用负载流量周期比较固定的情况，用户可以预先按时间和日期配置应用。定时弹性多应用于传统的行业，如证券、医疗、政府或是教育等。
指标弹性：
指标弹性可以配置指标值，然后会使整个应用的指标稳定在用户配置的指标值规则内，并且默认采用快速方式来保证整体的稳定性。指标弹性适用于徒增流量的情况，多用于互联网、游戏或是社交等行业。
混合弹性：
混合弹性是把上述的定时弹性和指标弹性结合，可以配置不同时间、日期等指标规则，可更加灵活应对复杂场景需求。混合弹性多用户互联网、教育或是餐饮行业。同时，对于初通流量的场景，
自适应弹性：
SAE针对流量场景进行优化，然后内部有一个流量增长窗口来不断检测当前流量激增的情况的，它的激增强烈程度如何，然后可以根据强烈程度执行自适应弹性扩缩，并且在原有算法过多的行为中会增加一定的冗余来实现扩缩的效果。
9. 弹性能力：稳定性
稳定性是SAE弹性能力过程中非常重要的一环。它可以保证用户应用在弹性过程中可以按照预期行为进行扩缩，并且保证整个过程的稳定性。SAE弹性伸缩整体遵循了快扩慢缩的原则，通过多级平滑防抖来保证执行的整体稳定性，同时对于这个指标激增的场景借助自适应能力提前实现扩容。
下图是整体的四级平滑机制。一级平滑是对指标的获取周期及每次获取请求的时间窗口和时间窗口内数据的聚合逻辑，都可以进行精细化的控制。二级平滑可以对指标容忍区间的容忍弹性进行配置，也就是区间内不扩不缩。三级平滑可以对单位时间内的扩缩步长、比例和上下限进行配置。四级平滑是可以对冷却时间和预热时间进行配置。
四、Serverless弹性最佳实践
1. 弹性伸缩准备阶段
SAE弹性伸缩可以有效解决剩余流量波峰波谷到来的自动伸缩。首先建议配置应用的监控检查和应用生命周期管理，这样可以保证扩缩工作的过程中整体的应用可能性，确保应用启动。应用生命周期管理，可以配置上下限，比如执行缩容时，应用可能需要执行一些操作，可以通过生命周期管理的对应的接口配置对应的脚本来执行。为避免因弹性不及时，应用启动不及时或应用没有优雅上下线导致服务调用异常，建议采用指数重置机制进行服务调试。
应用启动速度优化，在阿里内部来讲，这是平台为用户提供的一些优化手段。作为用户也可以对应用进行启动优化，其中最重要的是对软件包的优化，比如优化启动时间，减少因类加载、缓存等外部依赖导致的应用启动过长。
2. 弹性伸缩配置阶段
弹性伸缩指标配置比较灵活，支持非常多的指标，如CPU、内存、IO等等。需要根据整个应用的指标属性，是CPU敏感还是IO敏感等，进行一个灵活的选择。然后可以通过技术监控或是应用监控它的历史指标来预估整体的容量负载情况，来了解应用可以抗住多少请求，或是抗住多少CPU内存，以及高负载的情况下，这个应用会有怎样的异常。
另外，因为应用系统比较复杂，它不是单时间而是多系统写作的过程。当一个实数扩的时候会影像上下游，所以建议梳理整个上下游的相关依赖，并配置相应的弹性规则，来确保整个链路都是能够保证可能性的。在配置弹性工作之后，也可以通过晚上可观测手段来不断调试弹性配置。
指标配置这里有个建议，最大值建议考虑每个可能区对应IP是否有冲突，否则就扩不出来了；最小值建议不要保持单实例，建议大于二且配置多个可能区，这样防止某个可能区域有问题，可以迁移到另外一个可能区或是实例。
3. 弹性伸缩过程
在整体弹性伸缩过程中需要注意几个点，比如弹性伸缩是否达到最大值，这个最大值意味着一方面流量预估可能不准，或是最大值配置有问题，也有可能是应用出现了异常，或可能区分布不均衡。可以通过重启来实现可能区的均衡，然后自动回复弹性配置。
4. 弹性伸缩可观测
弹性伸缩可观测是对弹性历史记录进行观测，或是对于弹性实践进行通知。实际上是一种内部报表。
从下图的内部报表可以看到包括Hpa的配置和整体每一次请求的间隔，还有具体的耗时等等信息，在弹性伸缩可观测报表里都很清楚。
对外，阿里也在不断完善这个报表的开发。
上述就是用户从弹性伸缩的最佳实践介绍。
