从“预见”到“遇见” — SAE引领应用步入Serverless全托管新时代

从“预见”到“遇见”

SAE引领应用步入Serverless全托管新时代

——黛忻

阿里云SAE产品经理

近年来，随着互联网的普及，企业数字化发展越来越快，技术架构也经历了几度更迭。尤其是在线业务部分，企业最初的需求是将业务尽可能在线化，于是产生了早期的单体应用。即便今天，如果有想法需要快速落地、试错，单体应用依然是最为推荐的方式。

随着在线业务复杂性的增加和访问的增长，逐渐演进到分布式应用，前端加上负载均衡，后端引入消息缓存等中间件，数据库开始分库分表，才最终得以应对流量的增加。

随着云原生时代的到来，企业应用也开始面向云进行容器化、微服务化的构建。过程中产生了进阶式的变化，主要是应用的开发设计、应用的交付以及线上运维的变化。

服务架构的演进为开发者带来了便利，同时也带来了一定的复杂度。新技术上手门槛较高，容器和微服务是两个典型的拦路虎。在框架选型、服务治理 k8s 运维方面缺少经验，短时内也无法储备专业人员。此外，即便微服务化和容器化之后，企业依然需要关注服务器的配置，人工评估容量和服务器的运维工作，同时还会面临高性能和稳定性的挑战，因此无法享受云带来的最大便利。

而 Serverless 的出现带来了跨越式的变革，为企业数字化转型带来了更多机遇。在此模式下，服务器和操作系统的管理部署、运维、资源分配和缩容能力等全部由云计算厂商提供，计算能力真正像水电煤一样被便捷地提供。它能够将原先在传统应用环境中的通用能力转化成云服务，客户可以低成本、高效力地触达。

Serverless最重要的价值可以归纳为三点：

① 通过基础设施解耦、极致的弹性和故障自动处理等提供永远在线的服务，无须担心宕机。

②  通过高效的研发框架以及DevOps 新形态，做到秒级市场响应。

③  抹平了头部互联网公司与传统企业之间技术竞争力的代差，让传统企业面临大量技术升级和重构时，能够从容不迫，不会出现人才缺口，甚至能够弯道超车。

   企业在上云过程中，如何接入 Serverless？

   阿里云提供了一款继 FaaS 形态之外的面向应用的 Serverless 产品——Serverless 应用引擎，简称SAE。 作为业界首款面向应用的Serverless产品，它提供了全托管、免运维、高弹性的使用体验，能够让应用上云更加开箱即用，支持开源的微服务、定时框架以及 web 应用全托管，并提供了开源侧的增强和企业级的特性。

 

上图为产品的功能架构。

SAE 的底座是基于阿里云的沙箱容器 2.0 和 IaaS 的基础资源层，提供了平台托管的开发集群，帮助用户屏蔽了IaaS 和复杂的 k8s 运维。

在此之上，SAE 提供了三大核心模块：

① 应用管理提供了整个应用生命周期的管理和多种发布策略，还具备冷启动加速等先进的技术竞争力。

②  在开源Spring Cloud和Dubbo 基础之上，提供了阿里巴巴近十年来的微服务最佳实践。在开源基础上，额外提供了微服务的无损上下线、限流降级、全链路灰度、服务鉴权等高级特性。

③  提供了运维配套和企业级增强等能力，比如自动弹性、权限隔离等。

基于以上核心能力，无论是Spring Cloud 应用，还是批处理类型的应用，或是 PHP 等多语言的应用，都可以直接通过 war包、jar包、php zip包或 Docker 镜像等方式直接部署到 SAE 上，且能够享受 SaaS 类服务集成的体验。

此外，在开发者工具方面也做了良好的集成，比如能够无缝对接Jenkins、Terraform、Serverless Devs 等开发者工具，为开发者提供非常好的体验。

SAE 的核心竞争力主要包括四大部分:

①   零代码改造。无论是微服务应用还是单体应用，或是开源的定时任务框架，都可以无缝迁移到 SAE。同时降低了用户使用 k8s 的门槛，支持代码包部署。

②    弹性效率。能够提供 15 秒的极致弹性效率，让应用端到端地快速扩容，应对突发流量。

③    降本提效。基于 SAE 一键启停的能力，能够实现多套环境按需启停，降本且提效。

④    启动效率。 SAE 联合 Dragonwell突破了 Java 冷启动瓶颈，使得 Java 冷启动的效率提升了40%。

因此，可以说SAE 覆盖了应用上云的完整场景，让企业上云更加开箱即用。

Serverless 微服务作为当今业界非常火热的名词，较为广泛的定义为：CI/CD 流水线，加上内置的高效能研发框架，再加上屏蔽基础 IaaS 层或 k8s 底座，并且提供了端到端的可观测能力，以及一些自动弹性和流量治理服务。

