事件源架构中的微服务是否应该通过REST/gRPC/等等直接相互通信？

Question

我正试图把我的注意力集中在事件源架构上。

似乎常见的建议是让小事件中包含尽可能少的信息(而不是包含所有内容的大型事件，以允许其他服务存储自己的数据)。

显然，减少服务之间的耦合是被鼓励的。因此，人们通常建议不要从一个服务直接调用另一个服务，对另一个服务进行REST/qRPC/等调用将是一件坏事。人们似乎将事件描述为服务之间应该发生的唯一沟通。

然而，在我看来，小事件和服务之间没有直接的交流是不可能的。例如，订单服务可能需要知道存储在产品服务中的产品的名称。

事件源架构中的微服务是否应该通过REST/gRPC/等等直接相互通信？

Answer 1

在使用微服务时，最关心的是处理请求所需的时间。这意味着您必须管理同步响应时间。重要的是要认识到设计决策的影响。当用户从网站发出请求时，有效响应需要一段时间。

异步调用

异步调用允许您尽快向调用方提供响应，同时允许所有其他服务迎头赶上。这一概念被称为最终一致性。通常，您正在使用消息队列或类似的服务(如Kafka)通知其他服务数据已经更改。

• 您希望您的邮件只提供对其采取行动所需的信息。
  • 如果您的其他服务必须回拨以获取其他更新信息，则无需保存任何内容。

• 你必须决定你的保证是什么。
  • 大多数消息队列实现将保证消息的传递，即使服务暂时停止也是如此。
  • 如果您的微服务不能对消息做任何事情，您必须确定服务是否可以排空队列或强制执行背压。

• 将异步调用保存到不需要向用户提供答案的区域
• 更新缓存项最好是异步完成。

同步调用

没有理由一个微服务不能调用另一个微服务。浏览器可以这样做，您的服务也可以这样做。你只需要知道什么是交换：

• 请求链接增加了代码的脆性(即一个服务调用另一个服务，而另一个服务调用另一个服务)
• 请求链接也会增加给用户响应所需的时间，因为.
  • 每次调用都有序列化/反序列化开销。
  • 在路径中的每一步都有处理发生。

• 也就是说，低延迟请求链接并不一定是邪恶的。
  • API网关/反向代理允许您对微服务实例进行负载平衡调用。
  • 一些端点允许优化对其他端点的调用(即GraphQL联合)

• 您应该使用断路器模式来响应默认响应，或者用微服务的不同实例重试请求。
  • 有时，由于垃圾收集或其他一些不确定的原因，服务会陷入无响应状态。
  • 通过设置您愿意等待响应的最长时间，可以限制用户必须等待的时间。

底线

您可能需要明智地在解决方案中同时使用异步调用和同步调用。没关系。异步通知其他服务的主要优点是，在向用户发送响应之前，不必等待所有内容同时更新。另一个优点是，当数据更改或被访问时，您可以提供复杂的算法，而无需等待计算完成。

让用户等待的时间越短，web应用程序的响应性就越强。使用最合适的方法来处理请求。

Answer 2

我正试图把我的注意力集中在事件源架构上。

请注意，您在这里描述的是一个事件驱动的体系结构。事件来源确实意味着一些不同的东西。

如果我们讨论的是一个微服务体系结构，那么我们希望能够一次重新部署一个微服务。即使在重新部署邻居时，自治的微型服务也需要能够取得进展。这就产生了一个问题--如果我的服务正在等待您的服务的答复，并且您的服务正在重新部署，它就无法取得进展。

通常的答案是使用数据副本--我的服务可以取得进展，因为它缓存了它从您那里需要的信息的副本。换句话说，如果我们同意异步交换消息，而不是同步交换消息，那么当一个微服务不可用时，就不会出现级联中断。

事件是“公正”的消息；您需要有某种方式在系统中的微服务之间交换消息。根据您所面临的情况选择合适的传输方式。例如，Atom Syndication / Atom Pub为您提供了一个很好的标准，可以将消息添加到许多组织都非常了解的集合中；但是，当您处理的是同一家公司拥有的、彼此接近的一组封闭的微服务时，您可能不希望这些类型的权衡。另一种选择是使用消息总线。或者让您的微服务共享一个公共消息存储。

然而，在我看来，小事件和服务之间没有直接的交流是不可能的。例如，订单服务可能需要知道存储在产品服务中的产品的名称。

在某种程度上，它来自于职责的分离--为什么订单服务需要的不仅仅是一个不透明的产品标识？这是否表明在其他地方存在设计缺陷？

过去的许多数据设计在空间上都受到了严格的限制；为了节省空间，我们希望每个事实都有一个副本。我们今天所做的交易是不同的，由于存储成本低廉，拥有一个数据副本就不那么重要了(我们仍然需要考虑哪些数据是副本，哪些数据具有权威性)。

所以是的，如果订单服务必须有产品名称，那么一定有一条消息会带来这些信息。因此，这个信息需要一些交通工具才能到达它需要去的地方。

另见Pat Helland：外面的数据...