微服务内部通信

Question

我一直在阅读微服务架构但我仍然无法理解微服务间通信机制。
在许多文章中，他们说微服务通常是通过RESTful API公开的。但是当您搜索互联网时，您总会看到基于消息传递和后端通信事件的实现。

所以我很困惑，REST API是所有微服务的标准，或者我们可以看到没有REST端点的微服务。

Answer 1

对于您的问题，首先让我们了解一个服务相互交互的方式，让我们创建两个服务订单服务和客户服务：

1. 一项服务需要来自其他服务的一些数据来处理其请求，例如：假设你想要下订单，所以从ui你必须点击http请求订购服务（可以休息，或者有一个api网关）在n之间使用其他协议如protobu来调用订单服务来下订单，现在假设订单服务需要检查客户的有效性，所以订单服务需要同时调用客户服务 - 最有可能你会休息或者创建一个protobuf或在服务之间有一个持久的websocket，然后在客户服务响应后，订单服务继续前进。

在这种情况下，需要模仿同步通信，一种直接的方法是休息或原型，或通过消息模仿它

1. 基于一个服务事件，您希望更新其他服务：通常，首选样式是消息传递总线，其中一个服务发出事件，而多个其他服务在消息传递总线上具有侦听器并相应地做出反应。例如：假设在客户服务中更新客户名称，您要在订单服务中更新客户的缓存名称，此时在客户服务中更新名称时，它会发出客户名称更新事件，订购服务订阅它，然后对它作出反应

你的第三个问题是，是否有可能没有休息端点的服务:::是可能的，但每个服务都需要可以访问。所以需要使用休息或其他形式

上面提到的链接：microservices.io非常好，再次通过它

Answer 2

benefits of using microservices中的一个（如果不是最大的话）是它消除了对技术堆栈的任何长期承诺。在开发新服务时，您可以选择新的技术堆栈。同样，在对现有服务进行重大更改时，您可以使用新技术堆栈重写它。

因此，您可以选择您想要的任何通信机制，只要它不会阻止您更改技术堆栈。 REST over HTTP是一个不错的选择，因为它隐藏了微服务使用的技术，以请求 - 响应同步方式生成响应。基于消息的通信也很合适，因为消息还可以隐藏用于生成它们的技术（只要您不使用生成器编程语言的内置序列化），即RabbitMQ或{ {3}}

Answer 3

REST不是微服务到微服务（也称为进程间通信/ IPC）的唯一样式，但它是基于微服务的应用程序使用的最流行的 IPC技术 - 风格建筑。还有其他技术，例如Apache Thrift和gRPC，可以达到同样的目的。基本上所有这些技术都是RPC（远程过程调用）的行业级实现。

我强烈建议您通过微服务专家阅读此link - Chris Richardson

Answer 4

REST受到普遍支持，它在所有语言中都被接受，如果所有后端服务都在同一位置运行，那么吞吐量可能会有所不同。

无论如何，如上所述投资和学习gRPC或Thrift是一个好主意，您可以将所有内部服务转换为gRPC（例如大多数语言支持），并在Universal Gateway上进行gRPC和REST之间的转换。

内部架构有两种方法，即CQRS与普通REST调用。事件/消息传递是CQRS的一个示例，您可以在其中分离读/写端操作，并且可以通过事件实现所有写侧操作，以获得更好的可伸缩性和吞吐量。