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

一剂良药：容器化技术为了解决这两个难题，开发者们尝试了各种各样的方案，新的理念以及技术框架在过去的这五年层出不穷。在一轮轮的优胜劣汰下，以Docker为代表的容器技术，在Kubernetes生态的支撑下，在业界成为了主流，是构建云原生（Cloud Native）应用的必备要素。容器化相关技术能够更大程序的挖掘云计算的价值，在一定程度上帮助开发者解决这两个难题。
在应用生命周期管理以及服务治理方面， Kubernetes提供了比较完善的实现机制，通过构建Deployment资源，配合proStop和postStart脚本，能比较方便的实现滚动发布以及应用的优雅上下线。虽然在灰度发布的过程中，依然没有办法直接对流量进行精细粒度控制（引入ServiceMesh技术能增强流量控制力，不在本文讨论范围），但相比简单的发布脚本，已经有了飞跃性的提升。
在应用的水平扩容与缩容方面，通过容器化技术可以极大程度的减少操作系统安装以及系统级初始化的时间，但购买虚拟机的操作是无法避免的，所以在系统遇到流量增突的时候，依然没有办法实现快速水平扩容。
我们可以预留一部分计算资源，放在资源池中，当应用有扩容需求的时候，就向资源池申请资源，当业务负载下降的时候，再把多余的计算资源归还到资源池中。
文章插图
这其实并不是一个好主意，每一个计算资源都是需要成本的，资源池虽然能够解决计算资源快速投入使用的问题，却造成了巨大的浪费。另外，到底规划多大的资源池，也是一件很伤脑筋的事情，池子越大，造成的浪费就越大，但池子太小，又可能满足不了扩容的需求。
资源成本更深层次的分析可能有的开发者会认为，目前的业务运行非常的稳定，在用户流量上并不存在明显的突增，所以扩容和缩容是一个伪需求，在将来也不会有这样的需求。这可能是对互联网业务的一种误解，因为完全没有扩容需求的情况是不存在的。
首先，只要一个系统是为人服务的，就必然存在波峰和波谷。对于一个7*24小时运行的系统，不可能永远保持同样的用户流量，二八原则对于很多业务系统依然适用（80%的用户流量集中在20%的时间段。即便是用户流量相对平衡的系统，在凌晨也存在流量的低谷，如果能更进一步的释放闲置计算资源，提升资源利用率，就能显著的降低资源使用成本。
文章插图
另外，相比生产环境，开发和测试环境对于扩容和缩容的需求会更加迫切。一套微服务应用由不同的团队进行开发，在理想的情况下，多个团队会共享一套测试环境：
文章插图
然而，每个团队对于应用的迭代都会有自己的节奏，与此同时，他们又想拥有独立的端到端测试环境，从而实现环境之间的隔离，以避免团队之间的相互影响。这样的话，很有可能会形成多套测试环境：
文章插图
随着应用、团队、业务功能点数量的增加，所需要的开发测试环境数量还会成倍的增长，造成巨大的资源浪费。对于测试环境的计算资源而言，资源利用率要远低于生产环境。有的时候仅仅是一个简单功能点的验证，为了端对端的跑通业务功能，又避免团队之间的相互影响，就会开启一套包括全部微服务应用的新环境。这样的资源浪费，对于很多企业，都是一个多年都未曾得到解决的难题。