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

因此，微服务架构在本质上就是对弹性伸缩有着强烈诉求的，在弹性伸缩的过程中，不管是单应用的水平弹性伸缩，还是整套环境的启停，资源利用率都对最终的资源成本起着决定性的作用。如果能想办法提升资源利用率，就能为企业节省大量资源成本。值得我们重视的是，绝大多数的微服务应用的资源利用率都是非常低的。我们可以做一个简单的统计：把所有服务器的CPU利用率每5分钟导出一次，按照天的维度求平均值，就能从整体上了解系统的资源利用率数据。如果把开发测试环境的服务器资源也纳入统计的范围，资源利用率很有可能会更低。
Serverless化探索资源利用率低的根本原因，在于以服务器为载体的应用架构中，开发者需要将构建好的程序包部署到服务器上，从而对多个用户事件进行响应。为了确保事件响应的及时性，需要让程序长驻于服务器上，而且尽可能保守的规划资源，以避免出现负载过重而导致服务崩溃的情况。在这个过程中，实际的负载在时间上分配并不均衡，从而导致整体的资源利用率偏低。
Serverless技术的出现，为提升资源利用率提供了新的思路。 Serverless是一种构建和管理基于微服务架构的完整流程，允许开发者脱离服务器资源而直接部署应用。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）的计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作服务器资源，真正做到了部署应用无需涉及基础设施的建设。
文章插图
Serverless技术存在多种形态，最典型的一种是FaaS（Function as a Service ，函数即服务），比如阿里云的函数计算（Function Compute ， FC）产品。在函数计算领域，一切计算资源的申请和调度都由具体的业务事件触发，当业务事件所对应的任务完成之后，计算资源会被立即释放。这样的方式真做到了计算资源的按需分配，能显著提升资源利用率，是Serverless技术的终极形态。
另外一种是Serverless化的容器技术， Serverless化的容器实例运行在案例隔离的环境中，每个计算节点通过轻量级虚拟化安全沙箱技术完全强隔离。对于使用者而言，无需购买服务器资源即可直接部署容器应用，也无需对集群进行节点维护和容量规划，可以根据应用配置的CPU和内存资源量进行按需付费。当微服务应用需要扩容的时候，就可以快速获得计算资源，不需要再经过购买服务器这个步骤了，可以帮助开发者降低计算成本，减少闲置资源浪费，平滑应对突发流量高峰。阿里云的Serverless Kubernetes（ASK）就是Serverless化容器技术的代表产品。
更进一步发掘开发者的诉求Serverless技术无缝是云计算和云原生应用架构的发展方向，但对于微服务应用的开发者而言，不管是FaaS形态，还是Serverless Kubernetes ，都存在一定的局限性。
不是每一种业务都适合通过FaaS的方式进行构建，特别是对于链路长，上下游依赖特别明显的应用，根本没有办法进行FaaS化改造。即便某些业务系统的FaaS化改造被证明可行，把现有的微服务架构改造成FaaS架构也需要一定的工作量，并不能做到无缝移植。 Serverless Kubernetes架构虽然能适配所有的业务场景，但对于开发者而言，构建一整套Kubernetes体系，需要掌握一系列跟Kubernetes相关复杂的概念，有着非常陡的学习曲线。而且Kubernetes生态中各种组件的搭建，再加上网络层与存储层的适配，都涉及非常复杂的工作。
造成这种局限性的原因很简单，在以Spring Cloud为代表的微服务技术阵营中，系统的构建都是围绕着应用（也可以理解为单个的服务）而展开，不管是版本更新还是水平扩展，都是针对应用本身。 Serverless Kubernetes架构的核心在于Pod ，比应用更偏向系统底层，所以使用者需要投入更多的精力用于应用下层资源的管理。而FaaS架构的核心在于函数，比应用更偏向系统上层，因此灵活度会降低，不能适配所有的业务场景。