Serverless无服务器架构

随着2019年的临近，我想写下一些关于过去十年中一些最重要的技术采用和技术创新的想法。我还展望了未来，列举了未来十年可以解决的痛点和机遇。本文不涉及数据科学，人工智能，前端工程等领域的发展，因为我个人在这些领域没有太多经验。

将Zeebe作为工作流引擎，您可以： 以您选择的编程语言构建应用程序（Zeebe提供Java，

通常将Knative项目解释为“ Kubernetes上的无服务器”的构建基块。因此，大多数Kubernetes用户都不知道Knative可以为他们的非无服务器工作负载做什么：它可

现在我们的工业终于从大众的错觉（微服务将是未来）中恢复过来了，又掉入了一个更大的错觉：无服务器Serverless将提供万能的拯救。试图从无服务器的基础上制作整个应用程序，例如Basecamp或Shopify或GitHub或几乎任何东西，无服务器沿着微服务所有坏主意继续挖坑，并说“但

不同于Docker容器或JVM等语言VM，亚马逊Firecracker专门致力于无服务器应用的轻量虚拟化。Firecracker是支持AWS Lambda和AWS Fargate的虚拟机监视器（VMM），自2018年以来已在AWS上投入生产。Firecracker是开源的，并且有许多项目使在

有许多项目试图抽象化Kubernetes：knative基于对Kubernetes抽象提供无服务器平台。kubeflow基于Kubernetes抽象提供ML平台。Argo基于Kubernetes抽象提供工作流引擎。 这些抽象

无服务器通常与函数即服务（FaaS）产品等同，例如AWS Lambda。但是，无服务器不仅仅是FaaS，FaaS平台允许用户编写在事件发生时执行的小段代码，该平台透明地负责配置运行时，自动扩展和安全性。FaaS可以看作是将云服务连接在一起并在某些事件发生时执行的粘合剂。Serverl

API网关可以做很多事情。他们有选择地向更广泛的受众公开私人服务。借助路由规则，它们可以在不通知客户的情况下在服务版本之间移动客户端。它们通过提供速率限制和缓存等功能来保护下游服务。而且，它们为具有微服务架构的用户提供了一种可行的方式来保护服务安全，而无需每个服务都进行自己的身份验证。从历史

Jangda等人由于在“无服务器计算的形式基础”方面的工作而在今年获得了OOPSLA的杰出论文奖。本文的中心是他们观察到无服务器执行环境具有许多独特的属性（例如执行环境的热启动/重用），这会使构建正确的应用程序变得更加困难。它们显示了无服务器功能可以安全地忽略这些特性的条件，因此变得更容易推

在此博客中，我们将探索使用无社交架构通过Twitter等社交媒体模型作为示例平台，以创建，管理电子邮件摘要并将其发送给用户的几种方法。对于此示例，我们假设正在使用

KEDA提供了一种扩展到Kubernetes标准方法的替代方法，该方法用于查看诸如CPU负载和容器的内存消耗之类的指标。从KEDA的角度来看，此方法是被动的，而不是主动的。与无服务器平台一样，KEDA尝试根据诸如消息源（例如，Kafka，Azure Service Bus或RabbitMQ）

我们收集了从业者在技术讲座，博客和白皮书中提出的无服务器模式。目的是通过对分类进行分类并报告可能的收益和问题，以支持从业人员理解不同的模式。我们采用了多语言文献复审过程，调查了同行评议和灰色文献，并对模式（解决常见问题的通用解决方案）进行了分类，并附带了收益和问题。在24部精选作品中，我们确

简单的说，事件溯源是一种存储状态（对于实体）的方法，该状态是通过存储该实体发生的所有事件的顺序历史记录而起作用的。对实体的更改将作为新事件写入，附加到该实体的事件流的末尾。当查询或业务流程需要使用实体的当前状态时，它会通过在事件流上运行投影来获取此信息，这是一段非常简单的代码，对于每

人们通常不知道微服务需要独立的自治。例如各种服务共享一个数据库；另一个问题是，服务之间通过RPC/Restful进行网络之间的同步调用链太长。这些都是分布式意大利面条一样的糨糊结构，这种架构并没有引起人们的注意，这种面条糨糊的结构可能是由于各种相互调用的服务紧密耦合而引起的。设计微服

在过去的几年中，无服务器一直是科技界的热门话题。我想通过尝试一些新方法来保持我的技术水平最新，所以我决定花几个小时来学习无服务器，并看看以这种方式托管我们的API是否有意义。我学习了关于使用