为什么微服务需要相互沟通？

Question

我是新来的，但是如果我们面对+很少的不同的微服务，我就是不明白为什么我们需要他们中的任何一个来互相交流，如果我们可以通过前面的axios来操纵他们之间的数据。如果我们同时使用前端和后端微服务，事件总线和事件驱动架构的目的是什么？

好的，举我的例子，我使用了5种微服务。其中有两个：

cart

• Posts

• 购物中心

我想直接访问微博，通过事件总线传递他们的数据，这样购物车微型服务就有了它的信息。原因是，posts和购物车都有不同的数据库，所以这样做是一个很好的例子，还是仅仅通过axios服务的前端呢？

Answer 1

对于一个非常简单的应用程序来说，您的建议可能是正确的，它甚至不需要像微服务这样的体系结构。服务为什么需要通信是很清楚的：

有些服务在客户端甚至是不可访问的(如安全性)，因此必须在其他后端服务中启动对这些服务的更改，这样的priviledge

• some更改将在后端服务中引发，而不是在客户端中引发，例如用于执行某些任务的cron作业--

• --它将对可重用性产生疑问，因为您必须考虑该服务不仅由客户端使用，而且如果您希望您的服务被公共使用，则会在任何environment

• what中发生更改，如果它们没有有意地或错误地实现所需逻辑的一部分，那么使客户端所做的一切都可能非常复杂，并且会减少flexibility

• some服务，例如身份验证作为确保安全的支持机制(或除主要逻辑之外的任何东西)，这些服务应该由需要它们的服务(

)直接通信。

至于问题的第二部分，这取决于几个因素，如您的业务需求&模型、所需的可伸缩性、性能、可用性等，因此正确的答案或另一种说法是不同的。

对于您的问题，使用事件总线(这是异步的)并不是一个好的解决方案，因为它会损害您的服务的一致性。相反，像posts service中简单的API调用这样的同步方式是一个更好的主意。