对于云原生解决方案中涉及到的微服务，DevOps，容器云和ServiceMesh等内容，在前面很多文章都已经谈到过，今天准备谈下对Serverless架构的一些理解。

实际上要完全理解Serverless无服务器架构是一件相对困难的事情，包括到现在我的认知里面仍然认为这种架构是无法满足传统IT应用系统的架构转型和迁移的，只能够应用到一些特定的场景。

对Serverless架构基础概念的理解

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

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

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

注：这里必须搞清和容器化paas的区别点，要知道容器PaaS本身也是不用关心服务器的，但是可以看到在Serverless是一种更小更灵活的动态容器这是其一，其次是真正到了服务级别，而不是部署包级别。因为在原来的部署包级别就一定还是会存在编译打包部署，要将部署包部署到类似tomact，jboss中间件的过程。而到了Serverless阶段功能都是FaaS粒度更新，没有打包构建动作，你也不用关系应用中间件。

Serverless由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发， 完全被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录。

关键两类服务-FaaS和BaaS

1.FaaS（Function as a Service，函数即服务）

要理解这个概念，首先还是要说明下传统的一个软件应用功能是如何开发和交付的。

即我们首先是在本地开发环境和IDE里面建设一个项目，然后建立相应的代码文件，编写代码，完成后进行编译构建，形成一个部署包。然后将部署包部署到中间件或容器里面，部署完成后应用就暴露一个访问地址，我们通过该地址访问该应用功能。

那么到FaaS里面是什么概念呢？

首先就是没有了中间件容器的概念，或者说这个容器对你不可见，最终的程序运行在哪个容器里面，或者说中间件容器长什么样子你根本不需要知道。

其次就是没有编译构建动作，对于写好的程序不需要进行编译和构建，打包成一个部署包进行部署，写好的程序即交付到Serverless环境后即可以运行。如果你不需要运行了，支撑程序运行的环境或容器也可以快速的销毁。

再次，我们在本地开发环境写一个应用功能，不可避免都会涉及到类似SSH三层框架，类似SpringCloud微服务开发框架等。但是到了Serverless阶段你可以看到没有很重的开发框架这个说法，也就是说开发框架在FaaS里面不再存在。那么原来你是通过开发框架开发一个应用，这个应用比如有20个功能点，那么到了FaaS这个阶段，对应的就是20个独立的代码片段实现20个功能点。

以上就是FaaS和传统应用的关键区别点。

FaaS意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和PaaS（平台即服务）等其他现代化架构最大的差异。FaaS可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，也不需要全时运行应用程序。

FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS函数就是常规的应用程序。例如AWS Lambda的函数可以通过Javascript、Python以及任何JVM语言（Java、Clojure、Scala）等实现。然而Lambda函数也可以执行任何捆绑有所需部署构件的进程，因此可以使用任何语言，只要能编译为Unix进程即可。

FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS，此类触发事件可以包括S3（文件）更新、时间（计划任务），以及加入消息总线的消息（例如Kinesis）。通常你的函数需要通过参数指定自己需要绑定到的事件源。大部分供应商还允许函数作为对传入Http请求的响应来触发，通常这类请求来自某种该类型的API网关（例如AWS API网关、Webtask）。

2.BaaS（Backend as a Service，后端即服务）

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

BaaS看起来和我们常说的PaaS平台感觉很类似，那么来看下两者的区别。

对应PaaS平台我们看到实际上提供的是应用托管，应用自动部署，后续资源弹性扩展调度能力。即前提是有部署包，再调用PaaS平台的能力将应用部署到托管的中间件和容器里面。这里面有两个重点，即：其一是有部署包，其二是有中间件和容器的概念。

但是到了BaaS可以看到，已经没有编译构建和部署包的概念，对于容器和应用中间件概念也不再有或对开发者不可见。而实际上BaaS需要提供的是什么呢？即代码片段编写完成上传后运行代码片段的能力。

但是实际上单独的一个代码片段本身很难实现一个业务场景功能。

比如我们需要做一个网页抓取功能，那么在实现这个功能的时候可能涉及到图片存储，全文检索，对象存储几个关键技术服务能力。而这些技术能力就是BaaS平台提供，即类似于我们传统PaaS平台里面说的技术服务能力平台。

