微服务之间的通信

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

交互方式

为服务选择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机制。下图显示了当用户请求一个旅行时，出租车服务应用程序中的服务如何交互。