微信搜 「yes的练级攻略」干货满满，否则来掐我，回复【123】一份20W字的算法刷题笔记等你来领。 我的文章汇总：https://github.com/yessimida/yes 欢迎 star !java
Hola，我是 yes。git
应读者要求，就下来会更新 Dubbo 相关的文章，还有位同窗想在春招以前看到，安排！github
这里要为官网辩护一下，其实官网仍是挺详细的哈，就是最近 UI 改了看着有点不太爽。算法
好了回到今天的文章，在了解 Dubbo 以前有必要先来剖析一波 RPC ，先搞清 RPC 原理再去深刻了解 Dubbo 会起到事半功倍的效果。编程
理解核心原理很重要，市面上全部 RPC 框架都逃不过这些核心。后端
搞清原理以后再看 Dubbo 就会有我说的那个熟悉感和“承认感”。微信
其实 RPC 不只仅用在咱们平日微服务的调用中，在不少和网络通讯相关的场景都能用到 RPC。网络
好比消息队列客户端和 Broker 之间的交互，还有和一些其余中间件的交互都会用到 RPC。并发
你可能会说没啊？哪有 RPC 调用？负载均衡
嘿嘿，你看这就是 RPC 的做用，让你无感知地完成了远程通讯。
其实在这篇我被喷的上“热门”的文章中已经提过一次 RPC，也提到了 HTTP 和 RPC 的区别，不过那次的主角是 HTTP 。
此次我们深刻剖析一波 RPC，从根上来理解一波。
来，上车！
正文
RPC 全称是 Remote Procedure Call ，即远程过程调用，其对应的是咱们的本地调用。
远程其实指的就是须要网络通讯，能够理解为调用远程机器上的方法。
那可能有人说：我用 HTTP 调用不就是远程调用了，那不也叫 RPC 了？
不是的，RPC 的目的是：让咱们调用远程方法像调用本地方法同样无差异。
来看下代码就很清晰，好比原本没有拆分服务都是本地调用的时候方法是这样写的：
public String getSth(String str) { return yesService.get(str); }
若是 yesSerivce 被拆分出去，此时须要远程调用了，若是用 HTTP 方式，可能就是：
public String getSth(String str) { RequestParam param = new RequestParam(); ...... return HttpClient.get(url, param,.....); }
此时须要关心远程服务的地址，还须要组装请求等等，而若是采用 RPC 调用那就是：
public String getSth(String str) { // 看起来和以前调用没差？哈哈没唬你， // 具体的实现已经搬到另外一个服务上了，这里只有接口。 // 看完下面就知道了。 return yesService.get(str); }
因此说 RPC 其实就是用来屏蔽远程调用网络相关的细节，使得远程调用和本地调用使用一致，让开发的效率更高。
在了解了 RPC 的做用以后，咱们来看看 RPC 调用须要经历哪些步骤。
RPC 调用基本流程
按上面的例子来讲，yesService 服务实现被移到了远程服务上，本地没有具体的实现只有一个接口。
那这时候咱们须要调用 yesService.get(str) ，该怎么办呢？
咱们所要作的就是把传入的参数和调用的接口全限定名经过网络通讯告知到远程服务那里。
而后远程服务接收到参数和接口全限定名就能选中具体的实现并进行调用。
业务处理完以后再经过网络返回结果，这就搞定了！
上面的操做这些就是由yesService.get(str) 触发的。
不过咱们知道 yesService 就是一个接口，没有实现的，因此这些操做是怎么来的？
是经过动态代理来的。
RPC 会给接口生成一个代理类，因此咱们调用这个接口实际调用的是动态生成的代理类，由代理类来触发远程调用，这样咱们调用远程接口就无感知了。
动态代理想必你们都比较熟悉，最多见的就是 Spring 的 AOP 了，涉及的有 JDK 动态代理和 cglib。
在 Dubbo 中用的是 Javassist，至于为何用这个其实梁飞大佬已经写了博客说明了。
他当时对比了 JDK 自带的、ASM、CGLIB(基于ASM包装)、Javassist。
通过测试最终选用了 Javassist。
梁飞：最终决定使用JAVAASSIST的字节码生成代理方式。虽然ASM稍快，但并无快一个数量级，而JAVAASSIST的字节码生成方式比ASM方便，JAVAASSIST只需用字符串拼接出Java源码，即可生成相应字节码，而ASM须要手工写字节码。
能够看到选择一个框架的时候性能是一方面，易用性也很关键。
说回 RPC 。
如今咱们知道动态代理屏蔽了 RPC 调用的细节，使得用户无感知的调用远程服务，那调用的细节有哪些呢？
序列化
像咱们的请求参数都是对象，有时候是定义的 DTO ，有时候是 Map ，这些对象是没法直接在网络中传输的。
你能够理解为对象是“立体”的，而网络传输的数据是“扁平”的，最终须要转化成“扁平”的二进制数据在网络中传输。
你想一想，各对象分配在内存不一样位置，各类引用，这看起来是否是有种立体的感受？
最终都是要变成一段01组成的数字传输给对方，这种就01组成的数字看起来是否是很“扁平”？
把对象转化成二进制数据的过程称为序列化，把二进制数据转化成对象的过程称为反序列化。
固然如何选择序列化格式也很重要。
好比采用二进制的序列化格式数据更加紧凑，采用 JSON 等文本型序列化格式可读性更佳，排查问题比较方便。
还有不少序列化选择，通常须要综合考虑通用性、性能、可读性和兼容性。
具体本文就不分析了，以后再专门写一篇分析各类序列化协议的。
RPC 协议
刚才也提到了只有二进制数据才能在网络中传输，那一堆二进制在底层看来是连起来的，它可不会管你哪些数据是哪一个请求的。
但接收方得知道呀，否则就不能顺利的把二进制数据还原成对应的一个个请求了。
因而就须要定义一个协议，来约定一些规范，制定一些边界使得二进制数据能够被还原。
好比下面一串数字按照不一样位数来识别获得的结果是不一样的。
因此协议其实就定义了到底如何构造和解析这些二进制数据。
咱们的参数确定比上面的复杂，由于参数值长度是不定的，并且协议经常伴随着升级而扩展，毕竟有时候须要加一些新特性，那么协议就得变了。
通常 RPC 协议都是采用协议头+协议体的方式。
协议头放一些元数据，包括：魔法位、协议的版本、消息的类型、序列化方式、总体长度、头长度、扩展位等。
协议体就是放请求的数据了。
经过魔法位能够得知这是否是我们约定的协议，好比魔法位固定叫 233 ，一看咱们就知道这是 233 协议。
而后协议的版本是为了以后协议的升级。
从总体长度和头长度咱们就能知道这个请求到底有多少位，前面多少位是头，剩下的都是协议体，这样就能识别出来，扩展位就是留着往后扩展备用。
贴一下 Dubbo 协议：
能够看到有 Magic 位，请求 ID， 数据长度等等。
网络传输
组装好数据就等着发送了，这时候就涉及网络传输了。
网络通讯那就离不开网络 IO 模型了。
网络 IO 分为这四种模型，具体之后单独写文章分析，这篇就不展开了。
通常而言咱们用的都是 IO 多路复用，由于大部分 RPC 调用场景都是高并发调用，IO 复用能够利用较少的线程 hold 住不少请求。
通常 RPC 框架会使用已经造好的轮子来做为底层通讯框架。
例如 Java 语言的都会用 Netty ，人家已经封装的很好了，也作了不少优化，拿来即用，便捷高效。
小结
RPC 通讯的基础流程已经讲完了，看下图：
响应返回就没画了，反正就是倒着来。
我再用一段话来总结一下：
服务调用方，面向接口编程，利用动态代理屏蔽底层调用细节将请求参数、接口等数据组合起来并经过序列化转化为二进制数据，再经过 RPC 协议的封装利用网络传输到服务提供方。
服务提供方根据约定的协议解析出请求数据，而后反序列化获得参数，找到具体调用的接口，而后执行具体实现，再返回结果。
这里面还有不少细节。
好比请求都是异步的，因此每一个请求会有惟一 ID，返回结果会带上对应的 ID， 这样调用方就能经过 ID 找到对应的请求塞入相应的结果。
有人会问为何要异步，那是为了提升吞吐。
固然还有不少细节，会在以后剖析 Dubbo 的时候提到，结合实际中间件体会才会更深。
真正工业级别的 RPC
以上提到的只是 RPC 的基础流程，这对于工业级别的使用是远远不够的。
生产环境中的服务提供者都是集群部署的，因此有多个提供者，并且还会随着大促等流量状况动态增减机器。
所以须要注册中心，做为服务的发现。
调用者能够经过注册中心得知服务提供者们的 IP 地址等元信息，进行调用。
调用者也能经过注册中心得知服务提供者下线。
还须要有路由分组策略，调用者根据下发的路由信息选择对应的服务提供者，能实现分组调用、灰度发布、流量隔离等功能。
还须要有负载均衡策略，通常通过路由过滤以后仍是有多个服务提供者能够选择，经过负载均衡策略来达到流量均衡。
固然还须要有异常重试，毕竟网络是不稳定的，并且有时候某个服务提供者也可能出点问题，因此一次调用出错进行重试，较少业务的损耗。
还须要限流熔断，限流是由于服务提供者不知道会接入多少调用者，也不清楚每一个调用者的调用量，因此须要衡量一下自身服务的承受值来进行限流，防止服务崩溃。
而熔断是为了防止下游服务故障致使自身服务调用超时阻塞堆积而崩溃，特别是调用链很长的那种，影响很大。
好比A=>B=>C=>D=>E，而后 E 出了故障，你看ABCD四个服务就傻等着，慢慢的资源就占满了就崩了，全崩。
大体就是以上提到的几点，不过还能细化，好比负载均衡的各类策略、限流究竟是限制总流量仍是根据每一个调用者指定限流量，仍是上自适应限流等等。
这个在以后分析 Dubbo 的时候都会提到，等着哈。
最后
我以前面过一个同窗，两年经验，简历写着熟悉 Spring Cloud Alibaba 而后了解 Dubbo 。
我问他 RPC 的调用原理，他问我什么是 RPC，没听过这个名词。
这就太浮在表面了。
理解原理仍是很重要的，像我上面提到的动态代理也不是必定是要的，像 C++ 就没有动态代理， gRPC 框架用的是代码生成。
反正最终只要能屏蔽调用细节，不须要使用者关心便可，至于用什么方式达到这个目的，影响不大。
还有上面提到面向接口，其实有时候就是没接口，例如一些服务网关，暴露出 HTTP 调用的方式给调用者来调用后端 RPC 服务。
网关是要接入不少后端服务的，因此不可能依赖后端的接口，否则就不灵活了。
这里就有个泛化调用的概念。
其实只要你理解了请求方无非就是告知服务提供方我要调哪一个方法，参数都是哪些，你就能很容易的理解什么叫泛化调用。
也就能理解其实不须要接口咱们也能进行 RPC 调用。
具体泛化调用是什么以后写 Dubbo 会提到。
因此听起来好像很高级的玩意，若是你理解了本质，其实也就这么点东西。
万变不离其宗。
欢迎关注个人公众号【yes的练级攻略】，更多硬核文章等你来读。
更多文章可看个人文章汇总：https://github.com/yessimida/yes 欢迎 star !
我是 yes，从一点点到亿点点，欢迎在看、转发、留言，咱们下篇见。
本文分享自微信公众号 - yes的练级攻略（yes_java）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。