NET Core微服务之路：利用DotNetty实现一个简单的通信过程

上一篇我们已经全面的介绍过《基于gRPC服务发现与服务治理的方案》，我们先复习一下RPC的调用过程（笔者会在这一节的几篇文章中反复的强调这个过程调用方案），看下图

根据上面图，服务化原理可以分为3步：

1. 服务端启动并且向注册中心发送服务信息，注册中心收到后会定时监控服务状态（常见心跳检测）；

2. 客户端需要开始调用服务的时候，首先去注册中心获取服务信息；

3. 客户端创建远程调用连接，连接后服务端返回处理信息；

 

第3步又可以细分，下面说说远程过程调用的原理：

目标：客户端怎么调用远程机器上的公开方法

1. 服务发现，向注册中心获取服务(这里需要做的有很多：拿到多个服务时需要做负载均衡，同机房过滤、版本过滤、服务路由过滤、统一网关等)；

2. 客户端发起调用，将需要调用的服务、方法、参数进行组装；

3. 序列化编码组装的消息，这里可以使用json，也可以使用xml，也可以使用protobuf，也可以使用hessian，几种方案的序列化速度还有序列化后占用字节大小都是选择的重要指标，对内笔者建议使用高效的protobuf，它基于TCP/IP二进制进行序列化，体积小，速度快。

4. 传输协议，可以使用传统的io阻塞传输，也可以使用高效的nio传输(Netty)；

5. 服务端收到后进行反序列化，然后进行相应的处理；

6. 服务端序列化response信息并且返回；

7. 客户端收到response信息并且反序列化；

 

　　正如上面第三步的第4条所提到，C类向S类调用时，可以选择RPC或者RESTful，而作为内部通讯，笔者强烈建议使用RPC的方式去调用S类上的所有服务，RPC对比RESTful如下：

优点：

1. 序列化采用二进制消息，性能好/效率高（空间和时间效率都很不错）；

2. 序列化反序列化直接对应程序中的数据类，不需要解析后在进行映射(XML,JSON都是这种方式)；

3. 相比http协议，没有无用的header，简化传输数据的大小，且基于TCP层传输，速度更快，容量更小；

4. Netty等一些框架集成（重点，也是本篇介绍的主要框架）；

缺点：

1. 使用复杂，维护成本和学习成本较高，调试困难；

2. 因为基于HTTP2，绝大部多数HTTP Server、Nginx都尚不支持，即Nginx不能将GRPC请求作为HTTP请求来负载均衡，而是作为普通的TCP请求。（nginx1.9版本已支持）；

3. 二进制可读性差，或者几乎没有任何直接可读性，需要专门的工具进行反序列化；

4. 默认不具备动态特性（可以通过动态定义生成消息类型或者动态编译支持，后续会介绍利用Rosyln进行动态编译的特性）；

 

通信传输利器Netty（Net is DotNetty）介绍

　　（先埋怨一下微软大大）我们做NET开发，十分羡慕JAVA上能有NETTY, SPRING, STRUTS, DUBBO等等优秀框架，而我们NET就只有干瞪眼，哎，无赖之前生态圈没做好，恨铁不成钢啊。不过由于近来Net Core的发布，慢慢也拉回了一小部分属于微软的天下，打住，闲话扯到这儿。

　　DotNetty是Azure团队仿照（几乎可以这么说）JAVA的Netty而出来的（目前已实现Netty的一部分），目前在Github上的Star有1.8K+，地址：https://github.com/Azure/DotNetty，没有任何文档，和代码中少量的注释。虽然比Netty出来晚了很多年，不过我们NET程序员们也该庆幸了，在自己的平台上终于能用上类似Netty这样强大的通信框架了。

传统通讯的问题：

　　我们使用通用的应用程序或者类库来实现互相通讯，比如，我们经常使用一个 HTTP 客户端库来从 web