微服务通信

Question

我是微服务的新手，我正在尝试将我的项目转变为基于微服务的项目。我的问题是弄清楚每个服务如何相互通信。

首先，我探讨了REST样式服务，但如果每个服务都基于HTTP REST，那么它们之间是如何相互“交谈”的呢？

然后我尝试学习Spring Integration，但后来它变得更加清晰，他们应该如何沟通，因为现在我想到我可能需要使用RabbitMQ作为前端和微服务后端之间的中间件。

我也遇到了云和Docker技术，所以我猜每个服务都应该在云端，但它仍然没有说清楚服务是如何沟通的。

我正在使用Java，Spring技术。

如果有人能够更好地了解事情应该如何，我会很高兴。

Answer 1

你是正确的方式。使用REST架构公开服务非常强大而且简单。每个微服务都暴露了其他微服务可以调用的一些功能。您可以使用SpingMVC和注释@RestController执行此操作。要调用REST API，您可以使用Spring类RestTemplate。

您可能还需要一个网关，将请求重定向到正确的服务。我建议你试试Netflix Cloud Stack：

• Zuul。这是您的应用程序的入口点。每个请求都会发给它。它应该协调整个生态系统。
• Eureka客户端 - Eureka服务器。所有的微服务都应该以某种方式告诉某人他们已经启动并且可以接受请求。因此，您可以使用Eureka Server接受服务中的注册，并将您的微服务标记为客户端。
• 丝带。另一个重要的事情是请求的负载平衡。使用Ribbon，您可以轻松完成此任务。

如果您使用的是Spring Boot，可以使用一些注释快速设置此架构。

您可以在此处找到一个简单示例：https://cloud.spring.io/spring-cloud-netflix/

Answer 2

微服务的通信或传输机制没有标准。通常，微服务使用广泛采用的轻量级协议（如HTTP和REST）或消息传递协议（如JMS或AMQP）相互通信。在特定情况下，可以选择更优化的通信协议，例如Thrift，ZeroMQ，Protocol Buffers或Avro。

微服务之间的通信可以设计为同步（请求 - 响应）或异步（消除和忘记）样式。两种方法都有其自身的优点和约束。仅用一种方法开发系统是不可能的。根据用例需要两种方法的组合。

根据您的使用案例和要求，您应该选择最适合您项目的项目。

Answer 3

我亲自使用过Eureka发现服务。这基本上是＆＃34;木偶大师＆＃34;微服务，如果你愿意的话。每个微服务在启动时将自身注册到单独的微服务（发现服务）。因此，发现服务知道每个微服务的地址和端口，并且每个微服务可以向发现服务询问哪些（其他）微服务被注册。此外，每个微服务可以简单地向发现服务询问有关另一个微服务的信息。所有通信（在我的情况下）都是使用REST完成的，但这是一个选择，因为具有Eureka发现服务依赖性的Spring Boot可以促进它。

通过非常小的配置，您可以使整个框架正常运行。

这是基于Netflix使用的框架。我相信Eureka甚至可以成为netflix库。

Answer 4

出于两个原因，我不喜欢从服务A到服务B的直接API调用，反之亦然。首先，它创建服务A和B之间的依赖关系。其次，随着服务数量的增长，它可以轻松地创建意大利面条。我希望看到的是pub / sub模式，例如service A向传输层发布消息（RabbitMQ不是一个糟糕的选择）并继续前进。解释消息的订阅和业务逻辑很好地封装在服务B中。通过这样做，服务B根本不需要知道关于服务A的任何信息，但他们可以很好地相互交谈。

Answer 5

微服务与对方进行同步通信是一种风险，最大的问题是耦合，这意味着服务现在彼此耦合，如果其中一个服务失败了它们的家属现在将完全或部分禁用/崩溃，更好的解决方案是使用异步通信进行状态更改操作。

您希望明确区分状态更改操作和读取操作（CQS命令查询分离）。对于状态更改操作，您可以使用某种消息传递基础结构，然后开火并忘记通信。对于查询，您将使用同步请求响应通信，并且可以使用http API或直接转到数据存储。

如果您正在使用消息传递，那么您还可以查看发布订阅以在服务之间引发事件。

要考虑的另一点是（事务性）数据共享（与只读视图相对）如果暴露内部状态，读者可能会得到错误的数据状态或错误的版本，并且可能会锁定您的数据？

最后但同样重要的是，尝试尽一切努力使您的服务保持自主（至少在逻辑层面）。

希望这是有道理的。