BazingaLyncc

本来只是想写一写，学一学的，不过觉得还是应该跟大家一起分享一下一个完整的在我知识体系中相对健全的RPC框架写这个RPC的时候，我是写过一个的RPC的，其实不能称之为写，算抄吧，看过别人写的RPC,也无脑的抄了一遍别人的代码，抄完之后，问了冯大神，感觉收获很多，比每天看书看帖收获多得多所以想重新写一个，写的时候向记录一下写的大体流程，与大家做一个分享，共同进步，其实这次应该还

上两节我们简单地说明了注册中心的功能和基本结构，本节重点讲述注册中心如何处理服务提供者发送过来的信息因为我们之前讲过Netty网络端的定义说明的，也讲了服务提供者发布服务的知识了，我们看看默认的注册中心的处理器是如何处理发布的信息的private void registerProcessor() { this.remotingServer.registerDefaultProc

上个小节简单的描述了一下注册中心如何处理与服务提供者的交互问题，也列举了几个简单的代码片段，中间有几个场景是需要通知服务消费者的几个业务逻辑的1）当服务消费者服务发布成功且审核通过的情况下

介绍注册中心的功能的小节，我们曾经说过，注册中心要有持久化的操作，将一些服务的审核信息放到硬盘上，这样做的原因就是因为我们所有的服务信息都是放在内存里面的，如果注册中心的实例宕掉，或者服务器因为某种原因停止的时候，这样某些服务的审核记录就无法找回，为了避免这样的问题，我们需要做的事情就是把这些服务审核信息定时刷盘，把这些信息保存到硬盘上去，然后每个注册中心服务启动的时候，去硬盘上去恢复这些信息，这

服务消费者也就是我们最最核心的主角，它是整个RPC中的主角，一切都是为它服务的

订阅服务看起来是比较简单容易实现的功能，乍一看，就是发送订阅服务的名称给注册中心，然后注册中心反馈给服务消费者，感觉万事大吉，其实并不是这样的，这块是比较容易实现的，使用Netty很容易就能实现了，但是写的时候就会发现各种问题

所谓负载策略，其实相对比较简单，某个消费者去远程调用某个服务，不过提供这个服务不止一个实例，那么建立的长连接就不止一个，所以需要做的事情就是根据某个策略在这个长连接中选择一个进行通讯本Demo RPC只实现了三个比较常用的负载策略1）随机2）加权随机3）轮询下面给出实现：package org.laopopo.client.loadbalance;imp

对于远程调用来说，最高境界就是让使用者不知道此处代码是远程调用一样，感觉就是调用本地的某个普通方法，封装底层调用的细节，这是我们服务消费端最后要做的事情比如，消费者需要调用此接口的方法package org.laopopo.example.generic.test_2;import org.laopopo.client.annotation.RPConsumer;publi

本来想多写点文字的，不过发现自己的表达能力的确有限，现在还是理解为啥大神都是贴代码，不做解释了，的确很难说明一切，大神的代码易懂，看到代码就基本上知道啥意思了，这就是所谓的妙笔生花吧，我不能，所以多写一点文字多加一点注释，这也是没有办法的事情RPC基本的代码上述22个小节所总结的，代码陆陆续续写了一个月，不过博客却是因为各种事情耽误了2个月，进度很慢，行百里者半九十，估计就是这个道理吧

进入了基本的测试篇，首先我们先进入基本的代码测试，我们先跑通代码：首先我们先写两个简单的接口：HelloService.javapackage org.laopopo.example.demo.service;/** * * @author BazingaLyn * @description * @time * @modifytime */publ

因为在某些场合下，服务提供者和服务消费者是直接可以调用的，不需要通过注册中心，本小节测试直连的调用：服务提供者的代码：package org.laopopo.example.generic.test_4;import org.laopopo.client.provider.DefaultProvider;import org.laopopo.common.exception.

本小节测试一下限流的功能，首先我们先定义一个简单的类，配置一下它单位时间最大的调用次数package org.laopopo.example.generic.test_5;import org.laopopo.client.annotation.RPCService;import org.laopopo.example.demo.service.HelloSerivce;public

性能测试的代码我也写了https://github.com/BazingaLyn/laopopo-rpc/tree/master/laopopo-example/src/main/java/org/laopopo/example/benchmark单机测试结果（Server/Client）放在同一台机器上（条件所限制）结果也写在代码的头部了，就不一一演示了，有热情的同学可以帮忙

注册中心的实现方式有很多种，实现的方式也有难有易，可以使用zookeeper，consul这些第三方已有的包去帮助实现，这样可以减少开发注册中心的难度，却可能加大运维的难度，当然最最原始的方法就是使用java去实现，不借助其他任何已有的第三方包去搞定，这样做的好处其实并不明显，不过对于开发者而言，使用这种最原始的方式最大的好处就是自己知道所有的实现细节，遇到问题，遇到bug，可以很快的定位到问题所

注册中心在RPC整个体系中担任的角色是比较重要的，但也是比较微妙的，它维护了所有服务提供者的所暴露服务的信息,最最核心的信息就是IP+端口号，服务消费者会在调用服务的时候去注册中心上去询问它远程调用服务的端口和IP地址，其实最最简单的注册中心的职责就是如此，注册中心的最核心的职责就是如此但是，其实在RPC的体系中，注册中心其实是可以缺失的，因为假如服务消费者知道服务提供者的地址，就可以

对于RPC而言，服务的降级也是必不可少的，何为服务的降级，就是在业务洪流来的时候，服务器的压力陡增，数据库的压力也很大的时候，轻量化服务的功效，比如某个非核心服务需要调用数据库的，我们降级的服务不需要调用数据库，就比如我们在某某电商购物的时候，商品详情页的侧边栏一般会有电商推荐的一些比较类似的产品，这个后台的机制可能是某个推荐算法，根据用户浏览商品的记录给出推荐的产品，这是非核心的逻辑，这个功能在

RPC 技术出来很多年了，出来的时候我估计还刚刚上大学，dubbo应该算是先驱者吧,下面的图更是经典中的经典RPC在我的认知体系中，其实最后简而言之，就是调用端，也可以称之为消费者（Consumer）获取到提供者的网络地址，并吧入参通过网络传递给Provider端，提供者端获取到参数，调用己方的方法，把结果再通过网络回传给消费者端整个流程代码实现，可以参考dubbo作者

现在N多网络通讯框架应该选用的都是Netty，基于多种原因吧：1）它很容易上手，它封装了网络传输底层的实现，但也有spring的开闭原则，可以根据用户的参数配置去定制属于自己的网络传输模型2）它优化了线程模型，且基于事件驱动，基于NIO，提高IO效率3）内存优化，直接内存的使用/池化的技术4）第四点，我也是认为很重要的一点，也是我们写这个RPC框架的核心点，就是有很多参考，基于ne

Maven的多模块项目搭建还是比较方便的，结构清晰，模块依赖明确，很适合用来作为开发RPC的开发架构，我们开发的RPC起一个名字，因为大学一直酷爱魔兽，喜欢魔兽解说xiaoy，他有一个别名叫做laopopo，所以我就没多想，就起了一个名字叫做laopopo-rpc，名字蹩脚了一点，不过不重要，明朝开国皇帝朱元璋真名叫朱重八，老爸叫做朱五四，他依旧做了皇帝，所以英雄不问姓名~（项目截

上一节，我们说到写一个RPC，很核心的一个模块也是基础就是网络通讯部分，定义一个通用的网络传输对象，会方便我们的对业务层面的编码，我们会花费很少的心思在底层的字节流的网络传输上。  因为我们选用的是Netty，写过Netty的或者有一点Netty基础的，都知道我们需要C/S端写一个编码器和译码器，因为我们知道不管你传输对象定义的有多好，有多么的通用，在网络上传输的全部都是正常人看不懂的字节，而

说到序列化，这在RPC的层面上也是很重要的一个环节，因为在我们的业务层面，你传输的一个对象，是一个Object，不过在网络上，却不管你传输的是Obj1，还是Obj2，网络只认byte，所以在代码层面上，如何将对象转化成byte数组，和如何将byte数组反序列化层对象，这也是很重要的，直接影响你的整个框架的性能java原生态的java.io.Serializable就对序列化提供了支持，

大家知道网络通信都是异步的，当你使用网络去发送一个请求的之后，就会去等待这个请求对应的响应体，可是你却不知道这个响应到底何时到达。 这就是异步的好处也是异步的坏处，好处就是在请求发送出去之后，你就可以去做其他的事，就比如你跟你的女神用微信表白了，表白之后，你不需要眼睛直勾勾的盯着手机微信，可以去干一些其他的事情，坏处就是你不知道响应到底什么到来，所以即使你去做其他的事情也会不舒心，你会时不时的

本节是本RPC网络传输的最后一个小节，讲解了Netty的部分，我之前已经讲过很多Netty的运用的基本知识了，也写过相关的博客讲述过这个模块，这边就不再赘述了Netty的模块，主要就是一些TCP的参数设置，handlers链的设置，编码器和译码器的编写，关于RPC的编码器和译码器，我们之前就讲述过了，也不多说，请求响应，我们之前也详细描述过还有一些Netty的零碎小知识（姿

关于RPC的网络模块其实还有很多地方可以挖掘，还有很多细节可以去深究，还有很多配置去优化，写代码，对待人生，玩游戏都是这样 写代码，人家的代码，总是人家的代码，跟别人家的孩子一样，性能是那么的卓越，bug总是那么少，你跟别人总是差一点，就差一点，这一点点就成了鸿沟了 人生也是一样，差一点点就成功了，差一点点就追到女神了，这一点点也就成了鸿沟了 游戏亦是如此，你差一点点就杀了对方的英雄了

本节介绍Provider端代码的搭建，工欲善其事必先利其器，Provider端的代码结构很重要，写代码的时候，我们需要知道我们自己要干嘛，好了，废话不多说，先写一个接口，接口是明确自己要干什么的利器，写个接口压压惊~Provider.javapackage org.laopopo.client.provider;import io.netty.channel.Channel;imp

首先先进行服务的编织，将一个服务的一些基本信息编织成一个类，发送给注册中心，订阅者在注册中心取到的编织信息就可以调用该方法，这是整体的思路，我们在网络篇说过，所有的数据传输走RemotingTransporter，核心的传输主体要实现CommonCustomBody接口，接下来，我们就定义Provider发送给注册的类：编织的服务信息基本信息应该有1）服务的IP地址2）端口号

上一个小节简单的介绍了服务提供者端如何去编制一个服务的信息，然后将此服务的信息发送到注册中心上去的基本过程了，其实算是比较简单的，这节我们将简单的

对于远程调用来说，限流是很重要的，这是对自己的保护政策，因为为了保证在业务高峰期，线上系统也能保证一定的弹性和稳定性，最有效的方案就是进行服务降级了，而限流就是降级系统最常采用的方案之一限流即流量限制，或者高大上一点，叫做流量整形，限流的目的是在遇到流量高峰期或者流量突增（流量尖刺）时，把流量速率限制在系统所能接受的合理范围之内，不至于让系统被高流量击垮。目前有几种常见

sigh，很遗憾，没有写完整，还有很多想做而没有做的事情，总结一下想做而没有做的事情吧1）性能测试，没有条件和环境给我做这个事情2）对portal，对页面的支持，没有一个可以直观的可视页面3）注册中心对zookeeper的支持4）监控中心链路调用的追踪的支持，这个很重要，不过没有做当然这是一个比较简单的RPC DEMO,一个学习的工具，希望对大家有提升就可以了，