前言
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源码、架构、算法和面试。