讯息：您的讯息看起来如何

Question

此问题与服务体系结构之间的消息排队有关。关于这个话题几乎找不到。

情况： 微服务A和微服务B。微服务A处理有关实体“某物”的事务，而B需要处理。我尽量避免讨论边界问题。

在我们的案例中，A发送了一条包含事件和相关实体ID的消息，例如 事件：somethingCreated SomethingID：1234

B使用此消息，并且如果需要进一步的信息，它将使用SomethingID从A那里获取。

第二种方法是消息不仅包含上述信息，还包含诸如 事件：somethingCreated SomethingID：1234 SomeFieldKey：someFieldValue ...

精简消息： 优点： *减少网络使用 *消息结构始终相同 缺点： *如果需要按需提供来自A的信息，则必须有某种机制来捕获e。 G。网络故障

胖消息： 优点： *信息已经存在 缺点： *如果所附信息不够，怎么办？

所以它既有优点也有缺点，我的目的是概述您使用的是哪种方法。

感谢提前回答

Answer 1

简单的答案取决于它， 我们提供的服务可将所有数据及其事件公开，并且我们的服务仅共享参考ID，并且涉及事件有效负载时位于这两者之间的服务。

我们的观点是，产生事件的服务主要是控制有效载荷的内容。我们审查用例并监视事件和服务调用的使用，并相应地使有效负载更胖或更瘦。 我们的邮件大小确实有上限，但没有限制。

当数据在服务之间流动时，网络延迟对我们来说不是问题。（我的意思不是因为有效负载的增加）

因此，您需要允许您的各个服务进行呼叫。每个服务都有一个响应时间方面的SLA，当它被违反时，您可以检查，找出瓶颈并加以解决。