Serverless工作流程

在实际生产中，Serverless架构通常都是FaaS与BaaS的结合，并且具备弹性伸缩和按量付费的特性。如下所示，当开发者想要开发一个项目的时候，通常只需要根据FaaS提供商所提供的Runtime，选择一个熟悉的编程语言，然后进行项目开发、测试（图中步骤1）；

完成之后将代码上传到FaaS平台（图中步骤2）；

上传完成之后，只需要通过API/SDK（图中步骤3）

或者一些云端的事件源（图中步骤3）触发上传到FaaS平台的函数，FaaS平台就会根据触发的并发度等弹性执行对应的函数（图中步骤4），

最后用户可以根据实际资源使用量进行按量付费（图中步骤5）。

Serverless工作流程

来看一个Web应用的例子。如下所示，通常情况下一些Web应用都是传统的三层C/S架构，例如一个常见的电子商务应用，假设它的服务端用Java，客户端用HTML/JavaScript。

传统Web应用三层C/S架构

在这个架构下，服务端仅为云服务器，其承载了大量业务功能和业务逻辑，例如，系统中的大部分逻辑（身份验证、页面导航、搜索、交易等）都在服务端实现。把它改造成Serverless应用形态，简图如下所示。

Serverless应用形态简图

在Serverless应用形态下，移除了最初应用中的身份验证逻辑，换用一个第三方的BaaS服务（图中步骤1）；

允许客户端直接访问一部分数据库内容，这部分数据完全由第三方托管，会用一些安全配置来管理客户端访问相应数据的权限（图中步骤2）；

前面两点已经隐含了非常重要的第三点：先前服务端的部分逻辑已经转移到了客户端，如保持用户Session、理解应用的UX结构、获取数据并渲染出用户界面等。客户端实际上已经在逐步演变为单页应用（图中步骤3）；

还有一些任务需要保留在服务器上，比如繁重的计算任务或者需要访问大量数据的操作。这里以“搜索”为例，搜索功能可以从持续运行的服务端中拆分出来，以FaaS的方式实现，从API网关（后文做详细解释）接收请求并返回响应。这个服务端函数可以和客户端一样，从同一个数据库读取产品数据。原始的服务端是用Java写的，而AWS Lambda（假定用的这家FaaS平台）也支持Java，那么原先的搜索代码略作修改就能实现这个搜索函数（图中步骤4）；

还可以把“购买”功能改写为另一个FaaS函数，出于安全考虑，它需要在服务端而非客户端实现。它同样经由API网关暴露给外部使用（图中步骤5）。

在整个项目中，Serverless用户实际关心的也就只剩下函数中的业务逻辑，至于身份验证逻辑、API网关以及数据库等原先在服务端的一些产品/服务统统交给云厂商提供。

在整个项目开发、上线以及维护的过程中，用户并不需要关注服务器层面的维护，也无须为流量的波峰波谷进行运维资源的投入，这一切的安全性、弹性能力以及运维工作都交给云厂商来统一处理/调度，用户所需要关注的就是自己的业务代码是否符合自己的业务要求，同时在Serverless架构下，用户也无需为资源闲置进行额外的支出，Serverless架构的按量付费模型以及弹性伸缩能力、服务端低运维/免运维能力，可以让Serverless用户的资源成本、人力成本、整体研发效能得到大幅度提升，让项目的性能、安全性、稳定性得到极大的保障。