一：前导知识
Http是超文本传输协议，跨平台性非常好。Http可以传输文本，更多的时候传输的是文本，我们也是可以传输二进制的，我们基于Http进行下载的时候，就是走的Http协议。
Tcp协议，处理的时候会更麻烦，我们需要自己开发服务器，对外提供服务，我们可以使用socket，可以使用nio，可以使用Netty。作为服务器端，暴露服务的时候，我们直接将我们的service暴露出来，这样的话业务性会很好，只不过我们的服务端代码实现起来会很繁琐。当我们进行调用的时候，这种方式比Http协议请求的方式会更加的方便，设计的好的话我们甚至可以在代码中直接service.业务性更强。
对于TCP这中方式的话，我们的客户端也是需要处理TCP协议的数据的，这样的话学位也是有一丢丢繁琐
TCP协议作为一种长链接协议。不需要进行频繁的三次握手四次挥手，Http协议底层也是TCP协议，但是高层进行了封装，需要频繁的关闭连接，这样就需要频繁的握手挥手，再加上应用层协议协议头内容很多，导致传输的内容负担较大。
通过RPC进行过程调用的时候，我们往往需要传递这样的几个参数：类的名字，方法的名称，方法的参数，就可以找到唯一的一个service中的方法，进而可以提供服务。服务提供完之后，再通过网络传输给我们的调用方。一个是有网络，另外一个通过页面。
通信的时候，我们基于Http协议还是TCP协议（不要再说底层就是TCP了!!!）的区别如下：
二：RPC框架的设计
1：设计目标
让调用者像调用本地方法一样，调用远端的服务方法。调用者就是我们的客户端，远端的服务方法就是我们的服务方service层中的某一个方法。基于这样的RPC来讲，我们的代码业务含义就会非常强。
我们想要达到这样的一个设计目标，我们必须需要解决两个问题：网络通讯+传递数据，接收返回值。在设计RPC的时候我们要这两个问题封装掉，让低级程序员使用的时候，达到上述的目的即可。
2：目标思路分析
1)：通讯方式
通讯方式，我们可以选择Http协议或者选择TCP协议，选择Http协议的话，我们大概率就不需要自己写服务了。
如果我们使用TCP协议的话，我们大概率的通讯工具使用的是Netty、Socket、Nio、Mina等等
2)：自定义协议
当然，如果我们使用TCP的话，我们可能还需要自定义协议。我们自定义协议在Netty文章中就已经探讨过了，我们自定义的协议包括两大部分：协议头+协议体（消息主体、协议主体）
3)：序列化方式
协议当中很重要的一个组成部分就是序列化，就是我们要传输的数据要以什么样的数据进行序列化。JSON，protobuf，hessian？
序列化是协议的一个组成部分，只不过他非常的重要，我们往往把他给拿出来单独来讲。
二进制协议与非二进制协议：
这个协议，什么是二进制，什么不是二进制，网络传输的时候不都是二进制的吗？对了网络传输的时候都是二进制，网络底层通讯走的都是二进制，而我们现在考虑的序列化是站在Java的角度考虑这个问题。是网络传输的上游，我们走JSON的这样的方式的话，我们走的是{id:10,age:30}，如果走的时候Java的序列化的话，那么就是ObjectOutputStream转成的byte[]，当这些数据走到传输层的时候，就会变成二进制。
4)：客户端增加远程代理类
当请求达到服务端之后，我们的服务提供方也就是服务器，可以拿到客户端请求的类的名称、方法的名称、方法的参数。服务端就可以去调用这个方法，然后在这个方法当中去进行访客户端中的Dao，甚至Redis，MQ等其他资源，当业务结果处理完毕之后，将方法的返回结果基于序列化协议通过网络返回给调用端。
通过代理类为原始类增加额外功能。也就是在客户端当中使用了远端代理，通过代理的思想，完成对远端服务的功能的包含，以及外功能的编写。
补充说明：
我们一般将远端的服务方法叫做skeleton（骨架）代理类叫做（stub）这个stub是远端服务的代理，这个代理即完成网络通讯，又完成传输数据。
3：衍生问题
1)：注册中心
服务端有多个实例，这种情况下就必须考虑注册中心的功能了。注册中心有所有的服务的注册信息。
负载均衡：基于轮训或者是加权的一些策略，将请求打到对应的服务上
管理服务：那些服务是可用的、健康的。定期的发心跳，管理服务。
解耦合：不需要直接绑定到对应的服务上，而是都跟我们的注册中心发声联系。
注册中心的核心作用就是：服务的治理
1：负载均衡
2：健康管理 服务管理(心跳 重试【延迟队列时间论算法】)
3：解耦合 耦合性更低
4：熔断
5：限流 虽然做了限流，但是流量过大，我们必须做限流。