那么代码片段做什么事呢？即通过代码片段对BaaS层提供的API能力进行组合或编排，这样就可以完成一个简单的业务场景和功能实现。

例如我们看当前亚马逊提供的Serverless服务应用场景图，如下：

可以看到BaaS提供类似网关，消息通知，对象存储等各种技术服务能力，而前端的FaaS通过对这些技术服务能力进行组合完成一个业务功能实现。

在AWS用Serverless创建一个应用一般会涉及到如下内容

1. API Gateway 网关服务，实现我们需要的网络RESTful接口
2. Lambda 函数计算，实现我们需要的平行扩展业务运算
3. Dynamodb数据库，实现我们需要的“单机”无限性能数据库
4. S3服务，实现前端静态页面的存储

通过 Amazon API Gateway，您可以根据在 AWS Lambda 中运行的代码快速、轻松地创建自定义 API，然后通过 API 调用 Lambda 代码。Amazon API Gateway 可以用您的账户执行 AWS Lambda 代码，也可以在 AWS 外部通过可公共访问的 HTTP 端点来调用 AWS Elastic Beanstalk、Amazon EC2 或 Web 服务。利用 Amazon API Gateway 控制台，您可以定义 REST API 及其关联的资源和方法、管理 API 生命周期、生成客户端 SDK，并能查看 API 指标。

Serverless架构适合的场景

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

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

无服务器计算还适合于任何事件驱动的各种不同的用例，这包括物联网，移动应用，基于网络的应用程序和聊天机器人等。这里简单说两个场景，方便大家思考。

场景一：应用负载有显著的波峰波谷

Serverless 应用成功与否的评判标准并不是公司规模的大小，而是其业务背后的具体技术问题，比如业务波峰波谷明显，如何实现削峰填谷。一个公司的业务负载具有波峰波谷时，机器资源要按照峰值需求预估；而在波谷时期机器利用率则明显下降，因为不能进行资源复用而导致浪费。

业界普遍共识是，当自有机器的利用率小于 30%，使用 Serverless 后会有显著的效率提升。对于云服务厂商，在具备了足够多的用户之后，各种波峰波谷叠加后平稳化，聚合之后资源复用性更高。比如，外卖企业负载高峰是在用餐时期，安防行业的负载高峰则是夜间，这是受各个企业业务定位所限的；而对于一个成熟的云服务厂商，如果其平台足够大，用户足够多，是不应该有明显的波峰波谷现象的。

场景二：典型用例 - 基于事件的数据处理

视频处理的后端系统，常见功能需求如下：视频转码、抽取数据、人脸识别等，这些均为通用计算任务，可由函数计算执行。开发者需要自己写出实现逻辑，再将任务按照控制流连接起来，每个任务的具体执行由云厂商来负责。如此，开发变得更便捷，并且构建的系统天然高可用、实时弹性伸缩，用户不需要关心机器层面问题。

具体参考：

https://blog.csdn.net/cc18868876837/article/details/90672971

微服务和Serverless关系和融合

当我们比较微服务和Serverless时，实际上比较的是微服务和FaaS。直观上来看，微服务和FaaS的差别在于粒度，而要实现FaaS，首先必须将单体应用演进到微服务，然后才能进一步地分解到函数级别，实现FaaS。

微服务和Serverless不完全是同一层面的事物，实际上不应该放在一个层面进行比较。

原因就是微服务仍然是传统IT架构演进的一个容易理解过程，即原来传统的单体应用拆分为微服务模块，从数据库，逻辑层都进行拆分，都能够独立自治。拆分后的微服务可以基于容器进行部署和管理。

但是微服务并没有强调传统SOA我们经常说的识别可重用的服务接口，基于服务接口进行应用功能的组装。

在这个意义上可以看到Serverless说成是SOA分层架构思想的进一步演进更加合适。

这个演进过程出现了两个关键点。

• 其一就是共性技术服务能力全部转变为BaaS层的API服务接口
• 其二是前端应用功能开发转化为代码片段和对API能力的组合

