从微服务到ServerLess无服务器架构演进思考

今天再下从微服务到ServerLess无服务器架构的演进过程方面的话题。对于ServerLess我在前面专门写过一篇文章进行说明，自己也专门申请了腾讯云ServerLess环境做了简单验证和测试。具体可以参考下面这篇文章。

你应该了解的Serverless无服务器架构和应用场景

最近1到2年，类似阿里，腾讯，华为各大公有云服务商对ServerLess架构和解决方案推广力度很大，也看了一些垂直细分场景下ServerLess架构下的成熟应用和实践。但是实际上可以看到这些应用场景主要还是集中在互联网应用中，即使在互联网应用中也是一些相当垂直的场景，比如一些基础服务能力整合，数据采集发送，事件响应场景，物联网垂直应用等。

而对于传统企业信息化领域，ServerLess应用很少。

其次，对于一个传统的IT应用系统，可以说对其进行微服务化和架构改造，但是却很难在短期做到完全的ServerLess化。

今天重新谈这篇文章，还是想对ServerLess无服务器架构里面的一些关键内容进一步说明，也方便大家理清思路和要点。

ServerLess无服务器架构

首先我们还是先看下对Serverless的一个基础定义和说明，即：

Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态(Stateless)、暂存(可能只存在于一次调用的过程中)计算容器内。

构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。

在这里我想再强调下里面的一些关键点。

彻底意义上的从资源到服务

实际在谈微服务的时候，我们希望的就是整个云平台不断地向上抽象和上移，从IaaS层资源能力提供到PaaS层服务能力提供。

但是实际在应用开发过程中，并没有完全做到对资源层的隔离，比如一些自研的基础组件开发和部署，一些数据库资源部署，我们仍然还在申请类似虚拟机资源，然后自己进行部署和管理。也就是说没有做到完整意义上的对资源层透明。

而到了Serverless阶段，那就是必须做到完整意义上的服务化，你能够看到和使用的只能够是通过API网关暴露给你的API接口服务能力，对于资源层可以做到彻底意义上的不关心。

所以对于Serverless无服务器化这个词，无服务器化可以理解为无资源化，即你不直接面对资源层，你面对的都是服务能力，去订购和消费使用API服务能力。

去重的开发框架和组件依赖

对于Serverless可以理解为微服务的进一步拆分，即将微服务实现的各个能力全部拆分和解耦，每一个服务能力变成无状态的API接口能力，这些API接口能力就是一个个的可以通过脚本来实现的云函数，构成了Serverless架构中的FaaS层。

传统架构，即使微服务架构仍然可以看到有比较重的微服务开发框架，有共性底层技术组件依赖等，而这些在Serverless下全部都应该去掉或者转为由云平台统一提供。

简单来说如果共性基础框架这层不去掉，上层就不可能彻底的函数化。

彻底的无状态化

为何彻底函数化困难?

除了前面谈到的有一个共性的技术框架依赖外，另外一个关键点就是各个方法和函数之间的调用往往存在状态，需要做类似会话保持等相关动作。

一旦方法间存在状态，那么实际每一个方法或函数功能的实现就无法做到完全的自我管理，这个不论在前期部署，后续的弹性伸缩，高可用等各种场景中你都需要去考虑状态保持的问题，那么整体架构又变得复杂。

因此在Serverless不断在强调事件驱动，强调无状态，强调任何一个接口调完就结束，这个结束不仅仅是不保留状态，包括承载FaaS函数实现的轻量无状态容器也可以做到快速的销毁。

所以你也可以看到无状态化是实现Serverless能够按调用次数进行计费的一个关键。要实现这个按次计费就必须做到资源层的快速启动，创建，快速的扩展，销毁等各种能力。

从微服务到ServerLess无服务器架构

实际上将微服务和ServerLess无服务器架构进行对比，或者将ServerLess作为微服务后续的发展趋势并不合理。

基于上图可以看到。

ServerLess无服务架构实际是整个云平台的重心不断上移，从资源到服务层能力不断抽象的一个过程。

那么微服务在哪里?

微微服务实际可以理解为PaaS层发展的第二个阶段。对于PaaS层的第一个阶段仍然是单体应用和传统的基于虚拟机进行应用调度和托管的PaaS平台，同时类似数据库，消息等技术服务能力也不足够成熟。

而随着云原生技术的发展，特别是云原生中的微服务，容器技术也在不断发展。公有云PaaS平台发展到了围绕容器+技术服务为核心的云原生PaaS平台。在这个过程中传统的单体应用为了获得更好的性能和可扩展性，也转变从单体拆分为更小的微服务。

这个发展阶段可以参考下图：

我们可以将整个演进过程分为三个阶段。

在传统单体架构阶段，往往只会使用到云平台提供的虚拟化资源池，提供弹性计算和弹性存储能力。应用自己申请虚拟机，然后安装环境，管理环境。同时应用在开发完成后也是人工来完成将测试通过的版本部署到虚拟机环境中去。

而到了云原生PaaS平台阶段，底层的资源池变成了更加轻量化的容器，同时上层的单体已经拆分为了多个独立松耦合的微服务，中间件PaaS层实现两个能力。

其一是类似K8s实现的容器资源编排和调度;其二是实现共性的技术服务能力提供，其中包括了数据库，消息，缓存等各种技术服务能力。

