二进制类RPC协议

数据中心内部是如何相互调用的

API网关用来管理API，但是API实现一般在一个叫做Controller层的地方。这一层对外提供API，由于是让陌生人访问的，我们能看到目前业界主流的，基本都是RESTful的API，是面向大规模互联网应用的。

如何解决协议约定问题

Dubbo中默认的RPC协议是Hessian2。为了保证传输的效率，Hessian2将远程调用序列化为二进制进行传输，并且可以进行一定的压缩。这个时候你可能会疑惑，同为二进制的序列化协议，Hessian2和前面的二进制RPC有什么区别呢？
Hessian2是一种自描述的协议，不需要原来需要定一个一个文件，通过这个文件生成客户端和服务端的Stub，才能进行相互调用。

如何解决RPC传输的问题

在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序列化方式，当然还有其他选择。例如，Dubbo从Spark哪里借鉴Kryo,实现高性能的序列化。
  当到了微服务的阶段，服务粒度更细，模块之间的粒度更细，模块之间的关系更加复杂，虽然二进制的方式进行序列化，不用协议生成Stub文件，但是接口中的DTO对象，还是需要共享JAR，所以

1. 建立严格的项目管理流程，只与允许上层调下层，接口保持兼容性，不兼容的接口新添加而非改原来的，当接口通过监控，发现不用的时候，再下掉。升级的时候，先升级服务端，再升级消费端
2. 用RESTful的方式，最后是JSON就行，性能的提升可以通过横向扩展来抵消单机的性能损耗
   小结：

• RESTful API对于接入层和Controller层之外的调用，已基本形成事实标准，但是随着内部服务之间的调用越来越多，性能也越来越重要，于是Dubbo的RPC框架有了用武之地。
• Dubbo通过注册中心解决服务发现问题，通过Hessian2序列化解决协议约定问题，通过Netty解决网络传输的问题。
• 在更加复杂的微服务场景下，Spring Cloud的RESTful方式在内部调用也会被考虑，主要是JAR包的依赖和管理问题。