（函数即服务）Faas的现状与未来

刚看到jolestar一位从法律转行程序员的前辈写了一篇Faas现状与未来的文章，里面很多观点都很有启发，或许正如他说的那样，由于Faas能较好的解决资源利用率和开发效率问题，2018年Faas将变得更火。下面是一些精彩摘录：

FaaS 的本质上是以程序的快速启动来实现正真的按需运行，按需伸缩，以及高可用。Function 配合调度系统，就可以完全做到开发者对服务运行的实例无感，真 Serverless。
FaaS 主要解决的是用户自定义的代码逻辑如何做到 Serverless，可以叫做 Serverless Compute，同时它也是事件驱动架构的一种。

Faas现状

FaaS 最开始是 2014 年一个叫做 hook.io 的网站提供的，顾名思义，这个网站最早的功能是托管 webhook Function。Webhook 这种场景，按调用次数付费是最易于理解的。之后大厂看到价值迅速跟进，AWS 同年推出 Lambda，2016 年 Google，Microsoft Azure 推出自己的 Cloud Function 服务，2017 年国内云厂商腾讯云，阿里云也跟进。FaaS 是一种事件驱动架构，所以事件源很重要。这一方面 AWS 做的最全面，几乎将 FaaS 所有可能支持的事件类型都囊括了，并且探索 FaaS 在边缘计算和 IoT 上的场景。随着 FaaS 的成熟，PaaS 会逐渐放弃托管用户自定义的应用，而蜕变成给 FaaS 提供事件源以及状态存储的平台，比如数据库，消息队列，API GateWay 等标准化服务，而 FaaS 变成托管用户自定义逻辑的平台。

FaaS 的应用场景以及潜力

微服务个人一直认为 FaaS 是微服务的终极演进结果。微服务一直没有一个明确的标准是拆到多细算是微服务，FaaS 给了一个标准：冷启动时间在毫秒量级，以及资源使用受系统上限约束。有人觉得全拆成 Function，是不是太细了？但实际上 Function 只是个抽象的概念，你也可以把整个应用的请求全部指向一个 Function，然后在内部做路由，只要能保证冷启动时间。另外微服务本质上还需要解决服务间的调用，追踪，熔断/重试等机制，这些在传统的方案里，都是通过应用内嵌框架来解决的，而微服务领域最近很火的 Service Mesh 的解决思路是在网络层处理，这样就可以独立交付，而 FaaS 可以说异曲同工，它直接从应用中剥离了一层出来，然后具体是内嵌框架还是通过 Service Mesh 实现，对用户来说没有区别。
视频，图片以及流式事件处理本质上是需要一种通用的，可自定义的，工作流应用。当前的工作流一般都是针对具体场景的，尚无支持自定义逻辑并且适用于各种类型事件的分布式工作流。而基于 FaaS 有可能诞生这样一种工作流。另外类似于 Storm 这样的流式大数据处理平台，也可以理解成一种基于特定语言的 FaaS 平台，FaaS 和流式数据处理平台的整合大有前景。
事件驱动以及响应式架构这个场景和前一个场景有相似之处，只不过前一个关注的是应用场景，这条单指技术架构场景。服务器端的事件驱动和响应式架构和客户端技术相比，一直缺少一种统一的体系解决方案，主要原因是服务器端缺少分布式系统级别的支持，纯开发框架的方式实现比较困难，如果调度系统和开发框架配合，实现这种架构就比较容易了。
IoT 物联网场景实际上和前面的流式事件处理以及事件驱动架构都有关系。这里单独作为一条阐述，主要是物联网对应用开发带来的不仅仅是架构上的变化。互联网主要是信息技术，主要是面向人的应用，要求及时把信息展示给用户，所以应用多是 http 的请求响应模式，对延迟比较敏感（毫秒级）。而物联网场景下，多是事件触发，哪怕有人参与的场景，比如智能开关，也是触发事件后控制另外的设备，对延迟忍耐度较高（秒级），协议多也不是 http，而是物联网相关的消息协议。

国内的 FaaS 案例

同程旅游首席架构师王晓波在 ArchSummit 2017 上发表《从微服务到 Serverless 架构：享受纯粹的编程乐趣》的演讲，通过 Serverless 提高交付效率，
VPGame CTO 俞圆圆在 GIAC 2017 大会上发表《电竞数据的容器实践 — Serverless 的电竞数据计算平台》的演讲，通过 Serverless 提高资源利用率。
今日头条视频架构负责人侯爽在 GIAC 2017 大会上发表《今日头条大规模视频处理的挑战与应对》，通过 FaaS 构建视频处理平台。

原文地址：http://jolestar.com/serverless-faas-current-status-and-future/?hmsr=toutiao.io