企业神奇中间件-RPC No.96

在企业的业务发展到一定程度的时候，企业内部的系统总会进行这样或者那样的系统切分。那么这会导致一个什么问题呢？原来直接通过直接本地调用方式的功能，已经无法正常工作了，因为物理上或者逻辑上已经隔离了。切分应用分别部署一般来说有四种方式。

1、同一主机不同端口。

2、同一主机跨虚拟机或者跨 Docker 容器。

3、跨主机同一内网

4、跨主机跨网络。

这就使得不论是从逻辑还是从物理上隔离，都使得远程调用尤为重要。现在最常用的就四大类。

1、SpringCloud系列，以 RESTful API 为首的 HTTP 类交互。

2、消息队列系列。

3、WebSocket系列。

4、RPC系列，远程过程调用。

各自都有什么特点呢？

SpringCloud 系列，基本都是基于 HTTP 协议来进行传输的， RESTful 风格的开发方式，接口层面可以做到兼容所有开发语言，这对于开发语言非常多样化的项目来说还是比较合适的。

消息队列系列，可以做到系统间解耦，以及进行各种削峰等操作。缺点就是消息队列一般是无法实时响应的，需要自己实现一套系统交互机制。

WebSocket系列。一般来说会用于浏览器和服务端的交互中，全双工模式以及持久化链接的设计，可以方便地替代消息队列交互中的轮询机制。当然WebSocket 系列也可以作用于服务间，用来实现双向推送。

RPC系列。一般来说，RPC不像HTTP一直要三次握手，RPC框架一般都伴随着长连接。RPC并不是一个单点的技术，而是一类技术，目前比较有名的有 JMI、gRPC、Thrift、Dubbo、Motan（微博版Dubbo）、HSF、Hetty 、rpcx等等。

我们后面的专栏主题系列最主要就是针对 RPC 的设计及原理，以及各种 RPC 的入门，最后会给出各种 RPC 的比较以及建议，可以赏个一毛钱给大蕉表达你想看这个系列的意向吗？

RPC是长什么样子的？

RPC（Remote Procedure Call），远程过程调用，从最简单最抽象的模式来看，就是下面这个图这样。客户端调用某个方法，然后中间经过一系列的过程，调用到服务端的某个方法。服务端进行处理之后，做出相应，然后逐层原路返回到客户端。

是不是很简单，一般来说，开发者只需要关注蓝色（ functions ）部分，而至于红色部分（ stub句柄 ） 和黄色部分（socket 网络）部分呢，框架层面会把它解决掉。蓝色部分，服务端开发者要做的事情就是定义某个接口，客户端开发者要做的事情就是调用某个接口，一切开发模式都跟本地调用无差别。

燃鹅，因为框架做得那么好了，所以出现了很多像我这样只会定义RPC和调用RPC的人工智能开发工程师（嗯，人工写代码是挺智能的，人工智能怎么能少了人工呢），希望能通过这个系列，解除你的疑惑，如果能有点帮助那就更好了。今天不讲太多 RPC 技术性细节性的东西，亲爱的朋友们，你们希望看到些什么内容留言告诉我吧。

敬请期待。。。