我们收集了从业者在技术讲座，博客和白皮书中提出的无服务器模式。目的是通过对分类进行分类并报告可能的收益和问题，以支持从业人员理解不同的模式。我们采用了多语言文献复审过程，调查了同行评议和灰色文献，并对模式（解决常见问题的通用解决方案）进行了分类，并附带了收益和问题。在24部精选作品中，我们确定了32种模式，分别被编排为业务流程，聚合，事件管理，可用性，沟通和授权。
在本文中，我们总结了已识别的模式以及它们的好处和问题。有关总结模式的方法和结果的更多信息，请参见我们的论文（Taibi2020）
从业者提出的模式
我们确定了32种模式，我们将其分为五类：
- 编排和聚合
- 事件管理
- 可用性
- 通讯
- 授权
编排和聚合
这些模式可用于组成无服务器函数或协调其执行，从而创建更复杂的功能或微服务。
1. 聚合器API网关：为多个API只公开一个端点。函数单独调用API，然后汇总结果并将其公开为单个端点。
2. 数据湖：数据湖是原始数据的物理存储，在其中数据的处理和删除最少。为了保持秩序，必须使用明智的元数据命名进行组织。好处：数据始终保持不变，不受当前需求的影响。可以根据需要及时进行转换。
3. 扇入/扇出Fan-In/Fan-Out ：也称为“虚拟角色” ，“数据转换” ，“处理器” ，“火警触发器“，拆分并行工作并最终汇总结果。并行执行可加快完成速度。适合执行超过最大执行时间的长任务。缺点：链接函数之间的强耦合。对函数链，在函数之间划分任务可能很复杂
4. 函数链：允许执行超过最大执行时间（例如，在Lambda中超过15分钟）的长任务。将函数组合在一起。初始函数在跟踪剩余执行时间的同时开始计算。在达到最大执行时间之前，该函数异步调用另一个函数，并传递继续计算所需的每个参数。然后可以终止初始功能，而不会影响链中的下一个功能。缺点：链接函数之间的强耦合，函数数量增加。在函数之间划分任务可能很复杂
5. 代理：也称为“命令模式”，“反腐败层”。创建一个函数来充当其他服务的代理，处理任何必要的协议或数据格式转换，为客户提供干净且易于访问的API。
6. 基于队列的负载均衡 ，也称为“可伸缩Webhook”，“ Throtler”。通过Webhooks，可以使用自定义回调来增强或更改网页或Web应用程序的行为。如何提高Webhooks调用的可伸缩性？可以使用触发服务的队列服务，该服务允许在高负载下对请求进行排队。
7. 节俭的消费者：一种函数，用于处理将消息直接发布到消息队列的多个服务（或函数）的请求。
8. 内部API：由于无法从外部访问服务，因此提高了安全性。
9. 健壮的API ：也称为“网关” ，使用API网关为客户端授予对所选服务的访问权限。
10. 路由器：创建一个充当路由器的函数，接收请求并根据有效负载调用相关功能。好处：易于实施。问题：路由功能需要维护。此外，它可能会引入性能瓶颈，并成为单点故障。双重计费，因为路由函数需要等待，直到目标功能终止执行。
11. 胖客户端 ：允许客户端直接访问服务并协调工作流程。好处：提高性能，降低服务器端成本，增加关注点分离。
12.状态机：采用无服务器编排系统（例如AWS Step Functions或IBM Composer）来编排复杂的任务。
事件管理
这些模式有助于解决通信问题。
13. 职责隔离：隔离用于更新和读取数据源的功能。对适当的函数使用“命令和查询”，以避免这种拥塞。
14. 分布式触发器 ：可以通过消息队列将多个服务耦合到一个通知函数中。如果主题仅具有一个目的并且不需要微服务之外的任何数据，则此设置非常有效。
15. FIFO：使用crontab（例如AWS Cloudwatch）定期周期性地异步调用该函数。然后，将函数的并发性设置为1，这样就不会尝试并行运行竞争请求。该函数轮询队列（最多10条）排序的消息，并执行所需的任何处理。处理完成后，该函数将从队列中删除消息，然后再次（异步）调用自身。重复此过程，直到从队列中删除了所有项目。
16. 内部切换：函数在执行完成时自动停止，并在需要时自动重试。使用消息队列附加死信队列可以捕获失败。
17. 调度：周期性调用者，将该函数订阅到调度程序，例如AWS Cloud Watch，Google Cloud Scheduler或Azure Scheduler。好处：定期运行函数，而无需使其永久处于活动状态。
18.轮询事件处理器：使用定期调用者模式检查服务的状态好处：运行定期执行函数，而无需将功能永久保持为侦听器。
可用性模式
这组模式有助于解决可用性问题，减少预热时间和可能的故障。
19.隔板：将工作负载分区到不同的池中。可以根据使用者负载或可用性来创建这些池。
20.断路器：当故障次数达到某个阈值时，“断开”电路会立即将错误发送回调用方客户端，而无需尝试调用API。
21.编译函数：一种高级的，专门的，预先编译的无服务器语言可以减少内存占用和调用时间。这可能使云中的Edge技术可行。
22.函数预热器：减少冷启动时间，即调用某个函数后函数执行之间的延迟。
23. 函数过大：在Serverless中，无法选择在哪个CPU上运行。解决方案：即使不需要更多内存，要求更大的内存也会授予更快的虚拟机。
24. 重载报表引擎：使用数据缓存并创建最常查询的数据的专用视图
25. 最终一致：使用数据库流服务（例如DynamoDB流）来触发以前功能在数据库上产生的事件，并根据需要再次使用数据。
26.超时：API网关的超时时间为29秒。这对于用户来说是很长的时间，并给服务带来不好的体验。解决方案：将超时时间缩短到较短的时间，最好在3到6秒左右。
通讯模式
在这里，我们描述了函数之间进行通信的模式。
27.数据流：也称为“流和管道”，“我是流媒体 ”和“事件处理器” ，“流数据摄取” ，“流处理”。无服务器平台提供了诸如Kinesis（AWS）之类的可能性来处理大量数据流并将其分发到服务。问题：在无服务器环境中，数据流可能会非常昂贵。在平台生态系统之外工作也可能很困难。
28.外部状态：在某些情况下，需要在函数之间共享状态。通常的解决方案：共享状态并将其保存到外部数据库中。 这个模式：应用连续流处理器捕获大量事件或数据，并将它们尽快分布到不同的服务或数据存储中
29.发布/订阅：在消息队列中使用独立主题来分发内部内部服务通知。
授权模式
这些处理用户授权问题。
30.Gatekeeper ：使用网关创建授权者函数，该函数可以处理授权标头并返回授权策略。
31.Valet key：通过请求特殊的授权者无服务器功能的首次访问，它被授予令牌，该令牌在一定时期内有效并且具有访问权限。