前言
RPC 全程近程办法调用，曾经在各大小公司被宽泛应用，品种也是很多比方：Dubbo，Spring cloud 那一套，GRPC，Thrift，可能还有很多公司自研的等等；每个公司都可能依据本人的业务需要，场景抉择本人适合的 RPC 框架；但大体的考查维度无非就这么几个：性能，可扩展性，跨平台，功能性，可监控，应用性；所以咱们如果要设计一个 RPC 框架，能够从这几个角度去思考。
性能
作为微服务中的外围组件，在一个零碎中 RPC 的调用量往往是很高的，所以性能是一个很重要的思考点；既然是近程调用，必然牵扯到网络连接，而 I / O 模型的抉择间接影响到性能，网络的长连贯短连贯，序列化形式也都影响性能；
1.I/ O 模型
常见的 Unix5 种 I / O 模型别离是：阻塞 I /O，非阻塞 I /O，I/ O 复用 (select,poll,epoll 等反对 I / O 多路复用)，信号驱动 I /O，异步 I /O；从晚期的阻塞 I / O 形式只能创立大量的线程来保障每个用户互不影响，到当初宽泛应用的 I / O 多路复用模型，再到异步 I /O；从 select 模型到当初支流的 epoll 模型，性能有了质的降级；当然咱们没必要本人去实现，能够间接应用网络通讯框架 Netty，Mina 等；
2. 长连贯短连贯
短连贯示意每次通信完就敞开连贯，而长连贯通信完持续放弃连贯，这样下次再通信就不须要从新建设连贯了，如果通信频繁，很显著长连贯性能更高；然而长连贯须要做一些额定的工作，比方保活解决；另外就是如果客户端太多的话，服务器端是无奈撑持的。
3. 序列化形式
网络传输中的数据都须要通过序列化和反序列化解决，所以这一块的性能也很重要；常见的序列化包含：json 和二进制形式，json 常见的如 fastjson，jackson 等，二进制如 protobuf，thrift，kryo 等；这个能够别离从序列化的性能，大小，以及应用方便性思考；当然稳定性和安全性也须要思考，比方 fastjson 频繁爆出安全漏洞；
4. 协定
这里次要讲的是应用层协定，RPC 个别都会自定义协定，当然也有间接应用现有协定的比方 http 协定；自定义协定能够本人掌控，协定能够做的很小很精简，当然解码和编码须要本人去实现；如果应用现有的 http 协定，相对来说整个协定包是比拟大的，然而曾经是一种标准了，很多货色能够间接拿来用，更加通用；
可扩展性
可扩展性能够从两个角度来看，一个是服务提供方和生产方的负载平衡策略；另一个就是用户能够对框架进行自定义扩大；
1. 负载平衡
RPC 的两个外围组件服务提供方和生产方，须要提供横向扩大的机制，用以达到更高的负责，比方 Spring Cloud、Dubbo 提供的注册核心，而后再联合容错机制达到负载平衡的成果，很容易达到横向扩大；
2.SPI 机制
一个好的框架是反对用户自定义的，用户依据本人的需要实现自定义扩大；JDK 提供了 SPI 机制，很常见的一个场景就是数据库驱动；另外 Dubbo 在此基础上提供了更加弱小的 SPI 机制；这种扩大对 RPC 来说是多方面的，能够是底层的通信框架扩大，序列化扩大，注册核心扩大，容错机制扩大，协定扩大等等；
跨平台
当初开发语言多种多样，如果能做成跨平台，当然是一大劣势，然而可能往往为了跨平台，会在一些中央做衡量退让，当然难度也更大；所以咱们在实现一个 RPC 时须要明确本人的定位，就是针对某一种语言的还是跨平台反对；常见的反对跨平台的 RPC 框架如 GRPC，Thrift；
实现机制能够参考一下，都有本人的一套接口定义语言 IDL 而后通过不同的代码生成器，生成各种编程语言生产端和服务器端代码，来保障不同语言间接的相干通信。
功能性
作为一个 RPC 框架，除了最外围的通信模块，序列化模块之外，功能性模块也很重要，往往为开发者节俭了大量的工夫，开发者可能因为 RPC 的某个性能而抉择用此框架；常见的性能包含：容错机制，负载平衡机制，同步异步调用，后果缓存，路由规定，服务降级，多版本，线程模型等；
1. 容错机制
在盘根错节的网络环境中，近程调用失败再失常不过了，容错机制就显得十分有必要了，常见的容错机制比方：失败重试，疾速失败，失败间接疏忽，并行调用多个服务器只有一个胜利即返回等；用户能够依据需要抉择本人适合的容错计划；
2. 负责平衡
下面提到服务提供方和生产方的可扩展性，生产方面对多个提供方的时候须要有肯定的负载平衡策略，来保证系统的稳定性；常见的策略如：随机，轮询，起码沉闷调用数，一致性 hash 等；
3. 同步异步调用
常见的同步调用有些场景无奈满足需要，比方同时须要调用多个近程办法，而这其中可能有些执行比较慢的；这时候异步调用就显得重要了，能够同时异步发送多个申请，等待时间就是响应最慢的申请；具体能够通过 Future，CompletableFuture 来实现；
4. 后果缓存
缓存始终是性能的不二法宝，某些场景下可能对服务提供方响应的数据实时要求性并不高，这时候如果能够在服务提供端提供后果的缓存机制，那么在性能上是一个很大的晋升；能够本人设计一个本地缓存，当然也能够间接整合第三方缓存框架比方 ehcache，jcache 等；
5. 路由规定
服务提供方往往是很多的，用户可能有一些非凡的需要，能够依照本人定义个规定来做路由，比方咱们常常做的灰度公布，联合 RPC 提供的路由规定来实现会很简略；此规定可能是条件表达式，脚本，标签等，咱们设计的 RPC 框架须要有一个给用户定义规定的中央，比方通过注册核心来实时推送，另外还须要相干的引擎来解决规定，比方脚本引擎；
6. 服务降级
零碎的高可用性准则中，很重要的一条就是降级解决，在一些非核心的性能中，能够在呈现超时 / 故障时或者间接设置为降级服务，给一个对立的响应，这样能够把贵重的资源留给那些外围的性能；能够参考 Dubbo 的实现，向注册核心写入动静配置笼罩规定，从而实现实时降级解决；
7. 多版本
接口降级时常有的事件，咱们可能会为了兼容之前的版本搜索枯肠，但有时候还是无能为力，这时候多版本就显得很重要了，能够让两个版本同时存在，等到适合的机会在缓缓降级；像 dubbo 这种服务的维度就是服务名 + 版本号，所以很好实现多版本；而 Spring Cloud 维度没有到版本号，能够通过路由规定去实现；
8. 线程模型
在零碎的高可用准则中，线程隔离是一条重要的准则，为什么要做隔离，能够拿 Dubbo 及其底层通信框架 netty 为例，netty 作为通信框架自身是有本人的线程模型，如果业务解决线程间接应用底层的通信线程模型，这样就会呈现因为业务阻塞而导致通信线程模型阻塞；这时 Dubbo 提供本人的线程模型就尤为重要，能够做到线程隔离，业务线程不影响通信线程；
当然作为一个 RPC 框架实现的性能能够很多，这里次要讲一些咱们平时用的比拟多的性能；
可监控
一个运行稳固的零碎，没有一个专门的监控平台是不行的，当然 RPC 也不例外，常见的比方 dubbo 的 monitor 模块，Spring Cloud Admin 等；对于一个 RPC 咱们次要监控：服务提供者有哪些，服务消费者有哪些，以及它们的状态，最好还有一些统计性能比方一段时间内的调用量，成功率，失败率，均匀响应工夫，最大响应工夫，最大并发量等等；
应用性
最初说一下，咱们设计进去的框架最终还是要给用户应用的，所以用户是否能够不便的应用也是一个很重要的点，某些框架可能就是因为应用繁琐导致最终被弃用；比方注解的形式相比拟 xml 的形式就简略不少；还有比方服务维度来说：dubbo 维度是接口，而 Spring cloud 维度是利用，整体来看 Spring cloud 应用起来更加不便；当然简略的 API，文档以及 Demo 对开发者来说也是必不可少的；
总结
RPC 实质上其实就是一次网络调用，很多设计其实都是在围绕，如何把它变成一个高可用，高并发的框架；其实这些设计实践实用于大部分的零碎，都在为达到此指标而致力。
感激关注
能够关注微信公众号「 回滚吧代码 」，第一工夫浏览，文章继续更新；专一 Java 源码、架构、算法和面试。