而阿里云的 SAE+MSE 可以称作 Serverless 服务的最佳实践。基于SAE ，以应用为中心，在 SAE 的应用启动过程中内置 MSE的agent ，即提供了一整套微服务的能力。加之其底层天然屏蔽了 k8s 底座，提供了一套无服务器的架构，因此可以将 SAE+MSE看作 Serverless 的最佳实践。同时能够做到 100% 拥抱开源并回馈开源，因为 MSE 团队做了大量开源步道以及在开源基础上做了非常多增强。

基于这套 Serverless 微服务的最佳实践，能够使开发效率提升70%，成本降低60%。

SAE 的弹性能力不同于 ECS或 k8s 的弹性，它的弹性指标更丰富，弹性策略更灵活，主要提供了三种弹性策略。

① 基于基础监控指标和业务监控指标出发的水平伸缩：比如在开源的开发基础之上额外增加了面向业务层的弹性能力，比如QPS、RT、TCP的连接数等，基于这些业务指标来精准地实现弹性，整体弹性容量的预估会更加精确。一般适用于有突发流量或点击脉冲的场景。

②  基于定时时间段触发的水平伸缩：可以设置何时开始扩/缩容，扩/缩容到多少实例。同时，SAE 提供了白屏化的操作，相比于自己使用开源的 K8S 再装一个 HPA Controller 更简单。

③  基于定时弹性和指标弹性混用的弹性策略（业界首款）：很多客户的业务都有潮汐特性，且会伴随流量突发，比如视频直播等场景。因此，我们提供个 了基于指标弹性做兜底，再针对固定时间段的流量峰值叠加定时弹性作为增强的方案，既保证整个弹性的灵活度，又极大满足了用户使用体验，只需要配置一次规则即可满足所有需求。

电商类、新零售、互娱行业等往往会出现一些不可预期的突发流量。以往一般通过提前预估峰值，按照峰值保留 ECS 资源来应对，但时常会出现容量预估不准，导致资源浪费或不足的情况，更重要的是会影响系统的SLA 。

而采用压测工具加SAE 的方案之后，可以根据压测结果精准地设置弹性阈值，与ARMS 的实时监控指标做对比，系统会自动进行扩缩容操作，无须再做容量的规划，极大节省了硬件成本，实现了秒级的弹性效率，得以轻松应对峰值大考。在紧急情况下，还能够通过限流降级的杀手锏来避免应用雪崩。

SAE 提供了高效闭环的 DevOps 体系，它完整地覆盖了从开发态到部署态到运维态整个闭环过程。它提供了三种企业级 CI/CD 持续集成解决方案：

① 无缝对接开源 CI/CD 工具 Jenkins：通过内置的 Maven 插件，可以完成从source code 到构建到整个部署的完整过程。它能够支持war包、jar包和镜像部署等几种模式。

②  云上功能最全的 CI/CD 方案：它与 Jenkins 的区别在于，可以将代码直接托管到云上，由云效来完成代码托管。还能够做到代码侧的安全管理，可以定制流水线，提供完整一致的构建运行的环境。它的功能比较齐全，一般适用于中型规模的企业。

③  最轻量、最易用的 CI/CD 方案：通过镜像仓库和阿里云的容器镜像服务来完成SAE 的部署。它的轻量在于通过 webhook 将代码仓库打通，在容器镜像服务上定制一些构建镜像的规则和触发器的规则，即可完成在代码提交时自动构建和部署的过程。如果使用企业级的容器镜像服务，它还能实现镜像的安全扫描、防漏洞、全球多域分发等能力。

此外，还可以将SAE 和 ECS 混部，将 ECS 作为常态保有的部分，SAE 作为弹性资源池，混部方案主要适用于两种场景：

场景一：从 ECS 陆续迁移到 SAE 的中间过渡方案，能够提升迁移过程的稳定性。

场景二：将SAE 完全作为弹性资源池作备用。此方案需要保证同个应用的 ECS 实例和SAE 实例都能挂载到同一 sob 后端，并设置好权重比例。如果是微服务应用，还需注册到同一个注册中心。此外，客户也需要做一些适配。

若要复用客户自建的发布系统，需要保证每次发版时 SAE 的实例和 ECS 的实例版本一致；若复用客户自建的监控系统，需要将 SAE 的监控数据和 ECS 的监控数据整合在一起。流量高峰到达时，弹性模块会将弹性实例弹到 SAE 上，极大提升了弹性扩容效率，也降低了成本。

SAE 拥有三个重磅新特性：

1.  支持 Terraform。

作为国内外大客户首选的云上工具，Terraform 的价值在于基础设施及代码，它能够自动配置基础设施，帮助企业以更高速度、更低风险、更低成本实现云应用程序的开发、部署和扩展，极大提高了自动化运维的效率。

这一点在 SAE 落地过程中也得到了非常好的体现。在没有接入Terraform 之前，开发人员需要通过控制台或者云上来部署 SAE， 不仅需要理解每个 Open API 的定义，还需要清晰地知道多个SAE Open API 之间是否存在互斥关系，是否有串行调用的行为，极易出现线上风险。

