前言

分布式系统，或者叫做微服务（其实微服务就是分布式系统理论的一种实现，由不同厂商进行技术实现落地，比如说大名鼎鼎的springcloud，本文就是基于springcloud进行讨论），之间通信，其实都是基于http协议的在网络应用层之间的通信，就是我们经常说的调接口。既然基于http协议，那么调用接口方和提供服务方都得实现基于http协议的相关功能（比如说客户端的httpclient和服务提供端的servlet），如果这些都由开发人员实现（其实在很久以前，这些真的是由开发程序员实现的，比如说在很久远的代码里，可以看到不同实现的httpclient和许多的servlet，笔者就曾经写过），那么必会造成多余的开发工作量，因为我们除了写业务代码外，还需要“造轮子”。

但是现在，这些工作都由开源框架提供实现，也可以说现在的框架越来越完善，而程序员越来越懒，越来越容易。但话又说回来，复杂功能全的框架虽然带来便利性，但如果不知道其中的原理，用起来遇到问题，是解决不了的，还是需要阅读源码，这也是为什么bat大厂要求面试者有阅读spring等开源框架源码的能力（源码是最好的文档）。

哎呀，扯远了，微服务系统间的调用，可以按照不同的标准进行分类，但本文只按照实时和异步进行分类，即

实时调用：一次http请求，有请求报文和返回报文，并设置有超时时间，在设置的超时时间之内实现请求和返回的通信

异步调用：通过消息中间件进行消息缓存，请求方无法实时得到返回消息

无论是实时调用，还是异步调用，都是系统间通信的方式，或者统称为rpc（Remote Procedure Call）调用（有人说异步调用不属于rpc调用，其实这是不对的，因为很多消息中间件提供了rpc调用的实现，比如说rabbitMQ）rpc调用直译过来是远程过程调用，就是像调用本地方法一样调用远程系统提供的服务。springcloud提供了一系列的组件来实现微服务间的rpc调用，比如说ribbon，feign等。异步调用虽然也可以用消息中间件提供的rpc组件实现rpc，但我们不推荐这样，所以，如果基于这个原则，也可以说，rpc调用就是系统间实时的接口调用。那么，下文的rpc调用指的就是实时接口调用。

RPC实时接口调用

实现rpc理论的开源或非开源厂商有很多，如阿帕奇的axix和cxf，他们都是基于http+xml进行系统间通信。在springcloud技术体系下，我们使用的是客户端负载均衡组件ribbon，声明式WebService客户端feign。ribbon主要的工作是客户端负载均衡，与服务端负载均衡（如nginx）不同的是，负载均衡策略是由客户端决定的，eureka只是一个注册中心；feign实现了rpc调用中的是像调用本地方法一样调用远程系统提供的服务，即面向服务的架构，我们掉的不是http接口，而是“本地”方法。

那么，实时调用在微服务中的应用大多是查询调用。因为系统间接口调用，无非就是增删改查，即http的那几个get，post，put，delete方法。增删改，我们称之为写调用，查称之为查询调用。查询调用讲究的是实时性，因为不涉及到数据库事务或者系统级事务（指的是分布式事务），响应时间应该比较短，可以实时返回（有很多查询接口调用，逻辑很复杂，比如需要从多个数据源进行取数，然后在进行大量数据加工，对于这种情况属于特殊情况，需特殊对待）。这种实时调用接口处理起来是最简单的。

异步调用

大多数的写调用都是用异步调用实现的。因为写操作是业务系统开发遇到的最难处理的问题。众多难点中的最大的难点就是分布式事务，CAP的三选二理论（Eureka是AP的）。异步调用可以实现柔性事务，即我们保证最终一致性就可以了，即CAP中的C，我们不保证，但在业务层面，最终是C的，就可以了，反正业务也能容忍。除非这个业务链条必须保证C，那么就要想一想，在设计的时候，拆成微服务是否合适。

异步调用，我们也可以不用消息中间件进行实现，用一种叫做“通知”接口的rpc调用，“通知”下游系统，下游系统在接受到“通知”后，只做轻量级的入库操作，然后立刻返回收到“通知”的返回报文，那么上游系统再开启一个定时任务进行轮询，查看该业务链条的实时状态。其实这个“通知”接口就是替代了一部分的消息中间件的功能：解耦。所以我们不推荐，这种方式是自己造轮子，而且还造了个功能不全的轮子，属于出力不讨好。

我再在实际业务场景中，使用这种通知接口就遇到过问题，当时是系统压力过大，导致连通知接口都超时了，上游系统认为下游系统有问题，就重新发起通知，结果业务出现重复。大家也可能会说，出现重复是因为你的通知接口没有实现幂等，的确，这是个问题，但在系统压力过大的时候，下游系统为什么还要响应上游系统的通知请求？

上一个案例的问题消息中间件就能提供解决方案，流量削峰。下面我们总结一下消息中间件对分布式系统带来的特点

解耦

耦合与内聚是我们设计系统中常常面对的问题，我们将设计系统时要降低耦合，提高内聚。这是个很大的话题，我们仅讨论消息中间件带来的系统间通信解耦，那么系统间通信耦合大概有这些：

时间耦合：客户端和服务端必须同时上线才能工作。发消息时，接受消息队列必须运行，但后台处理程序暂时不工作也不影响。

容量耦合：客户端和服务端的处理容量必须匹配。发消息时，如果后台处理能力不足也不要紧，消息队列会起到缓冲的作用。

发送方式耦合：RPC是点对点方式，需要知道对方是谁，它的好处是能够传回返回值。消息既可以点对点，也可以用广播的方式，这样减少了耦合，但也使返回值比较困难。

对于时间耦合我们将实时请求和返回，变成发送消息后等待。对于实时接口返回，可能这种等待会令人不安，因为这时会出现业务状态为未明状态，即不知道到底发生了什么。但这正是分布式系统在AP下带来的问题，因为在AP下我们允许事务的不一致性，也就是说，这种未明状态在业务逻辑上是可以容忍的，在设计业务系统的时候要考虑到。但我们也不能死等下游系统的返回消息（说不定该请求消息不翼而飞了，因为消息中间件是有丢消息的可能的），这时就需要一个定时任务出马了，定时任务按照超时时间差发起查询，根据实时查询的结果进行处理该条业务。但如果超过了约定的最终超时时间（下游系统即没给返回消息，查询接口也没查到），那么可以考虑再发起一个新的请求消息（这时必须保证幂等），或者人工介入。

那么容量耦合就很好理解了，这个就是上面提到的生产问题的解决方案。消息队列，可以让消息发送方和消息接收方都变为主动，上游系统自己决定是否发送消息，下游系统决定是否消费消息（我不消费，就让他堵在mq里呗，但时间不能过长，要不然mq也撑不住）下游系统可以根据自己系统的负载情况，决定开多少个消费线程，甚至是停掉消费监听。

发送方式耦合，rpc调用，ribbon选择一个它从eureka上拿到的点，进行http请求，实时返回。所以说要知道对方是谁，它是否在线，还要处理实时返回后的处理等。但引入消息异步后，只需要定义消息格式，routingKey即可，发了就不管了，谁要消费谁新建队列挂上去就行。即原来发送方式需要脸对脸，现在不需要了。但是得不到实时的返回值。

柔性事务支持

待完善。。。。