作者：洛浩
Serverless 应用引擎的组件架构
最早的时候，大家设计软件一般按照单体架构，包括和软件相关的数据库，存储等，会直接部署到一台物理服务器上。但是单体应用的问题在于，随着企业的规模逐步增大，扩展性较差，发布效率非常低。后来，就进入了微服务时代，微服务主要用的框架是基于 Java 语言。微服务架构的一个优势在于迭代效率非常高，扩展性也比较好，但是微服务对资源的占用和成本相对较高。随着技术的演进，容器化加速了微服务的落地。但并不是所有的企业都适合微服务，随着系统复杂性的提升，微服务的效率，运维成本也在增加。企业选用单体架构，还是微服务取决于系统的复杂程度。
随着公有云的发展，越来越多的用户会把业务部署到云上。随着云的使用深度越高，架构的优势也就越明显。第一阶段叫 Rehost，就是重新托管，使用云主机替换本地物理服务器，不改应用，但是这种托管模式是最基础使用云的方式，它的效率并没有达到最大化。随着进一步的发展，我们需要 Re-platform，使用托管的云服务替换自建应用基础设施，基本不改应用。但 Re-platform 也不是最好的一种方式，随着进一步的发展，我们可以重新去架构这个应用，即 Refactor。这个时候，可以用微服务加容器的方式，重构底层架构和软件架构，把云的价值发挥到最大。从长期来看，整体的收益是最大的，但是短期内它的迁移成本要求也是比较高的。
如果应用能够按照云上原生的产品或服务进行重构开发，就能够最深的享受云计算的便利性。但与此同时它有几个问题：
- 投入成本（迁移/改造）；
- 云厂商绑定程度；
- 云的易用性（上手门槛/维护）；
- 安全性。
阿里云推出了 Serverless 应用引擎（SAE），专门针对应用或者微服务，提供一个全托管的平台。比如 Java 微服务，目前可以做到零改造迁移部署到云上，并且支持完整的微服务治理能力。如果用户想做容器化升级，也可以使用这个平台。
Serverless 应用引擎的核心技术
SAE 由哪些组件构成？是怎样把各种产品能力结合到一起的？可以看下这个组件架构。图中绿色部分，是用户需要关注的，是各种各样的业务应用。同时，SAE 会提供各种工具，比如 Cloudtoolkit 插件辅助本地代码部署到云端，比如对接云效提供流水线能力。图中橘黄色部分，就是 SAE 平台，会提供很多种能力。比如说写了一个商城应用，前台就是一个独立的服务模块，可以单独迭代、开发或者管理。还可以给前台服务配置弹性策略，例如在大促期间，前台服务可以根据实际流量自动弹性伸缩，这个也是 SAE 的一个核心价值。所以 SAE，既可以提供资源管理能力，又能提供应用生命周期管理、微服务治理，是一个全托管式的应用平台。在资源层面，SAE 封装了K8s 集群，K8s 之下是基础设施，由神龙服务器和安全容器构建，SAE 在资源层面，会帮助用户提供资源管理和调度能力。
接下来讲一下 SAE 的核心能力。首先，我们先看一下传统企业用户部署应用的整个流程，首先是需要购买 ECS 资源，然后搭一个集群，对集群进行初始化，然后构建环境。研发开发完成后，开始进行测试部署，另外还要去部署监控、日志等组件。等业务全部上线后，就进入维护状态，包括资源的运维和业务的运维。而使用 SAE 可以省掉很多步骤，首先底层的 K8s 集群由云厂商来维护，用户只用提交镜像或者 JAR 包，就可以把系统部署到 SAE 平台。其次，监控和日志系统，这些已经由平台提供，用户只需要关注业务逻辑，不需要去维护资源。
如果用户想要做灰度发布该怎么办？SAE 也给用户提供了单批、分批、金丝雀等发布策略。让部署到平台上的业务能够做到不停机更新，这个能力也是默认就提供的。
关于用户诉求非常强烈的金丝雀发布，SAE 可以以做到按请求内容灰度 ，和按流量比例灰度。比如要做流量比例灰度，分批发布直接 50%，两批即可发完。同时，也可以按照精准的流量比例进行灰度。
用户使用这个平台也会非常关注弹性能力，而 SAE 提供了非常丰富的弹性配置。可以基于基础监控指标（CPU、Mem）和业务监控指标（QPS 、RT）来触发水平伸缩 。按照这种负载模型去做弹性扩缩容，一般比较适用于突发流量、或者有典型脉冲的应用场景。比如互联网游戏，社交平台。第二种是定时弹性，这种模型比较适合像餐饮，出行这种有波峰波谷的应用场景。
那么弹性效率能不能跟得上弹性诉求呢？正常情况下，当我们把一个镜像部署到平台，系统要经过一个资源调度，然后创建 POD，拉用户镜像，创建容器，启动容器等几个步骤。为了提升这个效率，SAE 首先针对应用做了原地升级能力。就是针对应用升级发布，可以直接在原有资源上，直接拉用户最新的镜像进行更新和部署，避免重建 POD，从而帮用户提升了 42% 的部署效率。
其次，SAE 还做了镜像加速能力，能帮用户提升 30% 的弹性效率。也就是在用户在创建容器的时候，会同步按需去拉取用户镜像，可以降低服务启动时间。
第三，SAE 针对 Java 应用的启动也做了加速。提供的 Dragonwell JDK版本，可以在 JVM 和进程启动的时候，生成缓存，再应用二次启动的时候，进行加速，缩短启动时间。
最后，SAE 会给用户提供这种监控和应用诊断能力，可以查询服务的调用链、接口的响应耗时、GC 次数、慢 SQL 等，帮用户快速定位问题。
Serverless 应用引擎的最佳实践
微服务/应用迁移到 SAE，大概有几个步骤。首先如果是单体，可以直接打一个压缩包，部署到平台上来，但是单体应用需要做存算分离，也就是数据库和计算代码分离开，把计算部分部署到 SAE。微服务应用可以选择写一个 docker file，做成镜像，然后推到镜像仓库，即可完成部署。微服务应用也可以选择打成 JAR/WAR 包直接部署到 SAE。
关于降本方面，SAE 也推出了一键启停功能。针对不同的环境，可以开启定时起停应用。比如对于测试环境，在晚上没人用的时候，就可以把测试环境直接关掉，来节省成本。
SAE 提供多种工具和方法来构建 DevOps 体系。比如大部分企业用户常用的 Jenkins，或者选择云上的云效等来做 CI/CD。在应用侧，可以在 SAE 平台配置定时启停、监控告警等完成业务运维。
关于企业用户比较关注的环境管理和权限划分，SAE 推荐使用命名空间，来做环境的隔离，不同的命名空间下的应用是不能互访的。另外，SAE 推荐使用权限助手来给不同的团队，生成对应命名空尽或者应用服务的权限策略，最终做到不同团队之间的应用，相互不可见不可操作。
还有的用户会关注 SAE 和 ECS 比，做了哪些能力增强呢？首先是提供的这种免运维全托管能力，其次是一站式的全应用生命周期管理能力，以及针对微服务的治理和优化、应用监控等，都是 SAE 给用户提供的增值体验。
Serverless 应用引擎的客户案例
第一个 Timing app，是在教育领域的在线课程学习 app，它是典型单体应用重构成微服务，迁移到 SAE 平台。随着疫情的发展，Timing 的流量激增之后，原有架构难以承载业务的发展，开始做微服务改造。在微服务化的过程当中选了 SAE 平台，像用户中心，学习中心，自习中心、图书馆中心等等，都被拆成独立的服务模块。对比使用云主机自建微服务的方式，大约节省 35% 成本。
另外想要分享的案例是爱奇艺·体育，其整个业务都部署在 SAE 平台上。在今年 6、7 月份的时候，爱奇艺·体育转播了欧洲杯赛事，当时的流量非常高；但是体育赛事结束之后，流量又开始回落，因此弹性能力对其尤为重要。而 SAE 丰富的弹性能力，可以帮助节省大量的运维开销，扩容效率比之前提升了 40%。其次内置的应用监控平台，在业务遇到问题的时候，排障处理效率也提升了 30%。整体上 SAE 帮助爱奇艺·体育还提升了近 50% 的资源利用率。
相信随着云计算的发展，Serverless 将成为云时代默认的计算范式，越来越多的企业客户将会采用这个技术。