释放双眼，带上耳机，听听看~！
开始造轮子之旅， 本期轮子：RPC框架。
在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第一篇文章， 主要从整体角度讲述了一个RPC框架组成结构与关注点， 并且附上了我的RPC框架的实现作为参考。
RPC框架的关注点
首先，什么是RPC？
RPC的全称是Remote Procedure Call，远程过程调用。
RPC框架有很多，比如hsf、dubbo等等。借助RPC框架，我们在写业务代码的时候可以不需要去考虑服务之间的通信等问题，在调用远程服务的时候就像调用本地的方法那么简单。
那么，要写一个RPC框架应该由哪些部分组成，关注哪些东西？
1.简化本地调用流程
既然我们要像调用本地方法那样调用远程服务， 那么就应该生成代理来帮助我们处理一切后续谈到的复杂流程。 很显然，我们可以通过动态代理的方式来做这件事情。
2. 服务发现与服务注册
- 如果连别的服务在哪都不知道，我们怎么去调用？ 所以，我们需要有一个服务注册中心。 通过这个中心，服务可以把自己的信息注册进来，也可以获取到别的服务的信息。
- 客户端也需要watch服务注册中心的目标服务的地址的变化
3. 网络通信
- 服务和服务之间的网络通信模型是怎样的？ 是NIO还是IO？
- 客户端如何复用与服务端的连接， 而不是每次请求都重新创建一个新连接？
4. 消息的序列化
服务之间通信的消息通过什么方式进行序列化？ hessian，XML、JSON、Protobuf甚至Java原生的序列化方式， 你总得选择一个。
5.容灾
这个话题就深了：
- 健康监测： 在某一个服务节点挂掉的时候， 如何在服务注册中心删去这个服务地址？
- 服务调用超时与重试： 在调用一个服务实例的时候，如果超时或者报错，怎么处理？
- 服务限流：如何限制最大并发数？这个又可以从客户端和服务端两个角度分析。
6.负载均衡
这个很好理解，客户端通过服务注册中心拿到一堆地址，该调哪个呢？
最简单的方式，可以通过随机、轮询的方式去获取到一个地址。 如果做得更深入一些，可以根据服务端的响应时间等信息去做进一步的负载均衡。
我的RPC框架实现
目前我的RPC框架已经简单实现了上述关注点1-4，可以成功的运行起来了，之后会继续完善代码。这个RPC框架暂且叫hrpc, 如果想看全部代码可以访问项目github地址
关于这些关注点以及具体的代码实现， 我会在后续一段时间里写这个系列的更多博客来分点阐述。感兴趣的话可以持续关注我的博客。
