为什么要手写RPC，不写行不行

1.为什么要手写RPC？

2.为什么要用RPC？

3.RPC是什么？

4.怎么写RPC？

5.我写RPC行不行？需要那些前置知识。

什么是RPC，为什么要用它？

  实际上这个问题是一个扫盲的。为了加深印象我还是说一下。RPC是时代的产物，是特定场景需求下的产物。 

   理解什么是RPC之前，我们先说一下为什么要使用RPC。不得不提的是单体应用到分布式应用的进步。RPC是远程过程调用，在分布式服务场景下，我们期望方便的完成 跨服务之间的调用，我们都知道在单体应用下，我们的调用顶多是通过分层的方法调用。但是在分布式服务场景下，我们在A服务中想要调用B服务中的方法。就是这个需求，完成这个过程就完成了RPC（远程过程调用）。

为什么要手写RPC？写RPC需要哪些前置知识？

  我说下班在家没事干闲的你信吗？（当然不是了，九点半才回来，我也是一边学习一边写这个文章。可能又要干到一点了）

  当然了，手写RPC虽然看起来是重复造轮子的事情，但是帮助我们深入的了解远程过程调用还是很有帮助的。可以帮我们深入的了解RPC的架构。那最后一点呢，也是因为我最近一个月都在看Netty实战这本书，看完了一遍，感觉都忘了，利用netty的知识，手写一个RPC，RPC也明白了，netty用能够更加熟练的掌握，岂不是一箭双雕！

  写一个RPC框架，先要懂RPC模型，也就是整个过程。其实这就是先弄清楚需求。第二个就是netty这项通信框架技术。

常见的RPC框架 -现成的轮子

 dubbo 是阿里开源的 RPC框架。它底层也是通过netty写的，这正是我学习了netty，并写一个RPC框架的真正原因，另外我是为了更好的掌握netty，它是一个性能优化的利器，我有预感，我今后一定会用到他发挥很大的作用。

  彩虹屁！不得不说netty真的的强大，elasticsearch集群节点之前的通信，也用到了netty。

正式开始介绍RPC相关的知识 - RPC模型

  一个简单的RPC模型。就是要解决跨服务之间的调用。请看下边这个简单的模型：

 我先不做过多的介绍，但是开始要啰嗦一下：其实学知识就是要融会贯通，这个怎么说呢，我看到这个RPC的架构图的时候，联想到的网络通信的一张图如下：

 使用举一反三的方式来看待工作中遇到的需求，似乎所有的问题都有一个原型供我们来借鉴。只要我们底层知识扎实。能够融会贯通的去想问题，一切都变得简单起来。实际上RPC就是一个端到端的通信过程，一次网络通信可能是服务器到客户端服务器的通信，而RPC实际上就是一次从一个服务到另外一个服务的通信。

在一个简单版的RPC框架里边都需要哪些内容

1.  服务的提供者
2.  服务消费者
3.  接口约定

 既然要用netty来写 RPC，那如何把netty中的知识对照到RPC中呢？

   实际上服务提供者就是一个启动的服务，而服务的消费者本质上就是一个客户端，这是一个典型的C/S 模型。

coding一个RPC分几步

1.  先约定服务提供者和服务调用者，传输的数据格式。这就像是网络中使用html格式的网页数据用于展示。本身RPC也是一种通信协议。
2. 编写服务端的控制器，这个如果熟悉netty很简单，只需要编写一个handler，并实现ChannelInboundHandler接口即可。
3. 编写服务端的程序引导器，这实际上就是套用一下netty的代码，然后放入一些必须的控制器，这些控制器都是netty实现好的，所以非常简单。
4. 编写服务调用者，同样也是写一个handler，然后这里边比较复杂一点，因为需要使用到代理模式，使用代理类去完成服务端的调用，并且要实现callabel接口。
5. 编写客户端的程序引导器，和服务端类似，也是套用netty就可以了。

代码实现

 这个今天晚上回来再做~ 

 由于最近出差，有点疲惫，我这里就放两个案例，来自别人的文章。为什么是两个案例呢？实际上都是基于netty写的RPC案例，但是有差别：差别就在于一篇文章把代理类写到了客户端，一片文章把代理类写到了服务端。我觉得都可以，所以放两篇在这里，我就不cv代码了。一片比较详细，代码复制下来可以运行，一篇代码来自韩顺平老师的 netty与源码解析的课程的案例代码。

  代理类写在服务端的、韩顺平老师的案例：

https://blog.csdn.net/weixin_45480785/article/details/113710579

  代理类写在客户端的：

https://blog.csdn.net/weixin_41835612/article/details/107032874#comments_17179275