作者：洛浩
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 将成为云时代默认的计算范式，越来越多的企业客户将会采纳这个技术。
戳此处，返回查看视频解析~