前言

为什么需要RPC，而不是简单的HTTP接口？

刚开始还是菜鸟的时候，时常把RPC和HTTP搞混淆，本身概念还没理解清楚，心里就浮躁的不行，导致闹出了不少笑话。

什么是RPC？

RPC（Remote Promote Call） 一种进程间通信方式。允许像调用本地服务一样调用远程服务。

RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式（TCP或者UDP）、序列化方式（XML/JSON/二进制）和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

什么是HTTP？

HTTP协议是应用层的超文本传送协议，它是Web的基础。HTTP协议位于TCP/IP协议栈的应用层。基于HTTP协议的客户/服务器模式的信息交换过程，分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。

OSI网络结构的七层模型

第七层：应用层： 定义了用于在网络中进行通信和数据传输的接口 - 用户程式；提供标准服务，比如虚拟终端、文件以及任务的传输 和处理；
第六层：表示层： 掩盖不同系统间的数据格式的不同性； 指定独立结构的数据传输格式； 数据的编码和解码；加密和解密；压缩和 解压缩
第五层：会话层： 管理用户会话和对话； 控制用户间逻辑连接的建立和挂断；报告上一层发生的错误
第四层：传输层： 管理网络中端到端的信息传送； 通过错误纠正和流控制机制提供可靠且有序的数据包传送； 提供面向无连接的数 据包的传送；
第三层：网络层： 定义网络设备间如何传输数据； 根据唯一的网络设备地址路由数据包；提供流和拥塞控制以防止网络资源的损耗
第二层：数据链路层： 定义操作通信连接的程序； 封装数据包为数据帧； 监测和纠正数据包传输错误
第一层：物理层： 定义通过网络设备发送数据的物理方式； 作为网络媒介和设备间的接口；定义光学、电气以及机械特性。

RPC是一种概念，http也是rpc实现的一种方式。论复杂度，dubbo/hessian用起来是超级简单的。最近用dubbo和hessian比较多，http的几乎都被废弃了。

至于为什么用，其实很简单，业务场景不一样。我最早的单位所有的代码都在一个工程里，一次要发布几百m的代码。这种架构是非常有利于小程序的。但是我们为什么要应用rpc层呢，一个功能，一套代码下来不就解决了么？我觉得有几个好处：

1. 灵活部署
2. 解耦

系统做大了，肯定是需要做微服务的。 现在我们做电商就是这样，单独有一个订单系统，支付系统，商品系统，用户系统。都是分开部署，单独上线的。 但我们交互是用HTTP接口来交互的，我想转用RPC，但问题是我现在还没发现为什么需要用RPC，我还没能理解它的作用和意义。
用http交互其实就已经属于rpc了。

不知道大家看到这里有没有解决掉文章开头的那个问题呢？看似普普通通的一个问题，实际上暗藏了很多玄机，只有从头到尾都完完整整的了解过一遍之后才能真正地得到想要的答案。大部分程序员应该都有在工作过程中碰到各式各样的问题，那是否都深入去追究过问题的本质呢？如果有机会不妨去试一试，你会发现海面下隐藏的“冰山”是表面上的许多倍。

为什么面试官问的都是同样的问题，有的人觉得没什么太多能回答的点，有的人却能滔滔不绝？我想每个人思维的深度面试官一眼就能看出来，正好就印证了那句话：架构是一种思想，技术只是外壳。技术可能淘汰，思想才能长存。

人因为有了思想，才没有成为野兽。
在这里推荐一个架构群895244712，除了分布式、微服务、性能优化等技术点的技术分享，更重要的是架构思想的形成。

这边不再纠结，详细理解一下RPC的相关问题。

广义和狭义的RPC

广义的远程通讯技术包括:RPC , WebService , RMI , JMS , EJB , JNDI .

• CORBA:面向对象的编程体系规范,分布式系统,跨语言,对标RMI(竞争关系)。
• SOAP:简单对象访问协议,微软联合厂商对xml-rpc标准化,soap协议就是联合标准化的结果,而且微软抢先完善了soap协议,推出了webservice。对象访问协议指的是使用XML描述web service的信息(URI/类/参数/返回值),理论上SOAP就是一段xml
• WebService:属于广义rpc的一种(常见的广义rpc实现还有xml-rpc和json-rpc),支持异构系统间的交互, 支持不同语言的通信,使用http通信,通过serlvet提供XML格式的数据,是SOAP协议的封装,WSDL是它的描述方式。
• WSDL:webservice描述语言,描述SOAP协议的,也是段XML
• RMI:远程调用对象,其实是java实现了RPC的一组接口
• JMS:MQ
• EJB:大型分布式,rmi-iiop协议

广义RPC发展历程

狭义RPC技术框架

由于目前跨内存调用的普遍性,RPC往往代称更加具体的基于底层协议二进制流的RPC框架,与WebService最大的不同就是: 狭义的RPC基于二进制流的序列化和反序列化,故不能够提供跨语言的服务,但是比基于文本解析的WebService更加高效。

狭义RPC框架一般需要高性能的网络框架,如Netty,Mina,高性能的序列化反序列化框架,寻址方式,如果是带会话的RPC,还要有会话和状态保持功能。

当下XML-RPC,SOAP,WebService技术的缺陷

• 冗余数据太多,处理速度太慢。
• RPC 风格的 Web Service 跨语言性不佳,而 Document 风格的 Web Service 又太过难用。
• Web Service 没有解决用户的真正问题,只是把一个问题变成了另一个问题。
• Web Service 的规范太过复杂,以至于在 .NET 和 Java 平台以外没有真正好用的实现,甚至没有可用的实现。
• 跨语言跨平台只是 Web Service 的一个口号,虽然很多人迷信这一点,但事实上它并没有真正实现。

RPC框架实现的几个核心技术点：

• 远程提供者需要以某种形式提供服务调用相关的信息，包括但不限于服务接口定义、数据结构、或者中间态的服务定义文件。例如Facebook的 Thrift的IDL文件，Web service的WSDL文件；服务的调用者需要通过一定的图景获取远程服务调用相关的信息。
• 远程代理对象：服务调用者用的服务实际是远程服务的本地代理。说白了就是通过动态代理来实现。
• 通信：RPC框架与具体的协议无关。
• 序列化：毕竟是远程通信，需要将对象转化成二进制流进行传输。不同的RPC框架应用的场景不同，在序列化上也会采取不同的技术

RPC面临的挑战

在大规模服务化之前，应用可能只是通过RPC框架，简单的暴露和引用远程服务，通过配置URL地址进行远程服务调用，路由则通过F5负载均衡器等进行简单的负载均衡。

当服务越来越多的时候，服务的URL配置管理变得更加困难。单纯的使用RPC就有点吃不消。所以在大规模分布式集群中，RPC只是作为集群的一个方法调用手段。例如在Hadoop的进程间交互都是通过RPC来进行的，比如Namenode与Datanode直接，Jobtracker与Tasktracker之间等。

服务化架构的演进

• MVC架构：当业务规模很小时，将所有功能都不熟在同一个进程中，通过双机或者负载均衡器实现负债分流；此时，分离前后台逻辑的MVC架构是关键。

• PRC架构：当垂直应用越来越多，应用之间交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。此时，用于提高业务复用及拆分的RPC框架是关键。

• SOA架构：随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的SOA服务治理是关键。

• 微服务架构：通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降。