Serverless 基本概念

理解 Serverless

简化的云端编程：一份来自伯克利的调查，关于 Serverless 计算。

原文：https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf

一）Serverless 和 Serverfull

Serverless相对于serverful，对业务用户强调 noserver（serverless并不是说没有服务器，只是业务人员无需关注服务器了，代码仍然是运行在真实存在的服务器上）的运维理念，业务人员只需要聚焦业务逻辑代码。

Serverless vs Serverful，有三个改变：

• 弱化了储存和计算之间的联系。 服务的储存和计算被分开部署和收费，存储更加云化，计算更加无状态化，即功能更加原子化。比如 Serverfull 模式下的应用间的依赖，为了保障底层依赖的可靠，需要时刻保持“活着”，应用存储和计算必须同时“活着”。而无状态化的依赖则更容易拼装调度和缩扩容。
• 代码的执行不再需要手动分配资源。 不需要为服务的运行指定需要的资源（比如使用几台机器、多大的带宽、多大的磁盘等），只需要提供一份代码，剩下的交由serverless平台去处理就行了。理想的情况是通过某些学习算法来进行完全自动的自适应分配。
• 按使用量计费。 Serverless按照服务的使用量（调用次数、时长等）进行计费，而不是像传统的 Serverful 服务那样，按照使用的资源（VM规格，带宽占用）计费。

二）Serverless 被怎样使用

 

最多的场景是被用来搭网站（32%），然后是数据处理相关（21%），目前使用场景较少的是聊天服务（8%）和 IOT（6%）。这个是亚马逊的数据，对于阿里来说，除了 Web 和 API 服务之外，更多的场景应该是 Internal Tooling，内部工具，比如商家工具。

三）Serverless 的局限

Serveless 目前仍然更多的被定义为胶水层，即捆绑在一个业务模式之上，通过胶水代码成本更低的构建一个个的小功能，组成小生态。比如一个公众号的博主写一个插件来吸粉，再比如一个社区商店写一个插件来给本小区住户 Push 新品推荐。但 Serverless 依然有先天局限性。它不适合这些场景：

• 大量运算的场景，计算时长过长，Serverless 的共享存储的性能和成本优势挑战很大。这类场景有大数据，AI 高密度运算场景，流媒体应用等
• 业务场景无法细颗粒度无状态拆分，比如 A 依赖 B，A 运算时长过长，B 需等待，A 运算结束后需要发通知给等待状态的 B。这种场景 B 就应当被归入 A 中，进而产生耦合。所以 faas 的颗粒度不能随意细拆。
• 模块间的通讯过多，包括了广播 Broadcast、聚合 Aggregation、Shuffle操作。Serverless 的理念是沉淀大量微粒式的函数片段，片段之间的通讯成本较高，所以在实践中需要控制模块依赖的层次。

这张图解释了 Serveless 和传统应用通讯模式上的差别。VM-Based 是传统模式，Function-based 是 Serveless 的模式。

 

在 VM-based 模式下，所有的任务运行在一个实例中，要广播的数据是通过拷贝共享的，通讯复杂度是 O(n)，这里 N 是 VM 中实例个数。但是在 Function-based 模式中的复杂度是O(NxK)，这里K是每个 VM 里的函数个数，这个量级差别在 Shuffle 操作中的性能损耗可能会更加巨大。

四）Serverless 的成本

 

五）Serverless 的未来

• 我们预计新的BaaS存储服务会被创建，它将极大的扩充现有serverless的类型。
• serverless 计算将会比 serverful 计算更加简单安全，而且会成为主流
• 基本可以断定 Serveless 的成本将会比 Serverful 更低。
• Serverful 计算将会促进 BaaS的发展。
• Serverless 将会成为云时代的首选项。