34.微服务之间的通信

简介

在单体应用中，各模块之间的调用是通过编程语言级别的方法或者函数来实现的。而基于微服务的分布式应用是运行在多台机器上的；一般来说，每个服务实例都是一个进程。

因此，如下图所示，服务之间的交互必须通过进程间通信（IPC）来实现。

后面我们将会详细介绍 IPC 技术，现在我们先来看下设计相关的问题。

交互模式

当为某个服务选择 IPC 时，首先需要考虑服务之间的交互问题。客户端和服务器之间有很多的交互模式，我们可以从两个维度进行归类。

第一个维度是一对一还是一对多：

• 一对一：每个客户端请求有一个服务实例来响应。

• 一对多：每个客户端请求有多个服务实例来响应。

第二个维度是这些交互式是同步还是异步：

• 同步模式：客户端请求需要服务端即时响应，甚至可能由于等待而阻塞。

•异步模式：客户端请求不会阻塞进程，服务端的响应可以是非即时的。

下表显示了不同交互模式：

一对一的交互模式有以下几种方式：

1.    请求/响应：一个客户端向服务器端发起请求，等待响应，客户端期望此响应即时到达。在一个基于线程的应用中，等待过程可能造成线程阻塞。

2.    通知（也就是常说的单向请求）：一个客户端请求发送到服务端，但是并不期望服务端响应。

3.    请求/异步响应：客户端发送请求到服务端，服务端异步响应请求。客户端不会阻塞，而且被设计成默认响应不会立刻到达。

一对多的交互模式有以下几种方式：

4.发布/ 订阅模式：客户端发布通知消息，被零个或者多个感兴趣的服务消费。

5.发布/异步响应模式：客户端发布请求消息，然后等待从感兴趣服务发回的响应。

每个服务都是以上这些模式的组合。对某些服务，一个 IPC 机制就足够了；而对另外一些服务则需要多种 IPC 机制组合。

下图展示了在用户叫车时，打车应用内的服务是如何交互的。

上图中的服务通信使用了通知、请求/响应、发布/订阅等方式。例如，乘客在移动端向“行程管理”服务发送通知，请求一次接送服务。“行程管理”服务通过使用请求/响应来唤醒“乘客服务”来验证乘客账号有效，继而创建此次行程，并利用发布/订阅来通知其它服务，其中包括定位可用司机的调度服务。

现在我们了解了交互模式，接下来我们一起来看看如何定义 API。

定义 API

API 是服务端和客户端之间的契约。无论选择了何种 IPC