Java 两个微服务之间的通信

我正在创建一个具有微服务体系结构的项目。我创建了两个微服务

---

其中一个用于产品实体，另一个用于票据实体。它们有自己的端点，并通过网关连接在一起（我使用的是jhipster microservices体系结构）

该法案允许ms访问产品列表。我想知道如何在这两位女士之间进行沟通。我有三种想法：

从bill ms向类似rabbitMQ的队列发送请求，以从product ms获取具有这些ID的产品（我不知道这其中的瓶颈是什么）

向gateway发送产品服务请求并从那里获取产品（我担心延迟，因为它们之间的数据量很大，这样我就不会直接接触数据库，所以我总是依赖gateway）

我可以复制bill ms中的存储库、服务和实体（这是一种丑陋的方式，我认为它打破了ms体系结构的规则，维护非常困难）

如果你有任何其他方法，我感谢你与我分享

编辑

现在我知道了瓶颈是什么：假设有3个bill ms实例，rabbitMQ如何决定响应哪个实例？或者，我该如何对ribbon说“给我bill ms的免费实例，以订阅rabbitMQ的请求”，实现负载平衡

---

我不确定我要回答的是否正确。我还在自学。。但我可以告诉你我是如何实现我的微服务尝试的

首先，我从

HTTP

基于通信的微服务开始。这很好，但问题是，您在服务之间创建了依赖项服务A需要知道A服务B并需要直接呼叫它（当然是通过服务发现等）。这是开发微服务时通常要避免的

我最近开始使用的另一种方法是使用

消息总线

。这实际上是你在问题中提到的第三个选项

我有一个服务a，它存储人（只是一个例子）。当服务创建一个新人时，它所做的是：它在

RabbitMQ

总线上发送

事件
：
personCreatedEvent
。
如果有任何其他服务对这样的活动感兴趣，他们可以订阅。这些感兴趣的服务将其感兴趣的相关信息保存在自己的数据存储中

使用最后一种方法，您的服务之间并不存在真正的依赖关系，因为它们之间不直接通信服务A不知道服务B，因为B只是将事件发送到
RabbitMQ
，发送给对这些事件感兴趣的服务，反之亦然

当然，您可以通过服务在数据存储之间进行复制。但这也可能有利可图，例如，服务B不需要使用与服务A相同的模式或数据存储机制。它只以最适合此服务的方式存储相关信息。
您看过第2部分：服务间通信部分了吗。它将引导您通过一个具体的示例来了解如何实现这一目标。让我尝试在这个场景中添加更多的细节，以强调在产品和Biiling的上下文中，哪些可以或哪些不可以作为事件。只有在下订单的情况下，计费MS才需要与产品MS交谈。下订单主要是针对一个单独的MS，比如Order-MS。当创建或下订单时，它将包含作为行项目的产品信息

订单的创建可以视为一个事件。当订单创建事件发生时，可以将其推送到计费服务的队列中。队列应在RabbitMQ中实现为工作队列。这样，计费MS的多个实例可以订阅同一个队列，但它将由一个且仅由一个工作者处理。RIBBON在将服务注册为RabbitMQ的工作程序时没有角色。每个实例注册到一个队列，RabbitMQ决定轮询哪个计费服务实例来处理此事件

为计费Ms获取订单中产品的详细信息应该是通过Ribbon进行的服务对服务呼叫负载平衡（如果您正在使用）。获取产品详细信息并不是一个真正的事件，下订单才是，因此不同

此外，网关还应用于公开边缘服务。对于服务到服务的呼叫，通过网关服务跳转并不理想。
一个选项是使用eureka注册表上的注册名称向bill microservice发送请求。
您也可以重新考虑您的服务边界，可能您的服务太细了。复制可能不是坏事，如果你认为你的产品可能会消失或可能被修改在他们的数据库中，而在法案中，你希望他们保持不变很长一段时间，在这种情况下，我会认为这是一个复制，但只存储不可变的信息有关的产品，你的账单需要。“我使用的是jhipster微服务体系结构“.JHipster只是一个没有自己架构的图书馆..JHipster不是一个图书馆，它是一个应用程序生成器，恰好在spring cloud netflix之上实现了微服务体系结构。因此，更大的问题是：当你们确实有让数据彼此可用的问题时，为什么要走微服务的道路？我建议从一个适当模块化的整体开始。永远不要做选项3，因为这样你就根本不需要微服务了。不要害怕选项2，spring netflix world为即将出现的问题（eureka、feign、ribbon、hystrix等）提供了大量解决方案，可以使用负载平衡（按ribbon）discov