1.3.1　Serverless的技术创新

Serverless基于事件驱动的架构，它的编程模型和运行模式简化了开发模式，融入了不可变基础设施的最佳实践。

1. Serverless是事件驱动架构的延伸

Serverless更容易实现事件驱动的应用。在分布式系统中，请求/响应的方式和事件驱动的方式都存在。请求/响应是指客户端会发出一个请求并等待一个响应，该过程允许同步或异步方式。虽然请求者可以允许该响应异步到达，但对响应到达的预期本身就在一个响应和另一个响应之间建立了直接的依赖关系[1]。事件驱动的架构是指在松耦合系统中通过生产和消费事件来互相交换信息。相比请求/响应的方式，事件的方式更解耦，并且更加自治。例如，在图片上传后进行转换处理的场景，以往需要一个长时运行的服务去轮询是否有新图片产生，而在Serverless下，用户不需要进行编码轮询，只需要通过配置将对象存储服务中的上传事件对接到函数即可，文件上传后会自动触发函数进行图片转换。

Serverless架构的基本单元从微服务变为函数。微服务的每个API的非功能属性有差异，比如对性能、扩展性、部署频率的要求并不相同，进一步拆分的确有助于系统的持续演进，但相应会带来指数级的服务数量增长，导致微服务的基础设施和运维体系难以支撑。Serverless架构可以将微服务的粒度进一步降低到函数级，同时不会对基础设施和运维产生新的负担，只是增加了少量的函数管理成本，相比其带来的收益这是完全可以接受的。

基于Serverless更容易构建3-Tier架构应用。3-Tier是指将应用分为3层，即展示层、业务层及数据层，并且会部署在不同的物理位置。如Web应用，其展示层和业务层在物理层面往往会在一起部署。以图1-9中的宠物商店应用为例，在基于微服务的部署视图中，其业务层和展示层在一起部署；而在基于Serverless的部署视图中，展示层可以托管在对象存储服务中，业务层由FaaS托管，数据层由云数据库托管，实现了3-Tier在物理上的独立部署。同时，各层独立扩展，技术独自演进。

2. Serverless简化了开发模式

微服务提供了丰富的框架，方便开发者进行开发，但同时也增加了开发者的认知负担，同样是使用Java，基于Serverless开发服务，开发者只需掌握Java的基础特性、函数编程框架及BaaS的SDK即可，如图1-10所示。

函数的编程框架相比Spring/SpringBoot要简单很多，开发者只需了解输入输出处理（通常为JSON）及如何处理业务逻辑。如图1-11所示，Serverless系统可以是1∶1的触发模型，每个请求被一个单独的函数实例处理，每个实例可以被视为一个单独的线程，系统自动根据请求数量扩展函数实例，开发者不用理解Java的并发编程也可以轻松实现对高并发应用的支持。

基于函数的编程模型，可以继续对数据进行抽象操作。例如，Azure Function提供的Data Binding功能，允许开发者用一套配置和一种编程模型操作不同存储服务的数据，让开发服务变得更加简单，降低开发人员的认知负担，进而提升开发效率。

3. Serverless是不可变基础设施的最佳实践

Serverless直接以代码方式部署，开发者不用再考虑容器镜像打包、镜像维护等问题。系统通常在部署时重新创建函数实例，在不使用时回收实例，每次处理用户请求的可能都是全新的实例，降低了因为环境变化出错的风险。而这些部署及变更的过程，对用户来说只是更新代码，其复杂度相比使用容器及Kubernetes大大降低。Serverless在扩展性方面也具有优势。FaaS和BaaS对开发人员来说没有“预先计划容量”的概念，也不需要配置“自动扩展”触发器或规则。缩放由Serverless平台自动发生，无须开发人员干预。请求处理完成后，Serverless平台会自动压缩计算资源，当面对突发流量时，Serverless可以做到毫秒级扩容，保证及时响应。

基于Serverless的服务治理也更简单。例如，通过API网关服务可以对函数进行SLA（服务水平协议）设置限流，函数请求出错后会自动重试，直至进入死信队列，开发者可以针对死信队列进行重放，最终保证请求得到处理。

Serverless平台默认对接了监控、日志、调用链系统，开发者无须再费力单独维护运维的基础设施。虽然当前Serverless的监控指标并不如传统的监控指标丰富，但是其更关注的是应用的黄金指标，如延迟、流量、错误和饱和度。这样可以减少复杂的干扰信息，使开发者专注在用户体验相关的指标上。