微服务架构实战学习（二）：微服务间的通信

接上篇，之前我们说道，微服务就是我们将大事化小，小事化了...（暂时不能化了...）

可是问题来了，你拆是拆开了，可是你拆开的只是肉体，拆不开的是灵魂。你把用户服务都拆分出去了，那么其他服务（比如邮件收发服务）想要验证一下用户登录时，他要怎么告诉用户服务。因为在此时，极大的可能是用户服务与邮件收发服务已经是两个独立的进程且已经运行在不同的服务器上了。于是，我们引出了我们的微服务间的通信。

一、微服务的通信协议

上面我们提到了微服务架构中各服务是独立运行且极大可能是在不同服务器上运行。因此，各服务间的通信就是一种不同进程间的远程调用的机制了。即 RPC 通信。

IPC

在说 RPC 前，我们先说说 IPC。IPC 全称是 Inter Process Communication，中文大致可译为操作系统的进程之间的相互通信。

为什么操作系统的进程之间需要相互通信呢？为了资源的协调使用，使之能够和谐共处。

这可以类比于我们平常的工作中。比如，一个公司中的张三是一个超级打字员，手速飞快，手起刀落...它是个重度咖啡依赖患者，少了咖啡打字速度骤降不说，还打瞌睡。而李四是公司的一个 PS 高手，每天 P 的图连起来可达 200 斤，他是一个文艺装 * 青年，手上不捧杯咖啡就不会 P 图。

于是这里面有两个问题，第一，张三李四都不想自己花钱单独买一个咖啡机（有公司免费的，本着有便宜不占王八蛋的心理）。第二，公司的咖啡机一次只能打一杯咖啡。

那么，公司为了使大家达到资源的有效利用，就出点子了：规定谁用完咖啡机必须大喊三声，其他人听到暗号才能去使用咖啡机...

操作系统中的进程在使用电脑的资源也一样，在很多时候都可能需要进行通信，而 IPC 就是提供这种通信的规范（接口）。

RPC

什么是 RPC 呢？RPC 全称是 Remote Procedure Call 中文直译为远程过程调用。

上面我们说到同一个公司的两位同学怎么使用咖啡机，可是，现在公司做大了，全国都有分公司了。在北京同学 A 就想喝杭州分公司前台小姐姐旁边的那台咖啡机打的咖啡？？？原因是那个咖啡机打出来的咖啡苦中带咸，口感一流。

老板一看，既然这么你们实在这么爱喝，那就成全你们吧。公司搞个内部点餐平台，你只需要提一个具体的咖啡申请，立马给你响应请求并安排研磨与配送上门，至于怎么排优先级，怎么磨咖啡，用什么快递送货上门你都不用管。你只负责下单和付钱....

这一整套点咖啡送咖啡就像我们的 RPC 协议。是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

注：以上情节纯属虚构，如有雷同，概不负责。

二、微服务的通信模式

微服务间的通信模式大概分如下两种：

2.1 一对一还是一对多？

1. 一对一：每个客户端请求有一个服务实例来响应
   北京的张三同学单点了一杯来自台湾分部的咖啡。

2. 一对多：每个客户端请求有多个服务实例来响应
   上海的李四同学点了一份武汉的周黑鸭和一份南京的鸭血粉丝汤（真够折腾）

2.2 同步还是异步？

1. 同步模式：客户端请求需要服务端即时响应，甚至可能由于等待而阻塞
   张三点了咖啡后他希望能立即送达，且咖啡到手前他啥时不干（...）

2. 异步模式：客户端请求不会阻塞进程，服务端的响应可以是非即时的
   李四点了咖啡后开始写代码，其他的他不管，快递送上咖啡了他取了就喝。

2.3 一对一的交互模式

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

2. 通知（也就是常说的单向请求）：一个客户端请求发送到服务端，但是并不期望服务端响应。
   小明发送一条消息给某分部的小姐姐并说道：“小姐姐你真漂亮”。他并不期望小姐姐能回他，因为他知道小姐姐并不会理他...

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

2.4一对多的交互模式

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

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

2.5 处理部分请求失败

对于分布式的微服务，必须要面对的一大问题就是局部请求失败的处理。

Netfilix 提供了一个比较好的解决方案，具体的应对措施包括(摘自“Chris Richardson 微服务系列”)：

• 网络超时：在等待响应时，不设置无限期阻塞，而是采用超时策略。使用超时策略可以确保资源不被无限期占用。
• 限制请求的次数：可以为客户端对某特定服务的请求设置一个访问上限。如果请求已达上限，就要立刻终止请求服务。
• 断路器模式（CircuitBreakerPattern）：记录成功和失败请求的数量。如果失效率超过一个阈值，触发断路器使得后续的请求立刻失败。如果大量的请求失败，就可能是这个服务不可用，再发请求也无意义。在一个失效期后，客户端可以再试，如果成功，关闭此断路器。
• 提供回滚：当一个请求失败后可以进行回滚逻辑。例如，返回缓存数据或者一个系统默认值。

三、RPC 框架

RPC 框架就类似于干了那些诸如派单、物流等等一系列事情的平台。

如何选择 RPC 框架呢？
请听下回分解...

注：文中部分内容摘自网络，如有侵权，请与我联系。