【分布式系统遨游】分布式通信

今天我们来讨论分布式通信技术。

为什么需要分布式通信

我们之前在讲分布式资源调度的时候，把分布式系统中的各个节点与操作系统的进程做了类比。我们知道，操作系统的进程之间由于需要数据的交换，是需要进程通信机制的。那么同理，分布式系统之间同样需要通信。在业务层面，每个分布式系统一般都承载着一个微服务，所以，微服务之间也一定是需要通信的。比如，我们各条业务线均需要查询用户中心微服务的数据等等。我们常用的通信方式有三种：RPC、发布-订阅、消息队列。

RPC

在传统的B/S模式中，服务端会对外暴露接口，然后客户端通过调用这个接口来完成二者之间的通信。那么在分布式系统中，我们同样也可以采用这种模式。但是，B/S 架构是基于 HTTP 协议实现的，每次调用接口时，都需要先进行 HTTP 请求。这样既繁琐又浪费时间，不适用于有低时延要求的大规模分布式系统，所以远程调用的实现大多采用更底层的网络通信协议。我们先用一张图俯瞰一下RPC的架构：

在这里，订单系统进程并不需要知道底层是如何传输的，在用户眼里，远程过程调用和调用一次本地服务没什么不同。这，就是 RPC 的核心。即图中的第3步和第8步，对我们调用方是透明的。与我们经常使用的接口调用不同，图中的网络通信基本是基于TCP协议自己封装的一些协议。这样做可以约定通信双方的数据格式，从而让客户端封包和服务端解包更加快速，更加适用于分布式系统。这里的通信协议封装可参考Redis的RESP协议与FastCGI协议。

RPC的典型实现 - Dubbo

假设我们要自己去实现一个RPC通信框架，我们应该如何实现呢？假如我们用4个调用方与4个服务提供方，我们该如何管理他们呢？

首先，我们最容易想到的，就是服务提供方为服务调用方，提供相关的SDK，服务调用方直接引入SDK即可发起RPC调用请求，而SDK内部具体是利用什么协议，调用方并不关心。这是一种方案。但是，随着服务提供方和服务调用方越来越多，服务调用关系会愈加复杂。假设服务提供方有 n个， 服务调用方有 m 个，则调用关系可达 n*m，这会导致系统的通信量很大，SDK就显得力不从心了。此时，你可能会想到，在计算机领域，所有的问题都可以通过增加一个中间层来解决。那么，我们为什么不使用一个服务注册中心来进行统一管理呢，这样调用方只需要到服务注册中心去查找相应的地址即可，并不关心有多少个服务提供方，从而实现了服务调用方与服务提供方的解耦：

Dubbo 在引入服务注册中心的基础上，又加入了监控中心组件（用来监控服务的调用情况，以方便进行服务治理），实现了一个 RPC 框架。如下图所示，Dubbo 的架构主要包括 4 部分：

• 服务提供方。服务提供方会向服务注册中心注册自己提供的服务。
• 服务注册中心。服务注册与发现中心，负责存储和管理服务提供方注册的服务信息和服务调用方订阅的服务类型等。
• 服务调用方。根据服务注册中心返回的服务所在的地址列表，通过远程调用访问远程服务。
• 监控中心。统计服务的调用次数和调用时间等信息的监控中心，以方便进行服务管理或服务失败分析等。
  下面是Dubbo官网给出的一个调用方的Demo。首先是对需要调用的服务在服务注册中心的地址进行配置：

<?xml version="1.0" encoding="UTF-8"?>
<beans