微服务好处和概念性的东西就不介绍了，对于微服务，个人认为并不是越复杂就越好，相反要结合自己公司的现状，适当的做一些裁剪，比如对于规模和业务量不是特别大的企业，就没有必要把服务总线，服务健康检查，服务路由选择，熔断等等加进来，相反，这一部分职责可以通过配置文件，nginx代理，api网关等等外围的技术来控制，当企业达到一定的规模之后，再来完善这部分内容，但是对于微服务处理过程来说，没有任何影响。
我这里根据json-rpc 2.0标准，结合网上一些开源的微服务架构思想，采用dotnetty技术，搭建了一套轻量级的微服务通信组件，组件专注于Rpc Call这块的处理。
整体说明
先上一张图，Rpc socket调用过程
Rpc调用处理方式
三种处理方式：1. Local本地调用，一个服务调用另一个服务，有可能另个服务都宿主到同一个应用程序中，这种情况直接走本地调用；2. Tcp调用，这个应该是最体现价值的一种方式，服务消费者和服务提供者分别宿主到企业内部服应用程序中，相互之间通信走Tcp通道；3. Http调用，对于服务消费者和服务提供者一个在企业外部，一个在企业内部，或者其他语言开发的应用程序交互需要简单的集成调用，这种可以走Http调用过程。
Socket消息传输
直接基于dotnetty传输处理，dotnetty传输通道是串行的，服务端接收到消息的时候，每一个消息是异步线程完成处理的。
消息处理对象
调用方需要构造消息对象，并对消息进行编码，生成消息唯一Id，线程阻塞，等待线程被唤醒。服务端接收到消息，对消息进行解码，答复客户端的时候，需要拿到客户端调用生成的消息Id回调客户端，客户端收到答复消息，根据消息Id唤醒等待线程。
Tcp Invoker和ProcessHandler
主要是对Json-Rpc调用的请求和答复进行处理，并对内容进行处理，ProcessHandler需要创建服务委托对象，调用真正的服务。
微服务详细交互过程
先放一张图，后续对这种图进行详细的介绍。
