深入理解无服务器架构(Faas/Serverless)

对于自然无状态的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系统吧，无论你使用哪一种编程语言。

无论你是否认为你的应用是否存在此类问题，你最好用类似生产的负载来测试性能。如果此时此刻比较烂，不要着急，FaaS供应商正在持续改进，说不定年底就满足你的要求了。

API网关

API网关是一个HTTP服务器，其中路由和负载点定义在配置中，并且每个路由与处理该路由的函数关联。当API网关收到请求后，它会找到与请求匹配的路由配置，来调用相关的FaaS函数。API网关允许从HTTP请求参数映射到FaaS函数的更简洁的输入，或者让HTTP请求原封不动得通过，FaaS函数将执行其逻辑并将结果返回给API网关，而API网关又将此结果转换为HTTP响应，并将其传递回原始调用方。

工具

关于工具成熟度的评论也适用于FaaS。 到今年(2018年)，我们已经看到了明显的改善，我们希望工具能够更好地发展。

FaaS世界中一些“开发者用户体验”好的例子值得一提。 首先是Auth0 Webtask，它非常重视开发人员用户体验。 其次是Microsoft，其Azure功能产品。 Microsoft一直将Visual Studio及其反馈循环置于其开发人员产品的最前沿，而Azure Functions也不例外。 在云触发事件的输入下，它提供的在本地调试功能的能力非常特殊。

开源势力

无服务器中开源的最常见用途是FaaS工具和框架，它提供了一些跨云提供商的工具抽象，类似工具的例子包括Claudia和Zappa。另一个例子是Apex，它允许你使用亚马逊直接支持的语言之外的语言开发Lambda函数。不过AWS自己的部署工具SAM(无服务器应用程序模型)也是开源的。

专有FaaS的主要好处之一是不必关心底层计算基础架构(机器，虚拟机，容器)。但是如果你想关注这些事情呢?也许你有一些云供应商无法满足的安全需求，或者你有一些你已经购买但不想丢弃的服务器机架。在这些场景中可以开源帮助，允许运行自己的“Serverful”FaaS平台，这个领域有很多活动。开源FaaS的最初领导者之一是IBM(使用OpenWhisk，现在是一个Apache项目)。Microsoft，它开源了很多Azure功能平台。许多其他自托管FaaS实现使用底层容器平台，通常是Kubernetes，在这个领域，值得探索Galactic Fog，Fission和OpenFaaS等项目。在未来的博客中，我会重点关注OpenFaas项目，该项目目前有超过10k+的Star。

5. Serverless 不是什么

因为概念太多，容易混淆，现在很多Readme都有这个环节：

和Paas平台相比

看下大神(VP Cloud Architecture Strategy at AWS)是怎么说的：

换句话说，大多数PaaS应用程序并不是为了响应事件而使整个应用程序启动或消失，而FaaS平台是。

FaaS和PaaS之间的关键运营差异是扩展。通常使用PaaS，你需要考虑如何扩展服务实例，使用FaaS应用程序，则是完全透明的。即使您将PaaS应用程序设置为自动扩展，你几乎不可能将此操作设置为单个请求的级别的扩展，举个例子，你一个服务实例，一般不会对不同的请求设置不同的实例数量，如果大量查询操作，和少量更新操作，你可能会考虑优化查询，增加缓存等，而不是在1分钟内，将你的实例扩大到100倍，因此FaaS应用程序在成本方面更加高效。

鉴于此优势，您为什么还要使用PaaS?也许最大的原因是工具成熟度，基于Paas有很多行之有效的实践，Faas给了我们系统扩展一些更多的思路。

和容器相比

另一种流行的服务抽象是容器，Docker是这种技术最明显的例子。Kubernetes之类的容器托管系统越来越受欢迎，它们从操作系统级部署中抽象出各个应用程序。在这条道路上，我们看到像Amazon ECS和EKS这样的云托管容器平台(这里推荐下，灵雀云的AKS发行版)，以及Google Container Engine(Alauda Container Engine，AKE)，它们像Serverless/FaaS一样，团队完全无需管理自己的服务器主机。鉴于容器发展的势头，还是值得考虑无服务器FaaS吗?

运维

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!