而接入Terraform 之后，开发人员无须理解 API 代码的形式，只需将所要管理的资源定义在模板之中即可，操作 SAE 的资源更加安全，对接 CI/CD 以及接到 GitOps 也会更加简单。更重要的是，它还提供了资源编排能力，能够一键式部署 SAE 以及依赖的其他资源，从 0 到 1 来完成建站，效率大幅提升。

因此，SAE 拥抱了 Terraform 生态，无疑为开发者带来极大的便利。

2.  提供了 PHP 的一站式应用托管。

PHP 作为最流行的服务器编程语言，牢牢占据榜首位置近十年，全球 82.8% 的网站都是基于 PHP 来开发。

大多数开发者通过市面上常见服务器的运维面板来图形化地运维管控应用。但这些面板存在不少痛点：

第一，只能支持单机的运维，缺少集群的管理，需要逐台操作运维；第二，缺少应用侧的监控能力，应用上云需要自研 APM ；第三，流量突增时，弹性效率无法保证；第四，某些 web 应用的静态文件比较大且更新频繁，如果通过ECS 全量部署，需要耗费1-2分钟，前端体验非常差。

针对以上痛点，SAE 提供了免运维、高弹性、无缝集成 APM 监控的 PHP 全托管服务。在框架方面， SAE 支持了 Laravel、ThinkPHP、Wsoole 等流行的框架；在运行环境方面，支持在线应用架构的LNMP 架构，默认提供了PHP+FPM+Ngins 的配置。此外，虽然 SAE 的底座是 K8s ，但在产品侧支持 Docker 镜像和 PHP zip包的部署，大大降低了用户的使用门槛。

SAE 的 PHP 应用托管功能矩阵也颇为丰富，比如开发调试类的上传/下载、内置 Xdebug 等，运营时的弹性伸缩、APM 等能力，还能够通过NAS/OSS独立管理静态文件和目录。有了上述能力，可以非常好地支撑 PHP 的几个典型场景，比如静态站点的部署、远程调试、多站点部署，比如存量的ECS 或者宝塔面板的应用往SAE 迁移。

3.  SAE Job正式邀测。

SAE Job功能主要针对以下几个方面的痛点：

① 异步任务和在线业务通常采用混部的方式，资源共用，稳定性差，SLA 得不到保证。

②  成本偏高，资源利用率低，任务结束无法立即释放资源。

③  任务失败后需要人工重启，运维效率低，且企业需要为此付出非常多人力资源。

④  缺少可观测性和报警，对于任务的失败与成功缺少可视化的明细，失败后无法及时予以报警通知。

基于以上痛点，SAE 提供了全托管、免运维的任务处理平台，能够使开源的 XXL job 等任务框架0改造迁移，且深度地融合了微服务的生态，兼容开源的k8s。

上图为 SAE Job 的功能架构图，底座依然是基于平台提供的全托版k8s，帮助用户屏蔽IaaS 和 k8s 的运维。在此之上提供了任务管理界面，其中包含大量功能矩阵，提供了任务模板的能力以及任务启停的能力，能够详细记录每个任务执行的状态，且在开源 XXL job 的基础之上提供了一些高级特性，比如分片、监控报警、支持单机广播并行计算，能够支持任务幂等以及失败重试等。

上述丰富的任务管理界面，可以通过 war 包、jar 包或 Docker 镜像将任务部署到 SAE 上。能够支持几种调用方式，比如通过 Open API 、SDK的方式，或在Event Bridge 侧编辑触发器来直接部署到SAE。

SAE Job 适用于以下几类场景：基于时间驱动的定时任务，比如整点发优惠券、更新收益；批量数据处理、按月统计报表等实时性要求不高的场景；异步任务解耦场景，比如更新一些活动的状态，异步实现离线查询，与当前的业务逻辑做解耦。

SAE Job 与开源 XXL job 相比，较大的优势在于能够深度融合微服务生态。有些任务在启动过程中需要依赖一些微服务，比如查询产品中心，更新产品的变化，再投递到第三方，过程中与微服务有比较多交互，而 SAE 提供了统一的入口和统一的界面，使得客户微服务与 job 调用的诉求得到了非常好的满足。

综上，SAE job 对于客户的价值能够归结于以下4 点：

① 高可用：任务运行失败后能够自动重试，得到自愈。

②  免运维：基于 Serverless 架构，提供了免运维和高弹性的特性。

③  节省成本。

④  开源增强特性：比如与微服务生态的集成、任务分片等。

SAE 作为面向应用的Serverless产品，体现了云原生先进技术的完美融合，将容器化微服务和Serverless 的最佳实践完美融合在一起，提供了开源微服务、开源的任务框架和单体应用的Serverless 全托管，能够实现“来了就用，功能齐全，用完即走”的效果。