FaaS是Function as a Service的缩写，可以简单理解为功能即服务。与微服务相比，FaaS提供了一种更加服务化的软件架构范式，FaaS让研发人员只关注业务代码逻辑，而不关注技术架构。

1、微服务 个人一直认为 FaaS 是微服务的终极演进结果。微服务一直没有一个明确的标准是拆到多细算是微服务，FaaS 给了一个标准：冷启动时间在毫秒量级，以及资源使用受系统上限约束。有人觉得全拆成 Function，是不是太细了？但实际上 Function 只是个抽象的概念，你也可以把整个应用的请求全部指向一个 Function，然后在内部做路由，只要能保证冷启动时间。另外微服务本质上还需要解决服务间的调用，追踪，熔断/重试等机制，这些在传统的方案里，都是通过应用内嵌框架来解决的，而微服务领域最近很火的 Service Mesh 的解决思路是在网络层处理，这样就可以独立交付，而 FaaS 可以说异曲同工，它直接从应用中剥离了一层出来，然后具体是内嵌框架还是通过 Service Mesh 实现，对用户来说没有区别。

2、视频，图片以及流式事件处理 本质上是需要一种通用的，可自定义的，工作流应用。当前的工作流一般都是针对具体场景的，尚无支持自定义逻辑并且适用于各种类型事件的分布式工作流。而基于 FaaS 有可能诞生这样一种工作流。另外类似于 Storm 这样的流式大数据处理平台，也可以理解成一种基于特定语言的 FaaS 平台，FaaS 和流式数据处理平台的整合大有前景。

3、事件驱动以及响应式架构 这个场景和前一个场景有相似之处，只不过前一个关注的是应用场景，这条单指技术架构场景。服务器端的事件驱动和响应式架构和客户端技术相比，一直缺少一种统一的体系解决方案，主要原因是服务器端缺少分布式系统级别的支持，纯开发框架的方式实现比较困难，如果调度系统和开发框架配合，实现这种架构就比较容易了。

4、IoT 物联网场景实际上和前面的流式事件处理以及事件驱动架构都有关系。这里单独作为一条阐述，主要是物联网对应用开发带来的不仅仅是架构上的变化。互联网主要是信息技术，主要是面向人的应用，要求及时把信息展示给用户，所以应用多是 http 的请求响应模式，对延迟比较敏感（毫秒级）。而物联网场景下，多是事件触发，哪怕有人参与的场景，比如智能开关，也是触发事件后控制另外的设备，对延迟忍耐度较高（秒级），协议多也不是 http，而是物联网相关的消息协议。