面向生产的无服务器组成和编排

最新推荐文章于 2024-10-08 16:24:39 发布

dfsgwe1231

最新推荐文章于 2024-10-08 16:24:39 发布

阅读量158

点赞数

文章标签：后端数据库 ui

现代云软件开发中的一种强大且成熟的趋势是实现以下组件：

单用途
小
独立部署
易于测试

然后，将这些组件服务组合（或编排）为一个有凝聚力且有组织的工作流，以完成更高级别的任务并完成系统预期的业务或实际目的。

具有独立的组件可以实现软件的可重用性和软件体系结构的解耦。结果，整个系统可以更易于测试，扩展和维护。

如何在无服务器中组合？

组成无服务器功能（例如AWS Lambda ）并不像听起来那样容易。开发人员在无服务器功能中欣赏到的许多好处取决于某些属性。

例如：

>函数的高度可扩展性取决于其无状态属性按次计费模型（不会浪费空闲资源）仅因为函数是临时的，按需运行且没有长时间运行的流程才有可能

>使无服务器如此吸引人的相同属性也给服务组合带来了一些挑战。

在功能组合体系结构中，我们希望至少满足三个原则：

1）替代 ：能够在不破坏系统其余部分的情况下替换（或扩展/修改）组件；

2）隔离 ：每个组件都应该是一个黑盒子，没有服务应该知道其他服务的实现细节；

3）零浪费 ：由于无服务器是按使用付费，因此我们希望避免出现双重计费情况（例如，在下文中有更多介绍）

无服务器组成挑战

让我们考虑一个简单的情况：用户创建一个免费帐户（不涉及付款）并订阅在线服务。结果，应执行一些任务：

将用户数据保留在数据库存储中发送消息以验证用户电子邮件地址通知Webhook跟踪营销活动绩效（从潜在客户转换为订阅用户）

如果这些任务中的每一个都应该由孤立的独立组件执行，那么我们应该如何协调它们呢？

一个简单，简单的实现是使一个函数在API后面运行，并按顺序协调所有其他任务。接下来，我们将看到为什么这种实现方式不是最优的，但是请首先检查下图：

恢复我们希望满足的三个原则：替代，隔离，零浪费。

上面的实现不满足任何这些期望的属性。

打破替代

首先，这使得更换和扩展组件变得困难。假设该系统已经运行了一段时间。现在，还需要使用SMS验证用户的手机号码。当CreateUser调用ValidateEmail函数时，它仅提供收件人的电子邮件地址，而不提供电话号码。例如，我们不能仅用更通用的ValidateContacts代替ValidateEmail。

中断隔离

其次，CreateUser函数必须知道其他服务以及它们的至少某些实现细节。例如，必须意识到这些服务是作为Lambda函数实现的。这破坏了隔离属性。

打破零浪费

最后，还有很多双重计费。例如，当StoreUserData与后端数据库进行通信时，CreateUser在进入下一个任务之前一直处于空闲状态。即使代码是异步实现的，仍然会有一定的延迟，在该延迟中，同时为多个功能计费。这破坏了零浪费属性。

考虑选项

让我们找出在协调我们的功能时是否能够满足所有三个所需的原理。下面，我们将在客户端和后端介绍几种不同的功能组合方法。

应该避免其中的某些模式，建议使用其他模式，但它们都有自己的强项和弱项，应根据具体情况和用例加以考虑。

客户端

对于与UI（用户界面）具有某种交互作用的流程，业务流程逻辑可以嵌入客户端。

在上面的用户订阅示例中，可以这样构造：

客户端软件负责调用实现用户创建过程所需的每个端点。可以并行执行所有调用，以加快最终用户的总体处理时间。

但是，此模型有一些缺点和警告：

缺乏可重用性

客户端模型使代码的可重用性变得更加困难。由于启用可重用性首先是设计模块化组件体系结构的主要目的之一，所以它可能不适合我们的目标。

