微服务之间的通信

微服务架构中,服务间的通信不同于单体应用的内部调用,需要使用进程间通信(IPC)机制。主要的交互方式包括一对一和一对多的同步与异步通信,如请求/响应、通知、发布/订阅等。定义API时,使用接口定义语言(IDL)至关重要,考虑使用API优先的方法。处理API变更和部分失败时,要应用超时、限流、断路器等策略。通信技术包括基于消息的异步通信(如AMQP、STOMP)和同步的请求/响应IPC(如REST、Thrift)。消息格式通常选择JSON或XML,二进制格式更高效但可能更复杂。选择合适的IPC技术和消息格式对于微服务的稳定性和性能具有重大影响。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在monolithic单体应用程序中,不同的组件之间通过编程语言级别的方法或函数调用相互调用。 相反,基于微服务的应用程序是在多台计算机上运行的分布式系统。 每个服务实例通常是一个进程。 因此,如下图所示,服务必须使用进程间通信(IPC)机制进行交互。

In a microservices application, the services need an inter-process communication (IPC) mechanism (whereas modules in a monolith can call routines)

交互方式

为服务选择IPC机制时,首先考虑服务如何交互是必要的。 客户端⇔服务交互方式多种多样。 它们可以沿两个维度进行分类。 第一个维度是互动是一对一还是一对多:

  • 一对一–每个客户端请求仅由一个服务实例处理。
  • 一对多–每个请求由多个服务实例处理。

第二个维度是交互是同步还是异步:

  • 同步–客户端期望服务及时响应,甚至在等待时可能会阻塞。
  • 异步-客户端在等待响应时不会阻塞,并且响应(如果有的话)不一定会立即发送。

下表显示了各种交互样式。

One-to-One One-to-Many
Synchronous Request/response  — 
Asynchronous Notification Publish/subscribe
Request/async response Publish/async responses

存在以下类型的一对一交互:

  • Request/response–客户端向服务发出请求并等待响应。客户希望响应能够及时到达。在基于线程的应用程序中,发出请求的线程甚至可能在等待时阻塞。
  • Notification (也称为单向one‑way 请求)–客户端向服务发送请求,但不希望或未发送答复。
  • Request/async response–客户端将请求发送到服务,该服务以异步方式答复。客户端在等待时不会阻塞,并假设响应可能不会在一段时间内到达。

一对多互动有以下几种:

  • Publish/subscribe–客户端发布通知消息,该消息由零个或更多感兴趣的服务使用。
  • Publish/async responses –客户端发布请求消息,然后等待一定时间以等待感兴趣的服务的响应。

每个服务通常使用这些交互样式的组合。对于某些服务,单个IPC机制就足够了。其他服务可能需要结合使用IPC机制。下图显示了当用户请求一个旅行时,出租车服务应用程序中的服务如何交互。

A microservices-based taxi-hailing app can use a variety of communication methods: notification, request-response, publish-subscribe

服务使用notifications, request/response, 和publish/

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值