Serverless 应用引擎 SAE：让应用管理如此简单
内容介绍：
一、降本增效
二、功能场景
三、关键技术
四、客户案例
本次课程的主题是“Serverless 应用引擎 SAE：让应用管理如此简单”，由阿里云智能集团高级技术专家赵庆杰分享。
本次课程看似与AI的关联度较低，但实则与后续对AI应用与学习密切相关。如今AI应用是一个新的领域，需要大量的时间学习，如卷积神经网络、AR大模型等。本次课程内容是非常关键的一部分，包括如何管理存量应用（如非AI应用）以节省时间用到AI应用能力。
本次课程共分为四个部分，即降本增效、功能场景、关键技术与客户案例。
一、降本增效
Serverless场景与成本和人效的关联度很高，如果使用AI可以有效降低成本，提高人效。通过对近几年Serverless年度新增应用数、AI应用占比、微服务占比、应用实例数以及使用AI成本的降幅等几个数据的分析，可以发现很多的企业已经意识到了应将大量的时间放在AI应用上，更多的企业已经使用Serverless场景帮其提高人效以降低成本。
1、Serverless SAE引擎的作用
Serverless SAE引擎的作用非常明显，包含阿里云团队在内，都是从独立的云账号开始做起，一开始可能无需经过任何管控，仅仅以机器为单位进行使用，结果月底发现了巨额的账单，为了降低成本，在删除时删除了标题为test的机器，则可能会产生故障。或者当应用流量大幅上涨时，则需要扩容，可能会在ECS场景下找不到相应的节点，也可能在扩容后对故障未产生预期的有利作用，这会使我们非常被动。SAE引擎可以帮助我们解决这一问题。
如高可用场景，最近也发生了几起故障，但使用Serverless SAE引擎运行的业务恢复非常快，也就是说Serverless SAE引擎帮助业务方做了高可用的建设来达到整体的稳定性。
2、Serverless的价值
Serverless 的价值非常广泛，除此之外还有很多，这里不做一一介绍。总之，我们可以按量付费，弹性伸缩，省事省心，一些复杂没有核心价值或对业务帮助的繁杂的琐事都可以交给Serverless完成，从而把主要的精力放在AI应用或AI的业务价值上。
二、功能场景
Serverless引擎应用（SAE）已经是一款非常稳定、成熟的产品，它的功能面非常多，本节课就其几个关键的、最近更新的功能进行介绍。
1、SAE的优势
首先，SAE是一个包资源的产品，在使用时无需再买单独的机器，也无需再为ECS机器以及其他的一些计算付费。SAE包装使其以实例计费，实例以容器为维度，最小规格可达0.5C，我们的应用只需通过相应的文件编译成镜像即可在SAE上运行。
其次，SAE底层的技术是基于阿里云的基础设施，如神龙物理机，进行了虚拟化的动作吧，还使用了其他的技术，如通过镜像加固来架构实例的启动。
在包装成产品之后，上层应用部分添加了微服务治理，尤其是全链路灰度的能力，这一功能在电商类的场景作用明显，其全链路一起请求会涉及到很多模块，如库存、订单等，链路非常长，如果做发布变的时需要进行灰度，在ECS上可能需要手动进行，但在SAE场景下已经默认集成了这些能力。
此外，在上层应用的模型方面，也就是指何种应用可以在SAE上运行。对于SAE来说，应用不限制业务类型，只要做成相应的镜像，即可在上运行在SAE上。关于这一能力，其与函数计算不同。函数计算需要一定的改造成本，但SAE只需将应用打包成镜像上传即可运行，并且微服务的配套的设施也无需很多的迁移成本，只需与SAE进行高度集成即可。
通过企业反馈以及内部运行得出了一些SAE的数据，可以看到他的启动效率很高，提效明显。
2、SAE的功能
包括低门槛微服务架构转型、应用快速上云、一键启停环境的解决方案、面向大促的高可用方案、CI/CD解决方案、作为PaaS底座被集成等等。我们可以通过开发态从CI/CD的集成（如云效以及自研的应用平台）直接对接应用，在使用一些插件对接完成后，即可通过github提交代码，通过预定的发布流程进行应用部署。
3、SAE安全防护
安全防护的能力是今年全力集成的能力。我们发现大量的应用可能已经存在了一些隐性的自变异的病毒，如近期发生的AK、SKD泄露事件，它们都会导致应用被植入自变异的病毒，应用可能已经在不知不觉间运行了一些挖矿程序。SAE高度集成了安全防护能力，只需一键开启即可使用，帮助我们发现隐藏病毒。
关于安全防护，我们可以从以下几个角度进行：
在我们使用一些开源组件时，尤其是现在的软件大部分哦都使用了开源组件，这些组件可能会存在风险，可能会被漏洞程序侵入，通过SAE安全扫描进行扫描。在发现漏洞之后，SAE提供可一些建设性的漏洞修复方案，包含恶意文件检测或配置风险。只需打开SAE的开关，即可使用SAE集成的安全防护能力。
4、功能详解
（1）应用托管
应用托管是最基础的功能，通过该平台我们可以实现可灰度、可回滚和可观测，这些能力都基于此前进行了改版，目前只完成了一部分用户的灰度。灰度是研发平台是最关键的几个步骤，它的完成与否会极大影响业务整体的稳定性。任何平台都有改进空间，阿里云目前已支持了单批发布、分批发布等等。
（2）全套微服务治理
①无损下线
它与微服务治理能力进行了结合。对于微服务，在下线时如果进行重启必然会影响业务，在消费端结合SAE无损下线即可避免对业务的影响。对于普通的微服务，在服务下线时首先会停机，但在停机过程中由于客户端存在延迟，仍有部分请求传入，这段延迟时间内请求的处理就会受到影响。在结合了SAE无损下线后，在请求上加上了特殊的标签，服务变更会主动通知到消费端，待客户端发现后，上册注册中心即可感知到，进而及时更新列表，保证prestop的无损下线。
②无损上线
它是业界的一个标准方案。如果K8S通过readiness检查进行无损上线，若要自研还需要进行相应的开发，如要对初始化的readiness进行集成，一般是依靠端口检测，但由于微服务应用启用时间太长，我们很难判断内部应用是否启动，如果应用上线过快，整体应用可能会处于不可用的状态。SAE对readiness做了内部的集成，预留了一些接口，无需做任何研发，即可让微服务真正启动，确保readiness检查的正常顺利进行上层应用也无需更多地确认健康状态即可使用。此外，如果应用还未预热，可以通过小流量配置相应的时间，逐步地放大流量，直至应用全线启动。
③端到端全链路灰度
在长请求链路下，请求可能会经过5-6个模块，要控制这个完整的灰度链路，我们可以使用全链路网关在上游对新旧版本进行区分，新的流量可以通过网关打上一个标签，这样全链路均可使用设计好的甬道，即灰度版本的链路。如果没有这项能力，我们可能会有多套环境，如测试环境可能回到多个预发环境，则会造成资源的浪费，在使用全链路网关后，我们可在一个环境内进行多版本的测试或A/B test。
（3）运维配套
①CICD的集成
尤其是应用类的研发平台，它需要与内部系统、Jenkins、阿里云云效进行集成，通过与CICD的集成可以使得整个流程更加平滑。SAE封装了一些插件，只需在Jenkins等上安装（云效上直接加载）这些插件即可使用SAE的CI和CD（自动化部署集成解决方案）的能力，当然还存在一定的改进空间。
②基于请求的弹性能力
对于新研发的Web场景，该场景是基于请求的弹性能力，即缩0。函数计算是基于函数维度，SAE较其力度较大，如应用维度可以基于请求缩0，进而实现实例级别的启动，实现降本，当然要考虑冷启动的时间。
（4）ARMS：云原生可观测平台
SAE与ARMS进行了深度的集成，如基础架构下基础资源的云监控，我们可以使用标准的API接口对接，直接使用Prometheus、Grafana的数据。上层应用中，SAE默认集成了日志采集客户端，只要安装配置相应的插件，即可搜集日志，即可使用日志的告警、监控，以及ARMS、JVM的相关能力。
这里着重介绍ARMS链路。课程中展示了JVM的监控，JVM的多线程的队列会影响性能、内存及应用的启动状态等。对于这些问题的排查，目前的监控就已经细粒度到内存和线程的状态，并且也给出火焰图分析内存的使用、CPU是否存在热点，这些已经默认集成在SAE的控制台上。目前虽然只支持Java，但其他的多语言能力已经在研发过程中了。
三、关键技术
这里分享了今年SAE场景下重点优化的功能。这些功能对于SAE或应用管理非常重要，把更多的时间放到AI应用上，而把不重要的、非核心链路的工作放在SAE上完成，管理节约的时间。除了功能性的优化，还做了实例的弹性、加速，以及系统类的冷启动加速，这里选取了几个重点进行分享。
1、实例的弹性
（1）单体应用百毫秒、微服务2秒
结合了标准的K8S指标，再加上更灵敏的弹性，比开源的延时性更低，当发现指标不满足时，可以进行更快速的扩缩指标，可以通过基础的CPU 、Mem、QPS做设置，也可以做定时特别是秒杀的场景，这一点很多的弹性策略都无法满足，但可以结合定时的场景做这扩缩容。还有混合弹性，即定时加弹性的指标同时扩缩。有一个客户会在每周六的早晨8点做考试类的应用，可能会有几万人参与，但在考试结束后资源可以立马释放，这就用到了混合弹性的策略。在8点定时扩容1000个实例，在用户使用完后再自动地在11点进行缩容。当然，缩容的指标除了定时之外，还可以根据CPU设定比例进行自动的扩缩容。
（2）突破Java冷启动瓶颈，提速40%
针对特定的IDK运行时做加速，即AppCDS技术，目前已经是比较成熟的一项技术，与流行度较高的JDK做了集成，已经在线上运行，可以在SAE控制台上直接选择使用冷启动加速的能力。
2、VPC访问模式加速演进
pod实例在冷启动、应用启动、网卡挂载都非常耗时，特别是VPC或跨VPC的场景，要求插拔应用网卡。在此情境下，我们做了overlay网络，相当于代理的能力，可以加度网卡的插拔。
3、缓存能力
SAE做了四层缓存：基层是物理盘，物理盘之上是本机云盘，可以直接读取云盘的镜像等，云盘之后挂载了NAS或NAS的网盘，最后一层是OSS盘。这些是内部技术无需用户过多关心即可使用相应的Serverless Caching能力，如镜像的加速等。表格展示了目前Serverless存储可以支持的水平，除了做应用层面的管理，还有内部研发的核心竞争力，更多地，与自建的K8S或其他开源的产品相比Serverless caching优势明显。每个自建的产品，如自建的K8S可能面临的问题是，自建的存储、加速能力都需要团队维护，但在SAE场景下进行了默认集成，只需在控制台上一键开启或一键使用，就可以直接使用目前的能力。这也是SAE的核心竞争力。
四、客户案例
目前很多行业特别是互联网类的企业，已经使用了SAE，本节课介绍了高教社使用SAE做应用管理的案例。
高等教育出版社——云原生Serverless改造的探索之路
（1）背景介绍
高教社建设于1954年5月18日，迄今为止已有70年的历史，是一个较为传统的行业，即教育出版，包括普通高等教育、职业教育、继续教育、专业学术类教育，是全国最大的单体出版社。业务覆盖了教育出版、主题与学术出版融合发展、研究与评价，产品有图书、音像制品、电子出版物、网络出版物、期刊、在线教育和数据服务。其中，在线教育和数据服务是在传统的主业基础之进行了很大的探索，推进的数字产品包括新形态教材、数字教材、电子书、有声书、专题资源库、数字课程、虚拟仿真实验等。各种数字产品不断的丰富和扩展，建设了数字出版云平台、实验空间、iSmart、爱习题、高校书苑等平台。这些平台建设的基础上，2021年承担了国家智慧教育平台的建设（国家智慧教育平台分“三横”“三纵”，其中“两横”高等教育和职业教育都由高教社承担），部中又提出了更高的要求。高教社又建设了统一资源中心、统一支付中心、统一安全中心、智能审校等一系列平台，并持续优化。
①高教社数字化现状
在2019年年初，高教社就跟阿里云接洽合作，当时阿里云已经提出了中台战略，在合作伊始，就提出了双中台的概念，即云原生技术中台和数据中台。云原生技术中台以原生云为特色，充分利用原生的能力，把云原生的技术运用到技术中台中。其中蓝色代表对外服务的系统，高教社采用公有云服务提供对外服务，黄色代表的是内部的信息系统，早在2003年就启动了SAP系统的建设，这也是在国内较早采用SAP、ERP的企业。所以内部的信息系统在十几年之前就全部实现了设备的虚拟化。高教社也期望内部的虚拟化走向云原生方向。
内部的虚拟化是指内部信息全部部署在内部的虚拟机上，同样，外部的系统全部部署在外部的虚拟机公有云上。云原生技术建设的是数据中台，把多个系统数据的采集、传输、加工、处理、清洗、治理等一系列的操作合并成统一资源中心。实际上，高教社还未实现数据治理，只是完成了数据的整理，将数据的统一存储、传输、加工集合后建设了数据中台，把管理中心、数字大屏和专题库三个模块统一起来形成了统一资源中心。在统一资源中心之上，高教社在探讨业务是否还可以抽象。
第一个是用户，要把所有的用户统一起来，不仅仅是单点登陆，而是以微服务的方式和SDK的方式把用户中心植入到各个平台中，现在大约有一半以上的系统都接入了用户中心的服务。用户中心提供了统一的登录认证，统一的用户信息更新，用户中心提供了的统一的运营和统一消息，更重要的是，用户中心是以服务的方式对外提供服务，但目前期望和现实还有一些差距。
我们期望所有的平台中不存储用户密码，不存储用户相关的表，只通过用户中心提供服务，这不仅仅是技术的变革，更是一场思想观念的变革。用户中心之上还抽象了统一的支付中心，因为大量的业务系统中存在付款的问题，所有的支付都通过支付中心进行，支付中心与内部的SAP结算系统完全绑定，这也是其中的一个优势。除此之外，还抽象了教材课程考试等产品中心，还提供了实例搜索中心、营销中心、审核中心、智能客服等一系列的中台，以这种能力对外提供服务。
在数据中台之上是建设的业务平台，业务平台要基于技术中台，用户要基于数据中台的用户，业务要能与业务中台抽象结合。高教社在承担国家的平台建设以来，从2021年开始就参加了教育部、公安部的各种网络安全演习，所以对网络安全的要求也很高，因此建设了统一安全中心。所有的平台都是在统一安全中心之下建设的。因此，建设的中台系统和业务系统要实现的就是统一的管理和赋能业务，在建成几个大的中心之后用于支撑各个平台的开发和运维。
②数字化转型遇到的问题
在转型的过程中，高教社也遇到了很多问题。第一，在上云原生之前，有海量的ECS实例，有近千台的虚拟机，对于这些数量庞大的虚拟机管理的难度很大，且运维人员的能力也严重不足，近两年要做的有90个项目、60个供应商，很多运维工作进行了外包，完全不可控，系统的稳定性难以保障。在此基础上，原本是单体应用，服务器的应用也符合潮汐规律，在上班上课海量用户大量涌入，需要快速扩容，而周末访问量骤减，造成资源闲置。单体的应用在扩容上产生了很大的成本。因此，高教社开始探索云原生之路。
（2）探索过程
①云原生的基本思路
高教社的云原生探索之路未涉及微服务改造。谈到云原生改造，可能首先就要谈微服务的改造。微服务改造是一件非常复杂的问题，首先要把目前的主机变成容器，主机的上线变成自动化的部署CICD。这也是高教社云原生的两个主要方向，即K8S的集成和CICD的部署。
②云原生改造路径
高教社把云原生分为了四个层面：
第一，开发云原生。首先，研发云原生，即研发流程要符合devops的理念，而高教社大部分研发人员非内部人员，而是外包给了其他公司，所以devops操作在推广过程中遇到较大的困难和阻力。其次，需要集成的代码检测能力，开发可以交给任何公司开发，但在上线时一定要通过自己的安全检测，所以代码检测能力是高教社的强烈需求。同时，还需要完善代码管理平台，很多开发部署工作源代码的获取存在滞后性，无法区分其内在逻辑，也无法保证获取的代码就是上线的代码。因此，所以要。首先，工具平台需要代码管理、项目管理和文档管理。在开发部署中，最重要的是自动化部署的能力，即需要开发一系列的流水线，使得开发之后的过程可以自动化部署。
第二，计算云原生。它分为三个部分，第一部分是容器化和Serverless化。之前大部分的代码都是使用JAVA开发的，JAVA项目在tomcat和spring bot上有状态，所以第一步就是要把项目做无状态的改造，第二步是服务器的容器化改造。这两个层面，容器化改造相对较为简单，无状态的改造比较复杂，涉及到代码层的变动；第二部分，充分利用SAE的弹性做到自动弹性扩缩容和运维；第三部分，全面的故障容灾，网站的需要监控保障系统的安全，尤其是在重点区域也在探讨跨云的容灾能力。
第三，架构云原生。我们需要微服务的拆分，实现极简的研发加运维的模式。架构云原生是与阿里云合作的统一资源中心的微服务改造。
第四，数据云原生，要把所有的数据存储和历史数据迁移上云。问题有可能比较复杂，如在安全攻防时，网站上出现了码或链接，开发人员会被它传到OSS，但在传小文件时总会把文件传到本地服务器，可能会造成病毒的侵入。所以，数据云原生是改造重点，把所有的数据全部上云。
在实施改造过程中，按照前面的思路，提供了云原生改造、容器化改造的能力，构建了统一的工具平台，实行了基于云效的流水线部署。
③集成云效流水线CI/CD
流程：
开发人员或是开发相关的厂商通过git提交代码之后，首先要对所有的代码进行扫描，扫描完成后，使用云的能力做代码的评审和合并，当然也有可能交给开发的厂商完成。然后把合并情况生成可以发布的分支后，使用代码做编译和构建，构建完成后进行测试验证，再通过人工触发。测试之后先分为三个环境，即测试环境、预发环境和生产环境。测试环境通过后，经人工触发实现编译、构建，实现预发部署。预发部署验证通过后进入生产环境。
好处：
由原来单体部署的没有容灾、扩容成本高、无法满足业务需求的环境变成了可弹性的、简单的部署流水线的开发。如果顺利的情况下，仅需要两分钟。如果不太顺利，也不超过2天。其中大量的时间不是开发的时间，而是与业务方沟通的时间。
高教社云原生改造从2019年开始，图中有20+个项目，每个项目都设定好负责人、优先级、处理能力、需要改造的内容、容器化是否是统一代码、统一存储等。
（3）改造成果
①改造历程
2019年是第一个K8S网站上线之年，我们将其定义为高教社云原生的元年。2020年，开始在技术部门内部做推广，把较好的网站上K8S系统，2021年内部实现了普及。同时，从2021年开始基于云效建设的流水线，启动了云原生改造的计划，也自研了全部的容器化部署平台。2023年，在社内已全部铺开，同时，内部的CICD建设进一步推进，现在有三个人在负责CICD的改造，云原生计划稳步实施。今年，全面推进CRT的建设，云原生也纳入了高教社软件开发的管理规范，发布了高校生内部的软件开发管理规范，发现有几十家供应商的开发操作存在规范性问题，质量无法保障。首先，从制度的方式保障平台的质量，同时制定相应的标准，确保云原生改造的规范化，包括用户中心也要纳入管理考核规范的标准。
②改造成果
到2024年，已经运行了160条流水线，有260个容器在执行相关的操作。
（4）经验分享
①建设了统一的资源中心
高教社与阿里云合作建设的统一资源中心平台源自于高教社原来的内容管理系统，这个系统始建于2005年，也有几个明显的优势。第一，该系统最先提出SOA架构（基于服务的原生架构）；
第二，在2008年提出系统要基于可拖拽的图形化实现系统的架构，在2018年之前就开始探索内容管理系统是否前进一步建设中台架构。在中台架构之上，也启动了云原生的微服务改造。之前系统都是单体应用，平台获得了2021年国家新闻出版总署的出版行业科技创新与师范项目，该项目的特色就在于基于数据中台和业务中台的双中台架构，通过构建统一的数据模型标准、统一的数据采集同步机制，汇聚了高教社的各种数据，同时又借助之后的大数据人工智能相关的平台为数据赋智，为业务赋能。到2022年年底，ChatGPT出现，人工智能爆火，数据中台也为之后人工智能的建设提供了非常大的数据源。
在平台建设的过程中，也有几个问题是原来的系统未解决的。第一，中台数据整体的存储架构未能实现所有的数据上云和快速响应。之前的平台上线多以周记，这次改造的目的就是要平台实现一天内上线，包括对平台的监控、微服务的拆分，平台的服务在double的框架在之上做微服务的开发，平台的devops开发、运维、上线、部署连在一起，即SAE的架构。
通过平台的建设，我们总结了几个经验。
第一，降低服务成本。之前平台上线时需要十几台服务器运行，在微服务拆分后仅需13个微服务应用。13个微服务又分了三个环境，即生产、测试、预发环境，共39个微服务应用。这39个微服务在SAE中的费用大幅下降，这也与国企的项目也有很大的关系，项目意义重大，但实际使用人数较少，仅内部系统在使用。有的服务是对外的服务，应用人数较高，而有的服务使用人数较少，只在数据处理时使用，对这些服务的存储一定程度上是一种资源浪费。
第二，降低运维难度。微服务架构拆分了后，分为了用户中心、产品中心、前端管理、媒体、资源等模块，而各个模块之间相对独立，研发人员在进行维护时只需较小的模块了解即可更新上线，研发难度大大降低。
第三，提升研发效能，规范了流水线的流程，实现了基于云效持续集成发布。
第四，提升稳定性。平台基于SAE的建构之后，当服务故障时可以自动恢复和故障隔离，稳定性进一步提升。
第五，更高的安全保障。在使用SAE或K8S的服务之后，主机层面的安全无需再关心，在阿里云的大门被攻破后，只需要从业务层上做进一步的安全梳理即可。
②建设流水线
流水线的开发过程：
第一步，统一代码管理。因为大部分的代码管理平台都有Webhook的功能，在加了Webhook指令后，代码的提交即可与云效相关联。
第二步，编写Dock file。编写Dock filede的主要应用有JAVA、PHP应用等，有很多样例可供参考，新的项目可以很快复制过来。同时，要配置上传密钥字典，在其迁入云原生后，之前很多项目的代码密钥都写在源码中。
第三步，在上传了代码之后，所有的配置文件都要单独处理，上传配置文件。
第四步，进行配置构建，人工卡点，对代码做Sonar扫描。同时，由项目负责人做代码的评审。
第五步，配置构建物上传。
第六步，完成配置任务的部署。
第七步，部署成功之后，云效平台可以集成多个平台的消息通知，可以通过邮件、短信、钉钉等发送成功的情况。
流水线的优势：
第一，高度的集成化。自动化的流水线通过标准化的代码提交、构建、测试和部署，显著地提高了开发效率，降低了人为失误，保障了软件交付的持续性和稳定性，也可以快速响应市场变化。
第二，强大的集成能力。云效流水线可以无缝集成代码仓库、持续集成和项目工具，优化研发流程，确保信息同步。
第三，灵活的部署策略。包括云效中的灰度发布、蓝绿部署和分批发布等，能够有效降低上线的风险，确保业务的连续性和用户体验。
第四，全面的监控和反馈。云效通过严格的安全控制和权限管理保障代码与数据安全，利用加密和访问控制防止未授权的访问，确保部署透明可控，详细的日志和报告为持续优化提供数据支持。