为了更好地衔接上层微服务和底层容器云资源，可以通过DevOps持续集成和交付最佳实践和工具集的整合，来完成整个从需求，开发，测试，集成，交付过程的全面自动化。也就是说整个编译，构建，打包，部署的动作全部由DevOps过程自动完成。

到了ServerLess阶段，实际看到又带来如下变化。

其一是底层的容器变成无状态化容器，更加轻量，也更加容易快速创建和销毁;其二是上层的微服务能力进一步拆分为各个独立，无状态的云函数或服务;其三是PaaS层的技术服务能力进一步增强，构建完整的BaaS层。

BaaS(Backend as a Service，后端即服务)是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件(而不是进程内的库)来提供服务。

传统企业应用迁移到ServerLess思考

在现阶段，Serverless主要应用在以下几个场景。首先在Web及移动端服务中，可以整合API网关和Serverles服务构建Web及移动后端，帮助开发者构建可弹性扩展、高可用的移动或 Web后端应用服务。

在IoT场景下可高效地处理实时流数据，由设备产生海量的实时信息流数据，通过Serverles服务分类处理并写入后端处理。另外在实时媒体资讯内容处理场景里，用户上传的音视频到对象存储OBS，通过上传事件触发多个函数，分别完成高清转码、音频转码等功能，满足用户对实时性和并发能力的高要求。

无服务器计算还适合于任何事件驱动的各种不同的用例，这包括物联网，移动应用，基于网络的应用程序和聊天机器人等。

我曾经提到如下观点：

对于传统企业信息化应用来说，由于本身业务规则和逻辑实现复杂，同时存在大类的流程，数据，应用功能间的协同和集成。在这种场景下，转到完全的Serverless架构基本没有任何的可能性。

在这里想转换下思考方式，即对于传统企业信息化应用，如果要迁移到ServerLess无服务器化架构需要做哪些准备。

对于这个问题，我准备分几个点来思考。

第一：BaaS后端即服务能力仍然是传统方式构建

在这里再次强调下对于BaaS后端共性服务能力提供这块，仍然是采用传统架构或当期的微服务架构方式来提供。

当我们一说到Serverless架构的时候，很容易将思考重心放在FaaS云函数这层，其原因是在当前的公有云服务下，类似存储，数据，消息等各种BaaS后端服务能力都是云平台在提供。但是当前去开发企业级应用的时候，这个BaaS后端服务含义变化。

即BaaS后端服务不仅仅是技术服务，也包括了共性业务服务能力。

如果还是用中台这个词，你可以理解为企业共性的业务中台和数据中台提供的共性服务能力也是BaaS后端服务的重要组成。

也就说你要开发企业级应用，那么先得把BaaS这层做好，否则寸步难行。

第二：彻底的无状态化开发模式

在前面已经谈到，Serverless架构是一种彻底的无状态化架构模式。比如你原来本身就是采用的类似事件驱动架构在开发，那么转移到Serverless相当容易。但是如果你原来更多的都是大量长周期事务，大量的状态保持场景，那么整个迁移就相当复杂。

无状态开发类似SOA架构思想里面的服务组装和服务编排，也类似于基于消息事件机制的事件链编排模式。但是核心都是无状态，你需要通过其它方式，比如类似token传递来保持状态，通过消息机制来暂存状态等。

第三：面向服务开发而非面向资源开发

这个也是我在前面就强调的点，如果后续要转移到Serverless架构模式，那么你现在所有的开发指导思想都应该是面向服务而非面向资源。

你不要再去考虑申请订购虚拟机或容器资源，你需要考虑的是将你的技术需求转换为对技术服务的需求;将你的业务需求转变为一个个独立的无状态功能函数。

在前面我就谈到如果你现在上云过程中，都还是在自己申请虚拟机安装数据，安装消息中间件，那么在后期就更难以迁移到ServerLess模式。包括在前面对腾讯云ServerLess简单验证中也可以看到，当你需要数据持久化存储的时候，你不是去申请了一个虚拟机自己安装Mysql数据库，而是在基础服务里面有一个数据库服务，你直接使用这个服务能力来创建数据库集合即可。

对于所有开发人员来说，面向服务开发是一个相对重要的内容。

第四：开发团队和人员分工

进入到ServerLess无服务器阶段的时候，可以看到开发团队人员往往重新进行分工，这个分工可以看做是当前微服务前后端分工的一个分支。

即一个团队专门来做BaaS后端服务这层，这个团队仍然是采用传统方法或者当前的微服务架构来进行开发和持续集成交付。而对于另外一个开发团队则面向应用和用户，面向后端提供的API接口服务，这个开发团队完全可以由当前的前端开发人员来组成。

也就是说在后端BaaS服务稳定后，对于新应用的创建更多就是前端应用，FaaS云函数的编写，前端开发人员可以更加关注业务场景和规则的实现，更多的是去组装和组合BaaS层已有的业务服务和技术服务能力来满足各种需求。

可以举个简单的例子。

对于传统的OA办公自动化场景里面，当组织，权限，人员，流程这些共性的后端服务能力具备后，对于前端各种类似请假单，出差申请单这种功能的开发是完全可以实现云函数化的。这个时候前端应用的开发更类似于当前的低代码开发平台完成的事情。

原文地址：https://mp.weixin.qq.com/s/0o2VJj9E9AC4LV4Eacmfxg