“出租车”交互示例

让我们仔细看看什么是 REST API。它基本上是一种交互模式；系统可以相互交互的方式。

REST API 交互：

为了理解这两种交互形式，让我们考虑一个等效的现实生活用例，即用户从代理处订购出租车。

现在，用户问这个问题：“我的出租车什么时候到达？” 在 REST API 措辞中，请求的用户是**“消费者”，响应的机构或个人是“提供者”（又名“生产者”）**

上面显示的这种实时交互与REST API的工作方式完全匹配。它转化为以下内容：

现在让我们换个问题：“我的车准备好了吗？”

由于答案不是预期的，消费者将继续直到他们最终收到预期的答案。从人类的角度来看，这种情况是相当重复和烦人的。

以上从消费者到生产者的重复查询集模仿了以下 API。

REST API 限制

那么，这两个例子有什么区别呢？是时候了！

**信息的价值随着时间的推移而降低。**但是，对于所有信息，速率的下降并不相同。

让我们再看一下“打车”的例子来理解“信息价值与时间的比例”

驾驶室的估计到达时间可能仅在驾驶室到达之前是相关的。

最重要的是，当用户积极等待出租车以便及时到达某个地方时，没有什么比这个“你的车已经到了”通知更重要了。而一旦行程开始，这个通知就没有任何价值了。

还有很多其他此类实时场景，其中很少有：

• 股市
• 库存
• 送餐服务

在很短的时间内具有很高的价值。

一个人可以问“我的骑行准备好了吗？”

机器很容易提供资源的状态，例如“准备好/未准备好”。但预测（“10 分钟内到达”）很少见。

要具有相关性，它必须是准确的。如果它在预计的时间还没有准备好怎么办？如果提前准备好呢？这是一个非常复杂的问题。它们是处理这个问题的简单得多的方法。

如果我们能问“什么时候准备好告诉我”，问题就迎刃而解了。

REST API 交互模式意味着消费者总是发起与提供者的交互。这就是它的工作原理。因此，使用 REST API 无法要求“知道它何时准备就绪”。你猜怎么着？

这正是事件驱动 API 提供的价值。

事件驱动的 API 交互：

事件驱动的 API 交互模式不同于 REST API。我们将在下面看到，如何。有多种形式，其中两种流行的是：

• 网络钩子

• 流媒体

Webhook（用“taxi-ride”场景描述）

让我们回到上面讨论的“出租车”示例。并使用“告诉我我的旅程何时准备就绪”交互模式。

我们可以在这里清楚地看到差异。现在该事件由提供者（生产者）发起，在本例中为出租车代理。消费者必须定义生产者可以调用的端点（即 URL），以便将通知发送给消费者。一旦信息准备好，就会通知消费者。

这种交互类型称为Webhook，是异步 API 的首选样式。

这种交互构成了均匀驱动架构的基础。

API 流式处理（用“出租车”场景描述）

让我们稍微改变一下提供者的能力。而不是回答“准备好/未准备好”，现在的答案是出租车的当前状态。

机器告诉资源状态是很自然的。

这将允许另一种交互：API Streaming。

上面的API版本是：

消费者实时接收状态的每个变化。

通常，Webhook旨在从应用程序到应用程序，而Streaming更针对于与用户端的人进行实时交互，直接实时消费信息。

现在从微服务架构模式的角度来看这个

设计微服务有不同的方法，本博客主要关注微服务架构模式，请求驱动和事件驱动。

什么是微服务？

它是一个松耦合、高度可测试、独立部署、定义清晰的业务领域边界并由相对较小的团队轻松维护的应用程序。

请求驱动的微服务

电子商务应用示例

优点

• 有明确的流程控制，看编排器的代码，我们可以确定动作的顺序。

权衡取舍

• 单点故障 如果 Orchestrator 服务出现故障，这将是单点故障。当此服务关闭时，整个流程将不会执行。

• 重播数据以进行恢复并不容易 没有简单的方法可以通过重新处理对依赖服务的失败调用来恢复操作。

• 紧密耦合的服务（相对） 如果依赖服务之一出现故障，则很有可能排除对其他服务的调用。依赖服务的 Rest API 不能轻易修改。如果改变了，API的消费者也需要修改。因此，微服务不是松耦合的。

事件驱动的微服务

让我们将之前的请求驱动应用程序转换为事件驱动的电子商务应用程序。

事件驱动架构的优势

• 松耦合服务 消息的生产者不需要知道哪个服务有兴趣接收它。这使得以后在不影响现有功能的情况下添加附加功能变得更加容易。

• 异步 当您发出一个事件时，它是异步的，这意味着微服务可以立即继续其工作，而无需等待事件的使用者完成。这意味着事件峰值不会减慢用户界面或其他关键功能。

• 可扩展性 由于微服务专注于做好一件事而不与其他服务紧密耦合，因此您可以单独扩展具有最大工作负载的服务，以确保每个微服务的工作日志都是最新的。

• 恢复 事件是易于存储的时间点事实，并且与任何其他数据自然分离。

• 可维护性 事件可以通过重放事件日志简单地丢弃并用新模式重新填充。不再需要复杂的数据迁移！

权衡取舍

• 没有中央协调 器 没有明确的中央位置（协调器）来定义整个流程。
• 回滚很复杂 管理分布式事务可能很复杂。有多个服务消耗一个事件，因此，如果其中一个服务发生异常，那么整个流程应该发生什么或实现回滚过程是具有挑战性的。

结论

两种模式都有好处，权衡取舍，它们的适用性还取决于用例。还可以根据应用需求选择使用混合架构。但是，如果有机会实现事件驱动的微服务，那肯定会为构建松散耦合的微服务提供良好的基础。

本文使用 文章同步助手 同步