微服务内部通信

Posted 2023-03-15

【中文标题】微服务内部通信

【英文标题】：Microservice internal communication

【发布时间】：2018-06-30 10:31:17

【问题描述】：

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

【问题讨论】：

不，REST API 不是 所有微服务的标准。是的，您可以在没有 REST 端点的情况下查看微服务。

那么，我们可以说客户端发现模式效率不高，因为客户端负责在可能使用协议的微服务之间对请求进行负载平衡，例如AMQP 消息传递协议，所以这种模式迫使我们提高客户端的智能级别？

我会回答我的问题。有一些系统，如 RabbitMQ 可以将客户端的 http 请求转换为 AMQP 或其他协议。因此，多亏了这个交换点，使用的协议不再是问题。

【参考方案1】：

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

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

这种情况下需要模仿sync通信，直接的一种方式是rest或者protobuff，或者通过messaging来模仿

基于一个服务事件，您想更新其他服务：在这种情况下，通常首选的样式是消息总线，其中一个服务发出事件，而多个其他服务在消息总线上有一个侦听器并做出相应的反应。例如：假设在客户服务中更新客户名称时，您想在订单服务中更新缓存的客户名称，在这种情况下，当客户服务中更新名称时，它会发出客户名称更新事件，订单服务订阅它，然后做出反应

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

上面提到的链接：microservices.io很好，再过一遍

【参考方案2】：

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

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

【参考方案3】：

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

我强烈建议您阅读微服务专家 - Chris Richardson 撰写的 link

【参考方案4】：

REST 受到普遍支持，所有语言都接受它，如果您的所有后端服务都在同一位置运行，您可能不会发现吞吐量有太大差异。

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

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