二进制类RPC协议

 Dubbo 的 RPC 传输问题。前面我们也说了，基于 Socket 实现一个高性能的服务端，是很复杂的一件事情，在 Dubbo 里面，使用了 Netty 的网络传输框架。Netty 是一个非阻塞的基于事件的网络传输框架，在服务端启动的时候，会监听一个端口，并注册以下的事件。连接事件：当收到客户端的连接事件时，会调用 void connected(Channel channel) 方法。当可写事件触发时，会调用 void sent(Channel channel, Object message)，服务端向客户端返回响应数据。

当可读事件触发时，会调用 void received(Channel channel, Object message) ，服务端在收到客户端的请求数据。当发生异常时，会调用 void caught(Channel channel, Throwable exception)。当事件触发之后，服务端在这些函数中的逻辑，可以选择直接在这个函数里面进行操作，还是将请求分发到线程池去处理。一般异步的数据读写都需要另外的线程池参与，在线程池中会调用真正的服务端业务代码逻辑，返回结果。

Hessian2 是 Dubbo 默认的 RPC 序列化方式，当然还有其他选择。例如，Dubbox 从 Spark 那里借鉴 Kryo，实现高性能的序列化。到这里，我们说了数据中心里面的相互调用。为了高性能，大家都愿意用二进制，但是为什么后期 Spring Cloud 又兴起了呢？这是因为，并发量越来越大，已经到了微服务的阶段。

同原来的 SOA 不同，微服务粒度更细，模块之间的关系更加复杂。在上面的架构中，如果使用二进制的方式进行序列化，虽然不用协议文件来生成 Stub，但是对于接口的定义，以及传的对象 DTO，还是需要共享 JAR。因为只有客户端和服务端都有这个 JAR，才能成功地序列化和反序列化。

此文章为10月Day6学习笔记，内容来源于极客时间《趣谈网络协议》，推荐该课程。