Serverless 的局限性都有哪些呢？

当前的 serverless 的主要局限性体现在一下几点

1. 存活时间很短

目前 Amazon Lambda 创建的函数，一次运行最多 15 mins，执行完了以后缓存虽然还可能保留在当前运行的主机上，但是下次运行该函数的时候，不一定在这个主机上，所以缓存极大可能会丢失。

1. IO 瓶颈

目前 Faas 访问共享存储的方式是通过网络带宽，而不是直接通过总线来访问的，因此造成了很大的 IO 损耗，网络限制了 IO 的吞吐量，一般情况下，每个 Amazon Lambda Function 的平均网络带宽是 538Mbps，如果考虑到多个 函数都在一个主机上共享带宽——假设有 20 个，每个Function 平均带宽是 28.7 Mbps，那么每个 Function 的 IO 速度比直接使用 SSD 慢 2.5 个数量级。

1. 需要通过低速存储进行通信

由于 serverless 函数没有主机的概念，所以每个函数都没有一个固定的网络地址，函数和函数之间的通信已经不能通过网络链路或者内存，而是通过存储服务（例如 S3 这种 key-value 存储服务）来间接地通信，这些额外的存储服务相对于端到端的网络通信来说，不仅延时高，价格还昂贵。

举个例子，在处理客户端请求的时候，每个函数只完成一个子流程，每个子流程都应该知道当前请求的上下文信息，也就需要保存会话状态，例如session id，但是由于 serverless 的无状态化特性，每个子流程（函数）的会话信息不能共享，所以这些本该保存在缓存和内存的信息只能先保存在相对低速的存储服务 S3 中，然后下一个子流程（函数）再从 S3 中获取上下文信息。

1. 没有对硬件自定义提供支持

对于 serverless 来说，目前对 GPU 等专有硬件的支持度还不够，例如 Amazon Lambda 只支持设置 CPU 超线程的时间片和内存使用量。