一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第23天，点击查看活动详情。
RPC 通信方案
我们首先去看一看早期的微服务通信方案 RPC，它也叫做远程过程调用。也就是说有两台服务器 A 和 B，一个部署在服务器 A 上的应用想要去调用服务器 B 上部署应方法或者是函数，由于它们不在一个内存空间下面，不能够直接调用，需要通过网络来表达调用的语义和传达调用的数据。那么这就是 RPC。
它最终解决的问题是让分布式或者微服务系统中不同服务之间的调用像本地调用一样简单。
RPC 实现微服务通信的核心思想
第一，我们需要有一个全局注册表，将 RPC 支持的所有方法都注册进去。也就是说如果一个微服务它对外提供方法可以被调用，那么就需要把这个方法的信息注册到全局注册表里面。
第二，是通过将 Java 对象进行编码，我们叫做 IDL，其实就是对信息的描述。更简单的理解就是请求对象和响应对象的编码，再将方法名传递到服务器，也就可以实现通信。那么目标服务器通过全局注册表找到对应的方法，并使用请求对象执行，最后返回给目标服务器响应对象。
上面所示的这张图，要注意到 Clint 就是调用方。除了 IDL 和方法之外，Client 还需要知道目标服务器的地址。 那么这在以前没有像 Eureka、 Nacos这样的注册中心之前，我们会将服务器的地址信息保存在 zk，也就是 Zookeeper 里面。使用的时候，由我们的客户端去向 zk 发起请求，去拿到server 的地址，再通过 IDL 向server 去发起请求，最后 server 返回响应给我们的客户端。
RPC 优缺点
大概了解了 RPC 的工作思想之后，我们再去分析一下 RPC 的优缺点。
第一，目前市面上流行的 RPC 框架有 gRPC、Thrift、Dubbo 等等，所以我们有很多选择性，这是是 RPC 方案的优点之一。
第二，由于 RPC 它可以使用 TCP 作为传输协议，所以它的速度快，并发性能很高。
第三，由于 RPC 它并不是完美的，它提供高性能的同时也会增加你的软件开发的复杂度，你需要做更多的编码与维护工作。比如我们需要使用 zk 去存储目标服务器地址信息，以此我们就要去维护 zk。但是你也需要知道，优缺点都是相对的，你完全不需要拘泥于理论，只要你不觉得麻烦难以维护，那么它就是好的实现方案。
HTTP（Rest）通信方案
我们接下来去看第二种通信实验方案，HTTP 通信方案，也就是 Rest 。这种方式对我们程序员来说简直是不能再熟悉了。所以说我简单地对这种方式说明两点。
第一，Rest 它指的就是标准的 HTTP 协议，例如 GET、POST、PUT、DELETE 等等。目前主流的微服务开发框架通信实现都是 HTTP，例如 Spring Cloud。
第二，也正是由于我们熟悉 HTTP，它简单、标准，所以我们需要的工作和维护都会比较少，因为它本身没有什么依赖。另外呢，我们几乎不需要做额外的工作，即可以与其他的微服务集成，这一点很好理解，同时我们也几乎没有学习的成本。
HTTP 由于它比较简单，我们也比较常用的，所以只是简单地去讲解一下它的概念。
Message 通信方案
Message 通信方案通常也把它叫做基于消息驱动的通信实现。
第一，所谓的 Message 其实就是消息，也就是说我们会使用像 Kafka、RocketMQ 等等这样的消息队列来实现消息的发布与订阅，订阅其实就是消费的意思，也就是典型的生产者、消费者模型。我们在一开始学习编码的时候呢会学习到数据结构，数据结构又会牵扯到算法。那么关于这里面就会有生产者和消费者这样的工作模型，它其实就是 Message 的一个前身。
第二，由于消费消息不要求实时性，所以通过消息队列我们可以实现 “削峰填谷” 的效果，也就是以缓冲的机制实现数据任务的处理。
第三，当然消息驱动的通信方案呢也并不是完美的，它也存在缺点。最大的缺点呢就是它只能够做到最终一致性，而做不到实时的一致性，毕竟生产者发送消息到达消费者，消费者再去处理它，这个过程一定会存在延迟，甚至是出现消息的排队。但是你也要知道，如果业务允许，也就是不要求实时的一致性，那么 Message 仍然是可行的通信机制。
那么到这里，我们就把最常见的三种通信方式介绍完毕了。我们可以知道的是它们各自都有优缺点，各自也都是很好的解决方案，那么我应该如何做出选择呢？
微服务通信该如何选择
要去结合你的微服务框架与业务的需要去做出选择。
第一，我们所使用的微服务开发框架是 Spring cloud，它所建议的通信方案是 OpenFeign，是基于 Rest 的去实现的。所以如果你没有特殊的理由，你应该遵从框架的建议，因为这是框架在试验了很多遍，同时也听了很多开发者的意见之后，再去决定的给出的建议，就去直接去使用 OpenFeign。
第二，需要最终一致性，而且不要求快速响应的业务场景，你当然可以去选择使用 Message，这是非常好的业务实现。通过 Message 异步处理可以对系统性能有很大的提升。
第三，问题来了，Spring Cloud可不可以使用 RPOC 去作为实现通信方案呢？当然是可以的，RPC 它只是一种应用方式，不局限于哪个开发框架，但是我们仍然要说明，你一定要有足够强的理由去说明你为什么要去使用 RPC，它的好处是什么，你能够得到收益是什么，否则使用 Rest，也就是使用 OpenFeign 是最好的选择。
微服务通信方案的有哪些方式，那么具体怎么样去做出选择，还是要去结合微服务框架与业务的这个需要。
