Serverless面临的挑战和开放性问题

系统级挑战

1. 开销

对于Serverless，开销是最基本的挑战，这包括最小化Serverless函数在执行时和空闲时所使用的资源。另外一个方面是定价模型。例如，目前来说，CPU密集型应用使用Serverless函数更经济，而I/O密集型应用仍然是使用传统的虚拟机或者容器更便宜。

2. 冷启动

Serverless的一大特点是能够将函数在空闲时，缩容至0实例，并且此时是不计费的。然而，这种做法造成了冷启动的问题，因为使函数从0实例到准备执行需要消耗一定的时间。如何在保持缩放到0实例的同时，最小化冷启动所带来的消耗，是一个值得研究的话题。

3. 资源限制

为了使Serverless平台能够处理流量峰值以及预防攻击，一般需要对资源进行限制，这里包括对Serverless函数的内存，执行时间，带宽，CPU使用率等进行限制。并且，还可能会有对多个函数甚至整个平台应用的总资源限制。

4. 安全

多个用户的函数会运行在同一平台上，因此函数之间的完全隔离非常关键。

5. 伸缩

Serverless平台必须保证用户函数的可伸缩性和弹性，这里主要指的是平台需要响应函数当前的负载，并预期未来的负载，从而调整提供的资源。这是一个很有挑战的问题，因为这些预测和调整资源的决策都是要在几乎没有应用层信息的情况下进行的。例如，系统虽然可以利用请求队列的长度来预测负载强度，但是却看不见请求的内容。

6. 混合云

随着Serverless越来越受欢迎，一个平台不太可能具有所有功能，适用于应用的全部需求，因此一个应用中可能会有来自不同Serverless平台的函数服务，他们需要进行协作，而不同平台之间的函数协作可能会遇到一些问题。

7. 遗留系统

Serverless平台中的函数最好能够轻易的访问到非云环境中的系统。

 

编程模型和DevOps中的挑战

8. 工具

针对传统服务器的监控调试工具不适用于Serverless平台下的应用，因此需要新的工具。

9. 部署

开发者需要能够使用声明式的方式来控制部署，并且需要工具来支持这种方式。

10. 监控和调试

在Serverless架构下，开发者不再关注服务器等基础设施，因此当函数运行时，开发者只能从Serverless平台上提供的监控设置中获取到相关监控信息，所以Serverless平台必须对此提供良好的支持。

11. IDE

Serverless平台中最好集成功能丰富的IDE，能够使开发者获得函数重构（分割或者合并函数等），以及版本回退等高级功能。

12. 可组合性

函数的组合意味着我们可以在函数内部调用其他的函数。我们需要工具来更好的支持函数组合的创建和维护。

13. 长时间运行

目前，Serverless平台会限制函数的执行时间。然而在某些场景下，我们需要能够长时间运行的函数。所以，我们需要合适的编程模型和工具来将长时间运行的任务分解为多个小单位，并且提供必要的上下文来使得它们就像是一个长时间运行的任务。

14. 状态

真实的应用往往是有状态的，而目前还不太清楚应该如何在Serverless函数中较好的管理状态。因此我们需要合适的编程模型，工具和库来提供状态的管理。

15. 并发

我们需要能够表达并发语义，例如原子性（函数的执行需要序列化）等。

16. 恢复机制

Serverless平台需要恢复机制，例如 exactly once, at most once, at least once 等语义。

17. 代码粒度

目前，Serverless平台都是以函数的粒度对代码进行封装。是否应该使用更粗或者更细粒度的代码模块仍然是一个开放性的问题。

 

开放性的研究问题

下面总结一些开放性的研究问题。

一、Serverless的边界在哪里？

Serverless中一个基本问题就是它的边界：Serverless只是FaaS吗？或者范围更广呢？Serverless与其他模型，例如SaaS，MBaaS等之间又是什么关系呢？

随着Serverless的普及，不同的 "as-a-service" 之间的边界可能正在消失。可以想象，开发者在编写代码时，还可以声明他们希望代码如何作为 Faas 或者 MBaaS 或者 PaaS 运行。未来，可能主要分为两种模式，server-aware 和 serverless. 而Paas 则在两者之间，因为开发者尽管很容易部署自己的代码，但是仍然需要了解背后的服务器资源，制定相关的伸缩策略，例如启动多少个实例。

不同的云计算模型是否能够融合？Serverless函数的资源使用量（CPU，内存等）可以有更多选择吗？Serverless平台需要有类似IaaS的计费策略吗？

二、Serverless 所需的工具链与已有的解决方案是否有根本的不同？

Serverless 应用的粒度比传统应用要细的多，所以我们可能会需要新的工具来处理这些数量级更大，生命周期更短的服务。如何保证服务运行时的监控信息不会被遗漏呢？对 Serverless 应用的监控和调试会更有挑战性，因为我们不能直接到服务器上去看哪里出错了。相反，Serverless 平台需要负责收集代码运行时所有的信息，并且让开发者能够轻易地访问到它们。与此类似，Serverless应用的调试比传统应用要困难很多，因为开发者需要处理许多微小的代码块。所以我们可能需要新的工具来将微小的Serverless服务汇聚在一起以方便理解和调试。

三、单体系统能否自动被拆分适用Serverless的函数服务？

已存在代码的数量往往比新写的代码多很多。因此，一个很重要的问题是已存在代码可以在何种程度上自动化或者半自动化地拆分成细粒度的代码模块（函数）从而适应于Serverless平台。

四、Serverless必须是无状态的吗？

目前的 Serverless 平台都是支持无状态的函数服务，未来会支持有状态的服务吗？会有简单的方式来处理状态吗？

五、会有创建Serverless解决方案的模式（Pattern）吗？

如何将细粒度的Serverless模块组合成一个应用解决方案？如何将巨大的应用拆分成合适的细粒度Serverless函数从而优化资源的利用率？例如，我们如何识别应用中CPU密集型的部分，从而将它们无服务化？我们可以使用一些明确的模式来指导进行函数组合或者应用拆分吗？服务端和客户端之间需不需要做一些特别的事情呢？（例如，是否厚前端更合适一些？）是否可以从面向对象设计模式，企业集成模式等模式中学到一些经验教训，并总结出一些模式？

六、Serverless是否超越了传统的云平台？

Serverless 也许可以支持位于传统数据中心之外的代码运行场景，例如 IoT，移动设备，浏览器以及其他位于边缘的计算设备。例如，雾计算的目标是创建一个系统层面的水平架构，该架构将计算，存储，控制和网络的资源和服务分布在从云到物联网的任意位置。运行在“雾”中的代码不仅可以嵌入到设备中，还可以被虚拟化，从而完成了从设备到云之间的迁移。这可能会导致重新定义开销，例如，此时电池消耗也许比速度更重要。

还有一个例子是运行区块链中智能合约的代码。这些代码定义了智能合约，可能会被部署在以太坊中的虚拟机上。因为系统是分布式的，不是以太坊自己的机器在跑代码，而是其用户。为了激励用户运行智能合约代码，他们会从以太坊处得到相应的报酬。