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

在微服务中，采用中心化的思想，将单体应用拆分为多个中心，中心之间分布部署，那么面临的问题之一就是，中心与中心之间怎么通信：

一、微服务的通信协议

IPC

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

为什么操作系统的进程之间需要相互通信呢？为了资源的协调使用，使之能够和谐共处。比如：两个进程A、B在执行的过程中都要访问 资源W，为了避免A和B同时抢夺资源，造成死锁的现象，我们规定在A使用完了资源以后，需要通知B可以使用资源了，这时就需要用到IPC，IPC提供了这种通信的规范（接口）。

RPC

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

二、微服务的通信模式

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

2.1 一对一还是一对多？

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

2.2 同步还是异步？

1. 同步模式：客户端请求需要服务端即时响应，甚至可能由于等待而阻塞
2. 异步模式：客户端请求不会阻塞进程，服务端的响应可以是非即时的
    

2.3 一对一的交互模式

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

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

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

2.4一对多的交互模式

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

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

2.5 处理部分请求失败

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

Hystrix [hɪst'rɪks]，中文含义是豪猪，因其背上长满棘刺，从而拥有了自我保护的能力。本文所说的Hystrix是Netflix开源的一款容错框架，同样具有自我保护能力。

Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性、容错性与局部应用的弹性，是一个实现了超时机制和断路器模式的工具类库。

• 使用命令模式将所有对外部服务（或依赖关系）的调用包装在HystrixCommand或HystrixObservableCommand对象中，并将该对象放在单独的线程中执行。
• 每个依赖都维护着一个线程池（或信号量），线程池被耗尽则拒绝请求（而不是让请求排队）。
• 记录请求成功，失败，超时和线程拒绝。
• 服务错误百分比超过了阈值，熔断器开关自动打开，一段时间内停止对该服务的所有请求。
• 请求失败，被拒绝，超时或熔断时执行降级逻辑。
• 近实时地监控指标和配置的修改。

三、RPC 框架

RPC 框架就类似于干了那些诸如派单、物流等等一系列事情的平台。而服务调用方只需要订阅另一个服务提供方的服务，RPC 框架就会把结果扔给服务调用方。

1.1 alibaba dubbo（Dubbox）

dubbo 是 alibaba 前几年开源的 RPC 框架，后来停止维护。Dubbox 是当当在 alibaba 停止维护后基于 Dubbo 而维护的 RPC 框架项目。现在，alibaba 又开始了对 dubbo 的维护，而且项目已经捐献给了 apache 基金会，期待 ali 为开源项目提供更多的支持以及维护。

1 dubbo 架构图

 

Dubbo 架构图

从架构图上我们可以看到 0、1、2 这三步是服务启动时的初始化工作，其中 1 就类似于某咖啡店跟某点餐平台注册账号一样，2 就类似于需要点餐的用户也在点餐平台上来注册账号。

3 则表示如果服务提供者的地址发生了变化，就通知给服务调用者。这类似于咖啡店的的电话变了，平台会通知到用户。

4 服务调用者从注册中心拿到服务提供者的地址并调用服务。这其中包括负载均衡。

5 服务消费者与提供者和注册中心之间都使用的是长连接，在调用过程中，会在内存中对调用次数进行统计，然后定时反馈给监控中心对调用进行监控。

注：

• 图中实线表示的是同步调用，而虚线则表示的是异步调用。
• 消费者与提供者之间使用的是非阻塞IO(NIO)

2 dubbo github 地址

 

https://github.com/apache/incubator-dubbo

3 dubbox 官方中文文档地址

 

http://dubbo.apache.org/books/dubbo-user-book/

1.2 sina motan

motan 是新浪开源的服务治理框架，据说使用简单，我没使用过...

1 github 地址

 

https://github.com/weibocom/motan

2 中文文档地址

 

https://github.com/weibocom/motan/wiki/zh_overview

3 motan 架构

 

1.3 apache thrift

thrift 是 facebook 开发，后来开源并捐献给了 apache 社区，且 thrift 是一个跨语言的 RPC 框架，且支持市面上的主要的编程语言。

1 thrift 官方

 

http://thrift.apache.org/

2 文档

 

http://thrift.apache.org/tutorial/

1.4 google grpc

grpc 是 Google 开源 RPC 框架，高性能、开源、将移动和 HTTP/2 放在首位的通用的 RPC 框架，基于 HTTP/2, netty4.1, proto3, 拥有非常丰富而实用的特性，堪称 RPC 框架的典范。

但 grpc 它本身它不是分布式的

1 grpc github 地址

 

https://github.com/grpc/grpc

2 文档地址

 

https://github.com/grpc/grpc/tree/master/doc

1.5 spring cloud

Spring Cloud 完全基于 Spring Boot，服务调用方式是基于 REST API。整合了各种成熟的产品和架构，并且基于 spring boot 也使得整体的开发、配置、部署都异常的方便。

1 官方地址

 

http://projects.spring.io/spring-cloud/

2 文档地址

 

https://spring.io/docs

接下来，会进一步对上方各框架进行一些横向对比。并且，会基于 spring cloud 来进行示例开发。敬请期待

四、RPC 框架对比

对市面上比较流行的 RPC 框架的对比

 通过对比个人认为，Spring Cloud 还是微服务架构中的一个十分优越的实现方案。

 Spring Cloud 各组件架构图

关注微信公众号有惊喜：

 

本文地址：https://blog.csdn.net/u013310119/article/details/111991881