本文分 五 大版本：
1，开通SAE
2，小游戏测试
3，三种部署方式
4，建议和思考
5，总结
测试环境：SAE 2.0公测版
浏览器： firefox 117.0.1
很久之前就听过SAE（Serverless App Engine）大名了，是一个全托管、免运维、高弹性的通用PaaS平台。第一印象是低门槛，零改造支持容器化上云，但个人觉得过多的封装，导致维护开发层面的灵活性不够，用惯了黑屏kubectl等维护ACK的话，在SAE上使用就有点束手束脚了。这次推出的升级版本2.0 ，强调极致弹性、标准开放、简单易用，这三大功能。对于新兴业务以及一些小白用户或者创业的公司更加友好，省去了自建平台，重复造轮的步骤，实现开箱即用，一键上云。
那我们开始测评下。
一，开通SAE
开通试用
建议使用试用权益。
公测版本信息，可以点击体验。
授权角色服务后，点击创建应用
开通非常简单。
二，小游戏测试
按教程指导，创建游戏应用，指定游戏代码仓库。
配置完成，点击应用启动
一直在启动中，等了约10分钟，一直处于启动中。
后来点击右上角的启动应用，设置了实例范围，才算启动成功。
应是漏掉了教程里的 容量设置。
当实例未设置数量时候。
直接访问公网链接，报错，提示信息不够明显。
{"ErrorCode":"ResourceExhausted","ErrorMessage":"Function concurrent request count exceeded"}。
测试效果：
整体测试流程下来比较丝滑，界面跟函数计算类似，非常熟悉的功能和界面布局。
三，三种部署方式
使用三种部署方式将代码或者镜像推送到SAE上。
（卖个关子：本来是四种，但SAE还不支持第四种，那第四种是什么部署方式呢，具体请看下文。）
1，初始化一个应用demo
直接初始化一个 com.sae.demo的 jar 包项目
本地进行一些简单的代码添加，设置controller,定义个RequestMapping路由 /demo。
调试好代码后，启动正常。
2，使用代码部署-dockerfile方式
SAE只支持Push代码到仓库的事件，后续以此事件触发构建。
先将代码传到个人gitee上。
gitee授权SAE 访问。
关联后直接创建应用，以dockerfile方式构建。
但一直处于创建中，后来查到SAE 以dockerfile构建需要做先编译再做镜像构建。
所以这一步，有问题，一般我们在dockerfile里只定义部署动作，编译和构建动作 是在平台完成的，比如云效Flow，就是这么个逻辑。
但SAE 需要我们在dockerfile里定义好代码编译和镜像构建。
查了下，SAE对Source-To-Image（S2I）的过程，使用的是谷歌的kaniko，对dockerfile逐行解析并执行。
重新编辑dockerfile
构建成功，因为没有指定settings文件，依赖都从外网下载，花了13分钟 构建，比较慢。
查看镜像，不大，才75MB。
测试访问正常：
更新代码触发构建
我们简单修改时间为 17:39，看看SAE是否是持续构建的。
18点多的时候，已经构建完成。
因为设置的新版本流量为0，需要手动调整更换版本和流量比例。
查看新内容。
3，使用代码部署-系统自动构建
故名思义是编译构建动作全部交给SAE完成。
建议是先在本地 全部构建一遍，省去不必要的编译依赖麻烦，没有问题再执行系统检测自动构建。
建议删除mvnw文件。
自动检测构建，在构建模块会存在偶发问题，频率不低，构建错误，只能重试。
构建成功
访问正常。
进行代码修改，查看是否触发构建。
构建正常
手动调整流量比例，此时突破了 实例1-10的限制，会生成2个版本各1个实例。
访问，返回新数据
4，使用镜像部署
SAE使用已有的应用镜像创建应用。启动脚本和参数建议在构建镜像时候直接在dockerfile定义。
不过我们得先创建个镜像仓库，此处使用 阿里云的ACR。
仓库建好后，使用flow构建镜像
构建完成，转储到ACR的个人仓库下。
创建应用的时候直接指定这个镜像版本。
测试正常。
监控和通知
SAE 默认使用的是Arms的基础监控，不需要单独设置，包括QPS、RT、HTTP状态码、实例数、CPU和内存使用率、磁盘空间等。一般情况已经够用了。
有了监控我们需要配置事件通知，方便应用有重大变化时，及时感知和介入。
对实例进行了重启，但没有收到钉钉信息。不知道是不是还不支持2.0版本
四，建议和思考
建议1-默认镜像选择可手动修改
建议不要使用灰选，建议可自定义修改，现在需要点击修改镜像 再跳转选择界面，相对复杂了。
可以参考ACK的操作，简单明了。
建议2-不支持codeup
源代码库 竟然不支持codeup，在阿里云生态，应该都需要支持codeup。
因为代码库公司使用不太会变更，涉及变更代价比较大，我们使用云效很久了，如果迁移到第三方，涉及授权和使用习惯还有一堆webhook要改，非常不方便。
建议3-不支持VPC构建
不支持vpc网络拉取镜像，这个镜像是当前账户的CR个人仓库，SAE竟然不支持。
如果走公网，需要一定的公网流量成本和构建延迟。
建议4-界面状态添加
建议 实例界面可以观察到更多信息。
比如 应用有没有启动，启动了多少个，当前访问量等。
每次要看应用状态，都需要一个个点进去，非常不方便。
建议5-日志随时暴露
可以将构建日志暴露出来
还有启动日志，也最好同步输出
目前看启动成功后，没有实时同步展示启动日志。
日志管理中的日志，随着应用启动不会主动显示，有了访问后才有展示日志。
我等了10分钟都没有展示，感觉控制台日志就是随着HTTP访问后才被触发的，建议可以随启动应用实例 进行同时暴露。
有请求才有日志展示。
建议6-bug反馈
当前状态 已经完成第二步流量配置，启动状态等待中。
但此时切到其它界面比如日志管理查看，返回到基础信息界面，还是有1-2s的初始化状态，显示创建中，2s后，再进入到启动应用实例的启动中状态。感觉前端又进行了重检。
建议7-创建失败但进度消失
启动应用实例，一段时间后，创建进度 板块会自动消失，一般实例启动成功才会主动结束创建流程，结果没启动也突然消失了，用户不知所措。
应用实例没有启动成功，也查看不到日志，公网访问错误，应用整体状态也没有反馈透露。
建议，优化这块内容，最好把启动错误信息给暴露出来。然后启动状态也需要反馈给用户。上面这种情况很多人会很无助，因为实例没有启动，状态没有显示出来，但是从监控里看到访问记录却进来了。
查看有错误的访问记录
建议8-降级限流
SAE前端如果没有 WAF 或者MSE-Higress 网关的话，建议增加降级限流 开关。
比如可以设置流控规则，当超过 20QPS的时候，会调用 AHAS服务进行行为管理，比如自定义返回页面，跳转指定页面等。
可以对IP、Header、Cookies等访问特征行为进行拦截，限流等。
还可以进行重写、跨域CORS、失败重试、认证、流量复制等场景
建议9-mvn构建自定义
建议构建 的时候能自定义 构建命令
mvn install 需要指定环境 生成对应的环境版本。
比如，我们编译为测试环境：
mvn clean install -U -Dmaven.test.skip=true -P testing -s settings.xml
我们编译为生产环境：
mvn clean install -U -Dmaven.test.skip=true -P production -s settings.xml
建议10-流量检测
建议增加 流量检测。
类似ACK中，通过存活探针（Liveness）对实例进行存活检测，调用失败就重启pod
通过业务探针（Readiness）对实例进行业务接口检测，准备就绪，就打开流量访问。
目前，看SAE只有健康检查，没有区分存活和业务的功能，有时候应用是需要多个接口关联确认正常后才能打入流量访问。
建议11-构建问题
使用代码构建的时候，不会清理现场，导致构建镜像包 比较大。
源码和产物都在一起，镜像包有271MB，然而同样的代码，我自己本地打的应用包约70MB，相差较多。
没有预热的话，会增加一定冷启动时间。
缓存问题：
4分钟前已经删除这2个文件了，估计是缓存问题，重试了几次还是加载了。
SAE 公测版，构建的时候貌似不会自动清理缓存，构建容器应该是没有重置。
只能 返回到实例基础信息界面，点击停止应用 ，启动应用。
重新启动应用后，git clone下来的代码就同步了，不存在这2个删除的文件了。
建议12-灰度发布控制
建议灰度发布的时候，除了流量模式外，能增加一些请求头header或者Cookie等控制，
流量验证版本的时候不一定方便，范围控制也是问题，使用header就比较方便了，准确找到新版本，验证正常后，将流量打入新版本中，再安排老版本平滑下线。
其次建议能编辑版本，增加说明，方便版本部署，不会混淆。
如果是代码部署的，能从git里获取commit信息那最好不过了。
建议13-事件通知
建议新版本增加 事件通知功能。
比如，构建，部署，流量切换等重要操作有钉钉、邮件、webhook等通知功能。
对公测版本进行了实例的停止和启动测试，没有触发事件通知。
建议14-白名单扩展CIDR
建议尽早支持CIDR地址，目前只支持IP非常不方便。比如前端代理使用的是WAF等有多个变动出口IP，加IP无法解决，如果关联的云产品只提供CIDR的白名单，不知道如何添加是好。
建议15-自适应弹性
自适应弹性，没有 更多可操作指标，比如CPU、内存之类做HPA。
目前只有流量波动做弹性伸缩。
本例，使用AB压测了静态接口100次，和1000次。
压1000次后，才从实例1 弹到2个副本，度过5 分钟平稳期，后再缩回1 副本。
但部分场景 ，尤其是后端逻辑复杂的，长事务性请求的，更需要CPU和内存去体现访问压力，这时候如果不做扩容，服务基本就挂了。
建议16-不支持flow 构建部署
我们代码仓库是Codeup。
Flow可以使用gitee，也可以选择其它代码源，此处使用codeup，跟flow依赖性更好，也省去了授权问题。
云效是支持SAE构建和部署的，但配置后发现只支持老版本，不支持2.0公测版本。
五，总结
通过以上几种简单的构建部署方式，我们可以管中窥豹，大概了解SAE 2.0 公测版的应用接入方式，大家可以选择其中一种，或者几种，结合自己的业务进行使用。
个人是 建议java 技术栈使用 镜像部署，尤其是你们之前有一定容器使用经验的，更加应该使用镜像构建。比如之前在本地使用K8S，使用SAE后，可以平滑接入到阿里云Serverless PAAS平台。
因为环境已经在镜像包里定义好了，SAE 公测版本目前对环境识别上还不是特别好，不支持自定义编译参数，尤其还不支持云效接入。如果使用镜像部署，其实内部不变，更多的是换了个载体，进行微调适配即可。
如果使用源码自动构建 需要很多尝试，建议本地先做好编译和构建测试，再使用SAE。
但总体看瑕不掩瑜，SAE2.0公测版本，使用上还是非常容易入门的，界面简单，创建和发布应用非常快，也支持按量付费。底层全部是容器标准构建，可以一键上云，提升运维研发效率。尤其是弹性伸缩功能，令人印象深刻。我在上面使用ab 压测了1000个请求，SAE瞬间按流量拉起了新的副本，5分钟后又缩容到最低可用副本，后面没有请求，直接缩容到 0 副本，没有业务流量就不需要付费，这对于一些营销热点等新兴业务以及一些创新创业的公司更加友好。
如果你有使用过K8S或者ACK等产品，那SAE2.0 也肯定受你青睐。SAE 是Serverless产品，全程云托管，免运维，弹性伸缩，支持白屏化操作，根据应用健康自动调配流量，可灰度、可观测和可回滚。中小企业可以极速构建云上微服务应用，通过弹性伸缩从容应对突发性流量洪流，灵活启停应用环境降低资源成本。
希望SAE能更加丰富产品功能，丰富S2I的构建能力，提升CICD能力，真正实现一键上云上容器，造福广大中小企业。
