UC Berkeley曾犀利断言“Serverless架构将成为云时代的默认计算范例，主要取代服务器计算，从而为客户端 - 服务器时代带来封闭”，在信通院云原生产业联盟所发布的《云原生发展白皮书（2020年）》中，也对云原生发展趋势进行了大胆的预测“应用服务Serverless化，更加聚焦业务的核心价值。Serverless架构作为云原生技术未来的演进方向，无服务器架构技术（Serverless）也从观望逐渐落地，据Gartner的过往预测数据显示，到2020年全球将有20%的企业部署无服务器架构。Serverless将进一步释放云计算的能力，将安全、可靠、可伸缩等需求交由基础设施实现，使用户仅需关注业务逻辑而无需关 注 具体部署和运行，极大地提高应用开发效率。同时这个方式促进了社会分工协作，云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。“
由此可见Serverless架构将会成为未来云计算领域中重要的技术架构，将会被更多的业务所采纳，成为其技术选型，那么再进一步的深究，Serverless在什么场景下可以有非常优秀的表现，在什么类型的场景下可能表现得并不是很理想呢？或者说，有哪些场景更适合Serverless架构呢？
Serverless架构的应用场景，通常是由其特性决定方向，所支持的触发器决定具体场景。
如图所示，在《CNCF Serverless Whitepaper v1.0》关于Serverless架构所适合的用户场景包括：
- 异步的并发，组件可独立部署和扩展的场景
- 应对突发或服务使用量不可预测的场景
- 短暂、无状态的应用，对冷启动时间不敏感的场景
- 需要快速开发迭代的业务，因为无需提前申请资源，因此可以加快业务上线速度
CNCF基于Serverless架构的特性给出了四个用户场景之外，还结合常见的触发器提供了详细的例子：
- 响应数据库更改（插入、更新、触发、删除）的执行逻辑
- 对物联网传感器输入消息（如MQTT消息）进行分析
- 处理流处理（分析或修改动态数据）
- 管理单次提取、转换和存储需要在短时间内进行大量处理（ETL）
- 通过聊天机器人界面提供认知计算（异步）
- 调度短时间内执行的任务，例如CRON或批处理的调用
- 机器学习和人工智能模型
- 持续集成管道，按需为构建作业提供资源，而不是保持一个构建从主机池等待作业分派的任务
《CNCF Serverless Whitepaper v1.0》站在Serverless架构的特点，从理论上描述了Serverless架构适合的场景或业务，云厂商将会站在自身的业务角度，整体来描述Serverless架构的典型场景。通常情况下，对象存储为触发器在Serverless架构的典型应用场景包括视频处理、数据ETL处理等；API网关更多会为用户赋能对外的访问链接以及相关联的功能等，当以API网关作为Serverless相关产品的触发器时，常见的应用场景就是后端服务，包括App的后端服务，网站的后端服务甚至是微信小程序等相关产品的后端服务，同时像一些智能音响也会开放相关的接口，这个接口也是可以通过API网关出发云函数，获得相应的服务等；除了对象存储触发以及API网关触发，常见的触发器还有消息队列触发器，Kafka触发器，日志触发器等。
Web应用/移动应用后端
Serverless架构和云厂商所提供的其他云产品进行结合，开发者能够构建可弹性扩展的移动或 Web 应用程序 – 轻松创建丰富的无服务器后端，而且这些程序可在多个数据中心高可用运行，无需在可扩展性、备份冗余方面执行任何管理工作。例如Web应用处理示例：
实时文件/数据处理
视频应用、社交应用等场景下，用户上传的图片、音视频往往总量大、频率高，对处理系统的实时性和并发能力都有较高的要求。例如：对于用户上传的图片，可以使用多个函数对其分别处理，包括图片的压缩、格式转换、鉴黄鉴恐等，以满足不同场景下的需求。例如：
通过Serverless架构所支持的丰富的事件源，通过事件触发机制，可以通过几行代码和简单的配置对数据进行实时处理，例如：对对象存储压缩包进行解压、对日志或数据库中的数据进行清洗、对 MNS 消息进行自定义消费等：
离线数据处理
通常要对大数据进行处理，需要搭建Hadoop或者Spark等相关大数据的框架，同时要有一个处理数据的集群。通过Serverless技术，只需要将获得到的数据不断的存储到对象存储，并且通过对象存储相关触发器触发数据拆分函数进行相关数据或者任务的拆分，然后再调用相关处理函数，处理完成之后，存储到云数据库中。例如：某证券公司每12小时统计一次该时段的交易情况并整理出该时段交易量 top 5；每天处理一遍秒杀网站的交易流日志获取因售罄而导致的错误从而分析商品热度和趋势等。函数计算近乎无限扩容的能力可以使用户轻松地进行大容量数据的计算。利用Serverless架构可以对源数据并发执行多个 mapper 和 reducer 函数，在短时间内完成工作；相比传统的工作方式，使用Serverless架构更能避免资源的闲置浪费从而节省成本，整个流程可以简化为：
## 人工智能领域
在 AI 模型完成训练后，对外提供推理服务时，可以使用Serverless架构，通过将数据模型包装在调用函数中，在实际用户请求到达时再运行代码。相对于传统的推理预测，这样做的好处是无论是函数模块还是后端的GPU服务器，以及对接的其他相关的机器学习服务，都是可以进行按量付费以及自动伸缩，从而保证性能的同时也确保了服务的稳定：
IoT等物联网领域
目前很多厂商都在推出自己的智能音响产品，用户可以对智能音箱说出一句话，智能音箱可以通过互联网将这句话传递给后端服务，然后获得到反馈结果，再返回给用户。通过Serverless架构，可以将API网关、云函数以及数据库产品进行结合来替代传统的服务器或者是虚拟机等，通过这样的一个架构，一方面，可以确保资源的按量付费，只有在使用的时候，函数部分才会计费，另一方面当用户量增加之后，通过Serverless实现的智能音箱系统的后端，也会进行弹性伸缩，可以保证用户侧的服务稳定，当要对其中某个功能进行维护，相当于对单个函数进行维护，并不会对主流程产生额外风险。相对来说会更加安全、稳定等：
监控与自动化运维
在实际生产中，经常需要做一些监控脚本来监控网站服务或者API服务是否健康，包括是否可用、响应速度等。传统的方法是通过一些网站监控平台（例如DNSPod监控、360网站服务监控，以及阿里云监控等）来进行监控和告警服务，这些监控平台的原理是通过用户自己设置要监控的网址和预期的时间阈值，由监控平台部署在各地区的服务器定期发起请求对网站或服务的可用性进行判断。当然，这些服务很多都是大众化的，虽然说通用性很强，但是实际上并不一定适合。例如说，现在需要监控某网站状态码，不同区域的延时，并且设置一个延时阈值，当网站状态异常或者延时过大时，通过邮件等进行通知告警，针对这样一个定制化需求，目前来说大部分的监控平台很难直接实现，所以定制开发一个网站状态监控工具就显得尤为重要。除此之外，在实际的生产运维中，还非常有必要对所使用的云服务进行监控和告警，例如在使用Hadoop、Spark的时候要对节点的健康进行监控，在使用K8S的时候要对API Server、ETCD等多维度的指标进行监控，在使用Kafka的时候，也要对数据积压量，以及Topic、Consumer等指标进行监控；这些服务的监控，往往不能通过简单的URL以及某些状态来进行判断，在传统的运维中，通常会在额外的机器上设置一个定时任务，对相关的服务进行旁路监控。
Serverless架构的一个很重要应用场景就是运维、监控与告警，通过与定时触发器进行结合使用，可以非常简单的实现某些资源健康状态监控与感知，并进行一些告警功能建设、自动化运维能力建设：
