Serverless中的Faas的特点是什么呢？

有无状态

FaaS函数在本地（VM/容器实例）状态（即存储在内存中的变量中的数据或写入本地磁盘的数据）中具有很大的限制。一般情况下你确实可以这样存储，但是不能保证这种状态在多个调用中保持不变，更重要的是，你本来就不应该假设一次调用函数的状态可用于同一函数的另一次调用。因此，FaaS函数通常被描述为无状态，或者更准确地说，需要持久化的FaaS函数的任何状态都需要在FaaS函数实例之外进行。 对于自然无状态的FaaS函数 - 即那些提供输入到输出的纯功能转换的函数 - 这是无关紧要的。但对于有状态的而言，这可能会比较麻烦，以前分布式的那些限制现在完全相同。这种面向状态的函数通常将使用数据库，缓存（如Redis）或网络文件/对象存储（如S3）来跨请求存储状态。

执行时长

FaaS函数通常受限于允许每次调用运行多长时间。目前，AWS Lambda函数响应事件的“超时”最多为五分钟，然后才会终止。 Microsoft Azure和Google Cloud Functions具有类似的限制。这意味着某些类别的长期任务不适合FaaS - 除非你重新设计架构，需要创建几个不同的协调FaaS函数，而在传统环境中，您可能有一个长期任务执行协调和执行。

启动延迟和“冷启动”

FaaS平台在每个事件之前初始化函数实例需要一些时间。不同的函数，他的启动延迟也可能显着变化，从几毫秒到几秒的都有可能，取决于许多因素，具体一点以AWS Lambda为例。

Lambda函数的初始化即可以是“热启动”（使用Lambda函数的之前以前产生的容器），也可以是“冷启动”（创建新容器实例），冷启动带来的延迟应该引起了我们的关注。

冷启动的延迟取决于许多因素：开发语言，使用的库，代码量，Lambda函数环境本身的配置，是否需要连接到VPC资源等等。这些方面受开发人员的控制，通过这些地方的优化可以减少冷启动的一部分启动延迟。

可调的还有冷启动的启动频率。例如如果一个函数每秒处理10个事件，每个事件需要50毫秒来处理，那么每隔100,000-200,000个事件，您可能会看到一个实例的冷启动。另一方面，如果每小时处理一次事件，你可能会看到每个事件来时的冷启动，因为Amazon会在几分钟后退出非活动的Lambda实例。知道这一点有助于了解冷启动是否会影响集成效果，以及是否可能希望对函数实例执行“保持活动”以避免它们被回收。

冷启动需要太关注吗？这取决于应用程序的负载或流量的情况。如果你需要的是低延迟交易应用程序，那么最好忘掉FaaS系统吧，无论你使用哪一种编程语言