通过Serverless技术降低微服务应用资源成本( 四 ) 前言在大型分布式IT架构领域

对于使用主流Spring Cloud体系或Dubbo体系构建微服务应用的开发者而言，如果需要引入一种方案降低资源成本，他的最终诉求一定包含两个方面：
1、能否0改造成本，或者接近0改造成本。 2、能否适配所有的业务场景。
应用层Serverless技术是否有一种介于FaaS和Serverless化容器之间的技术，可以实现上述重要诉求呢？当然有，这就是以阿里云Serverless应用引擎（SAE）为代表的应用层Serverless技术。
文章插图
图：不同层级的Serverless技术
SAE实现了Serverless 架构 + 微服务架构的完美融合，对于Spring Cloud和Dubbo等主流的微服务架构，可以实现无缝兼容，基本上没有改造成本，并真正按需使用、按量计费，节省闲置计算资源，同时免去 IaaS层运维方面的工作，有效提升开发运维效率。
以Spring Cloud应用为例，如果需要部署一个新的应用，只需要2个步骤：1、告诉SAE这个应用需要多少个实例，并指定每个实例需要的CPU/内存规格。 2、上传应用的JAR包/WAR包，并启动应用。
我们发现，这2个步骤中并不涉及容量评估、服务器购买、操作系统安装、资源初始化等工作，就能让包含多个对等实例的微服务应用运行起来。这是因为在Serverless的世界中，不再具有服务器资源这样的概念，应用的载体是SAE调度出来的沙箱容器，每个实例只有在真正投入使用后，才会按使用时长进行计费。
对于开发者而言，他们不用关心应用到底部署在物理机里面，还是虚拟机里面，或是容器里面，也不需要知道底层的操作系统是什么版本的，只需要关注每个应用实例占据多少运算资源就可以了。如果应用需要从4个实例扩容到6个实例，或者缩容到2个实例，只需要一个指令就可以完成，甚至与SLB的绑定关系，都可以自动的建立或解除，这是Serverless技术为开发者带来的巨大价值。
使用SAE部署微服务应用，因为只是变更了应用运行的载体，所以可以100%的兼容现有的技术架构和业务功能，迁移成本可以忽略不计。
SAE的极致弹性能力除了手动的扩缩容指令， SAE还支持2种自动弹性机制，可以对微服务应用进行灵活的水平扩展，更进一步的发挥云计算的弹性能力。
1、定时弹性机制：对于会预期发生的周期性行为，可以设置定时弹性策略。举例：如果每天的上午9点是业务高峰，可以定时每天8点半增加实例数量，并在9点半减少实例数量。 2、基于指标阈值的弹性机制：对于超出预期的业务流量突增，可以设置基于指标阈值的弹性策略，根据CPU、内存等资源指标，以有QPS等业务指标让应用实现自动的弹性缩。
通过多种弹性机制，能够对系统容量进行精细粒度的管理，使资源的使用量能随着业务流量的变化而调整，从而极大程度的增加资源利用率，大幅降低资源成本。
文章插图
在计算资源的调度和启动上， SAE做了多项优化，对于扩容出来的新实例，只需要几秒钟的时间就能拉起，这项能力对于一些需要紧急快速扩容的突发场景，是具有重大意义的。
对于开发测试环境而言， SAE的机制弹性能力能体现得更加淋漓尽致，得益于SAE出色的资源调度能力，可以一键启停一整套微服务应用。即便仅对一项简单的新功能进行冒烟测试，也完全可以新启一套完整而隔离的测试环境来进行。新的环境可以在秒级搭建完成，快速投入使用，而测试完毕后，又可以立即释放。从成本上来讲，一套新环境实际投入使用的时间很短，因此只会消耗极少的费用。这对于微服务应用开发过程中的多团队协作，是一个巨大的变革。