微服务内部沟通

 

我一直在阅读微服务架构，但我仍然无法理解微服务间通信机制。
他们在很多文章中表示，微服务通常暴露在RESTful API之上。 但是当你搜索互联网时，你总会看到基于消息和后端通信事件的实现。

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

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

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

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

  • 基于一个服务事件，您希望更新其他服务：在这种情况下，首选样式是消息传递总线，其中一个服务发出事件并且多个其他服务在消息传递总线上有一个监听器并作出相应的反应。 例如：让客户服务中的客户名称更新时，您想要更新客户的订单服务的缓存名称，在客户服务中更新名称时，它会发出客户名称更新事件，订购订单服务，然后对它做出反应

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

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

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

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

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

    我强烈建议您阅读Microservices Expert - Chris Richardson的链接

    链接地址: http://www.djcxy.com/p/34091.html

    上一篇: Microservice internal communication

    下一篇: What the hell is microservice?