简介

在一个monolithic应用程序中，组件彼此调用是通过语言级别的方法或函数调用完成的。相反地，一个基于微服务的应用程序是运行在多台机器上的分布式系统。每个服务实例通常是一个独立的进程。

因此，如图3-1所示，服务之间需要使用一种 IPC 机制来进行交互。

在我们讨论具体的 IPC 技术之前，让我们先来看看各种交互设计思路。

Interaction Styles

当为一个服务选择 IPC 机制时，首先应该思考服务之间是如何进行交互的。存在很多客户端-服务器交互方式。可以从两个维度来划分交互方式。第一个维度，交互是一对一还是一对多的：

• One-to-one：每个客户端请求只被一个服务实例处理
• One-to-many：每个客户端请求被多个服务实例处理

第二个考虑维度，交互是异步的还是同步的：
• Synchronous–Theclientexpectsatimelyresponsefromtheserviceandmighteven block while it waits
• Asynchronous – The client doesn’t block while waiting for a response, and the response, if any, isn’t necessarily sent immediately.

• 同步：客户端希望得到服务的及时响应，在得到响应以前甚至可能会一直阻塞
• 异步：客户端在等待响应时不会阻塞，服务端也不必立即响应结果

下表总结了各种交互方式。

有以下几种 one-to-one 的交互方式，既有同步的也有异步的：

• Request/response：客户端向服务发起请求，客户端希望响应结果能立即到达。在一个基于多线程的应用程序中，处理请求的线程可能会因为等待响应而阻塞住
• Notification：也被称作 one-way request，客户端向服务发起请求，但不需要响应
• Request/async response：A client sends a request to a service, which replies asynchronously The client does not block while waiting and is designed with the assumption that the response might not arrive for a while.

有以下两种一对多交互方式，都是异步的：

• Publish/subscribe：客户端发出通知消息，该消息将被0个或多个感兴趣的服务消费
• Publish/async responses：A client publishes a request message, and then waits a certain amount of time for responses from interested services

每个服务通常会是使用以上这些交互方式的一种组合。对某些服务来说，使用一种IPC 机制就可以了，而其他服务可能会需要使用一种组合方案。

图3-2显示了，当打车软件中的用户发起一个行程时，软件中的所有服务可能是如何交互的。

图示叫车服务使用了notifications、request/response和 publish/subscribe 三种交互方式的组合。例如，乘客的智能手机发送了一个notification到 行程管理服务请求搭载。行程管理服务采用request/response 方式调用乘客管理服务来验证乘客账户是否在线。然后行程管理服务创建行程，并采用 Publish/subscribe 方式去通知其他服务，包括分配司机服务，该服务职责是定位一个有效的司机。

在已经了解了交互方式后，让我们看看如何来定义 API。

Defining APIs