以上这两点才是Serverless架构到重点，因此可以说传统架构朝微服务架构演进是顺理成章的一个渐进过程，但是不能说微服务到Serverless演进是平滑的。

Serverless比微服务粒度打的更细，完全到了功能点级，实际上可以看到后续管控运维的复杂度是增加了的，对于类似单一功能APP，微信小程序，定向数据采集等适合，但是对于复杂应用系统暂时不适合。包括我们看到企业内部复杂业务系统，当前转微服务架构本身就已经很吃力。一拆分一定会带来集成的问题，监控运维的问题，事务一致性的问题。

注意对于Serverless不仅仅是无服务器，是整体架构设计的概念都弱化了，同时应用开发框架的概念也随着弱化，没有重的开发框架和底层平台，也没有编译和部署概念。

在已有的API服务能力都用传统方式提供出来后，可以看到对于Serverless更加适合用来做前端应用的组合和轻量级编排，通过FaaS来实现对各类第三方API服务能力的整合完成要给特定功能。

比如你要做一个简单的图像处理程序，那么图像采集，图像识别和匹配，图像存储都可以调用独立的第三方API接口服务来完成。

在Serverless后，可以看到对开发人员技能要求进一步降低，更不需要大家都去做全栈工程师，开发人员也可以花更多的精力来关注业务场景和业务需求的理解和实现。同时在Serverless后也可以看到，小功能的开发和交付周期会更快更加敏捷。

微服务和Serverless相互融合

在前面我们谈到了BaaS层，对于各大公有云服务商来说，提供的BaaS层更多的是类似消息，缓存，对象存储，网关等技术服务API能力接口，而对于传统业务系统需要提供的可复用业务能力接口是服务提供的。

你也可以理解为BaaS可以提供技术中台API，但是服务提供业务中台API。

因此如果你采用Serverless方式来构建传统业务应用功能，你会发现一些业务后端API能力并不具备，在这种情况下你完全可以采用微服务的方式开发业务API服务接口能力，然后暴露给前端FaaS层使用。即我们说的构建方式为：

完整业务应用功能 = 前端FaaS代码组合+（后端BaaSAPI+后端业务微服务API）

通过这种方式，一些简单的业务功能场景我们就可以迁移到采用Serverless来进行开发。但是要做到一个传统IT系统应用全部功能迁移到Serverless仍然相当困难。因为传统IT系统，业务微服务能力往往才是主体能力。

进一步对Serverless架构关键思想理解

首先再回顾下对Serverless无服务器架构的一个基础说明。

Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）、暂存（可能只存在于一次调用的过程中）计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。

过去是“构建一个框架运行在一台服务器上，对多个事件进行响应”，Serverless则变为“构建或使用一个微服务或微功能来响应一个事件”，做到当访问时，调入相关资源开始运行，运行完成后，卸载所有开销，真正做到按需按次计费。这是云计算向纵深发展的一种自然而然的过程。

Serverless无服务器架构的一些关键理解

