目录
前言：
今天在阅读阿里开发规范2016.12时，发现在命名规范中提到，在POJO类中的任何布尔类型的变量，都不要加is，否则部分框架解析会引起序列化错误
比如说：定义基本数据类型boolean isSuccess；的属性，它的方法也是isSuccess（），RPC框架在反向解析的时候会“以为”对应的属性名称是success，导致属性获取不到，抛出异常
我就有了一个疑问，什么是RPC框架？就去了解了下，在此记录
参考网址：什么是RPC框架 - 知乎
1.简介
1.1什么是RPC
RPC框架，全程Remote Procedure Call
其实就是一种远程的程序调用，远程服务调用，具体的实现有下面四种角色构成
- registry - 注册中心，当服务提供者启动时会向注册中心注册，然后注册中心会告知所有的消费者有新的服务提供者。
- provider - 服务的提供者，远程调用过程中的被消费方。
- consumer - 服务的消费者，远程调用过程中的消费方。
- monitor - 监视器，它主要负责统计服务的消费和调用情况。
1.2 演变过程
什么是提供方，什么是消费方呢？
比如有A,B两台独立的服务器，A定义了一个方法，B想要调用A定义的方法，A提要求，让B如果想要调用自己，得提供姓名和手机号，B同意了，远程调用了A
在这里A就是服务的提供者，在远程调用过程中的 “被消费方“
? ? ? ?而B就是服务的消费者，在远程调用过程中的 “消费方”
?后续如果服务提供方A ，要搬家了，得换地址
?那么服务消费方B，也得跟着改代码，改成A新的地址
?那B就觉得太麻烦了 能不能把修改A新的地址和调用A这两件事绑定在一起呢，这样就不用都改了
?B就把底层逻辑提取出来进行了封装，每次直接使用即可
后续服务提供方A，又提供了一个新方法，有新的功能，新的返回数据
服务消费方B就觉得，你每多一个方法，我就封装一个调用逻辑，太麻烦了，能不能共用同个调用逻辑呢
B就想办法，做一个代理模式来实现共用调用逻辑，解决这个问题
这就形成了简单的一个框架，当然再往下延伸还有很多
- 那如果有其他用户调用方法怎么办呢，能不能把这些方法放在一个固定的地方，然后他们谁都可以调用。这就是registry (注册中心)?，当服务提供者启动时会向注册中心注册，然后注册中心会告知所有的消费者有新的服务提供者。
- 如果调用的时候，突然服务不在了怎么办，能不能监控一下这个服务状态，出现问题的时候提前告知消费者一下，这就是monitor(监视器)，它主要负责统计服务的消费和调用情况。
还有一些是这些中心之间的通信协议，最基础的是TCP/IP协议，也是最有效不会过时的协议。像HTTP协议等就是基于TCP/IP升级的一种协议，通过URL传输JSON字符串来实现，比web serivce高效一些
1.3 框架
现在主流的框架有Dubbo、Spring Cloud等，微博内部使用的Motan，腾讯内部使用的Tars。