编排过程是针对一种类型的客户端实施的：Web浏览器。为此客户端实现的代码无法轻松地传输到后端无服务器环境中。

例如，如果我们希望通过API或CLI（命令行界面）而不是浏览器UI支持通过编程方式创建帐户，该怎么办？

有人可能会争辩： 在浏览器中运行的相同Javascript代码可用于NodeJS无服务器功能 。尽管从技术上讲这是正确的，但是从体系结构的角度来看，这可能会导致错误的实现。

通过将此客户端图体系结构移至后端无服务器功能，我们将回到与上述顺序模型相似的情况。在此模型中，我们的构成无法满足我们所寻找的所有三个设计原则。

难以处理一致性

如果在创建帐户时StoreUserData函数无法访问数据库，该怎么办？用户数据将保持待存储状态。从数据库的角度来讲，该帐户尚未创建。

客户是否仍应请求验证电子邮件？Webhook仍应得到通知吗？

这些决定都必须在客户端中做出，这增加了客户端上运行的软件的复杂性。根据上述问题的答案，将不可能同时请求所有三个端点。但是仅在三步顺序的API交互之后才响应用户可能太长。

公开内部业务规则

在业务流程中必须在客户端公开一些理想情况下应保持私有的业务规则。这是在客户端运行代码所固有的，无法真正解决。

异步消息

在另一篇文章中，我们更广泛地讨论了异步消息传递，因此在这里我们将不详细讨论该概念。

使用此架构可以满足所有三个原则：替换，隔离，零浪费。

这种方法的缺点是当我们需要对工作流逻辑进行更细粒度的控制时。与在客户端模型中处理一致性有关的相同问题也适用于此。例如，如果一个步骤失败，则很难（即使不是不可能）控制流程中其他步骤的行为方式。

这并不意味着不应该使用此模式。实际上，对于可伸缩和可维护的无服务器组合策略而言，它可能是最常用和成功使用的模式之一。这并不是所有用例的理想选择。

链式

每个功能可以连接起来，在每个任务执行结束后调用一个功能。可以通过让API提前响应一条确认消息，即已接收到请求并正在处理请求，来减少最终用户的等待时间。

不幸的是，该模型也违反了我们正在寻找的一些设计原则。

在不影响系统其他部分的情况下，不可能轻松地更换组件。换人了。

不同的组件必须彼此了解，并且一些实现细节相互泄漏。隔离断开。不过，可以通过使用内部API网关或消息队列作为组件之间的接口来解决此问题。

最后一个原则是“ 零浪费” ，因为在此模型中不会出现二次计费。

异步协调器

这种模式涉及称为有限状态机（FSM）的概念的使用。如果您不熟悉，请先阅读我们最近发表的介绍性文章，然后再继续。

在FSM中，可以：

轻松更换组件而不会破坏系统的其余部分使组件充当完整的黑匣子，而无需彼此了解或实现细节泄漏避免双重计费

此模式的一些其他优点：

并行运行多个任务在流程的特定步骤失败时轻松处理重试处理复杂的逻辑，例如：

<code style="background: rgb(41, 41 , 46 ); color: rgb(239, 240 , 249 ); white-space: pre; margin: auto; padding: 0 px; border-radius: 2 px; font-size: inherit; vertical-align: 0 px; max-width: 100 %; line-height: 1.6 em;">if Step_1 returns True :
    run Step_2
else:
    run Step_3
</code>

与上面讨论的异步消息传递一起，这是用于无服务器功能组合的最常用和成功使用的模式之一。

尽管它难以实施，部署和测试，但它可以满足更复杂的工作流程的需求，同时仍可提供可扩展且可维护的体系结构设计。

大多数云服务提供商将拥有FSM的托管/无服务器产品，从而大大简化了实施和维护。例如，AWS具有StepFunctions服务。

披露：我是 Dashbird （无服务器监视平台） 的开发人员倡导者 。 该文章最初发布在 Cloud Knowledge Base中 。