通过拆分实现对应用基础设施的进一步弱化(中间件，容器，开发框架）

首先可以看到Serverless架构下本身就体现了微服务，而且这种微服务API的粒度更加细，更加小，一个API往往仅仅能够完成一个微功能。因此不再像传统应用必须是一个大的组件模块，实现多个功能并打包在一起。

大的功能拆分为微功能-》微功能本身拆分为无状态的微服务API

在完成了这种拆分后，要实现一个大功能那么就是对诸多的微服务API的的组装过程。

我们还是从传统的云平台说起，在传统的应用开发和云平台模式下，我们开发一个应用还是能够明确的感受到虚拟机，感受到中间件容器资源，同时应用开发必须依托一个很重的开发框架，类似springcloiud，类似传统的ssh框架等等。

但是新架构下可以看到没有复杂的开发框架，也没有重的中间件容器，只有一个个新粒度的微服务API，微功能的实现，这些实现也不存在传统的打包和部署动作。也就是说整个软件的开发过程实现完全的面向服务化，你可以使用第三方已有的服务，你开发完成的微功能也是服务，你呈现给用户的是多个服务的串联和组装。

在这种场景下没有任何的中间件资源需要你去关心和维护，类似传统模式下我们可能需要关心和运维我们的数据库，关心和运维我们的Tomcat容器服务器，我们有复杂的编译构建，打包部署动作，而这些在无服务器架构模式下都没有了。体现出现的是函数或事件，而函数本身也是服务。

传统云平台计费模式的一大转变-真正实现使用次数来计费

这个可以讲是Serverless无服务器架构带来的第二大转变，真正实现按使用次数计费。在传统云平台模式下可以看到，虚拟机或计算资源是固定分配给你了的，即使某天你的业务系统没有任何的访问请求，你也需要给云服务商缴费。

你为何需要固定分配的资源，简单来说还是你拿到一个虚拟机后，你还有很多的应用基础设施需要在虚拟机上安装部署和搭建，比如我们前面讲的中间件容器，网关，基础框架包，应用部署包等。而这些应用基础设施越重就越难以灵活的响应。

而到了Serverless无服务器架构下可以看到应用已经拆分为足够细的微功能或API，而这些微功能的运行本身需要极少的轻量化资源即可，因此我们能够实现对类似动态容器能力，快速申请获取容器资源，使用完成后快速的销毁释放资源。

所以你可以看到实现微服务化，实现FaaS或声明式API编程是走向按次动态收费的基础。

1. Serverless 是真正的按需使用，请求到来时才开始运行
2. Serverless 是按运行时间和内存来算钱的
3. Serverless 应用严重依赖于特定的云平台、第三方服务

对于AWS 官方对于 Serverless 的介绍是这样的：无服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如AWS Lambda服务），客户端逻辑和服务托管远程过程调用的组合。

在Serverless架构下开发人员不再关心底层逻辑

简单来说最早的开发往往会涉及到操作系统，进一步的会涉及到数据库，应用中间件容器，然后是各类的开发框架，而这些在Serverless架构下开发人员不再关心，更多的是关心业务场景和业务功能的实现。

这里的不关心包括两个方面，一个是不会直接去安装部署和配置这些中间件，其次是不用去关心这些中间件或容器运行在哪里？更加不用自己运维这些中间件容器。简单来说，你真正要运维的就是你实现的服务API接口，你实现的事件或函数。

目前业界的各类 Serverless 实现按功能而言，主要为应用服务提供了两个方面的支持：函数即服务（Function as a Service，FaaS）以及后台即服务（Backend as a Service，BaaS）。

而实际上我们看到最难的仍然是在类似数据库等原来的中间件资源能力的服务化，即我们对数据库的需求也变成了一个个可以拆分的微服务API请求。比如我们仅仅是一个爬虫采集后的数据存储这种单一场景往往比较容易实现，但是类似企业信息化系统这种底层复杂数据模型，强关系和强事务场景下往往就很难实现彻底意义上的数据库能够服务化。

正是这个原因我们看到类似Serverless架构前期更加适用于移动互联网，物联网IOT，面向互联网的聚合类应用实现上面，而对于传统企业信息化应用软件至少短期难看很难适用。

传统企业信息化应用转到Serverless

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

我们可以看到，对于SOA架构思想出来很多年，我们早就希望将传统企业内部新和应用的开发基于ESB总线暴露的共享服务能力进行BPEL服务编排来完成，即使这点对于绝大部分企业都很难真正做到和实施。

可以看到Serverless是SOA架构思想应用的极致状态。

由于企业应用本身的业务复杂性，数据关联和耦合性，集成复杂性，事务强一致性要求等。很难真正实现将传统IT应用完全的Serverless化。

那么唯一可行的应用场景，即是我前面谈到的，对于一些简单的功能开发，我们可以基于技术中台和业务中台暴露的API服务能力，进行前端的代码片段组装来完成。但是前提仍然是需要首先开发业务微服务模块，并暴露API服务能力接口。

对于企业内的信息化，在企业传统IT架构转型过程中，重点还是云原生里面的微服务，服务网格和DevOps几个关键能力。即首先是微服务化拆分，其次通过服务网格去中心化，再次通过Devops实现和云端的快速对接和持续交付能力。