Dubbo-3.0新特性

• 注册模型的改变
• Triple协议
• triple、dubbo、rest 的比较

注册模型的改变

• 在服务注册领域，市面上有两种模型，一种是应用级注册，一种是接口级注册
  • 在Spring Cloud中，一个应用是一个微服务
    • 把应用名以及应用所在服务器的IP地址和应用所绑定的端口注册到注册中心
    • 相当于key是应用名，value是ip+port
  • 在Dubbo2.7中，一个接口是一个微服务
    • 把接口名以及对应应用的IP地址和所绑定的端口注册到注册中心
    • 相当于key是接口名，value是ip+port
  • Dubbo3.0中将注册模型也改为了应用级注册
    • 提升效率节省资源的同时，通过统一注册模型，也为各个微服务框架的互通打下了基础

Triple协议

• HTTP1.x 协议性能太低了
  • 多余无用的字符太多了，比如回车符、换行符，这每一个字符都会占用一个字节，这些字节占用了网络带宽
  • 一条Socket连接，一次只能发送一个HTTP请求，导致Socket连接的利用低，并发、吞吐量低
    • 因为如果连续发送两个HTTP请求，然后收到了一个响应，就不知道这个响应对应的是哪个请求
• dubbo 协议就是为了解决上面两个问题，性能会更好，因为请求中没有多余的无用的字节
  • 每个Dubbo请求和响应中都有一个请求ID，这样就可以基于一个Socket连接同时发送多个Dubbo请求
    • 不用担心请求和响应对不上
  • 但是dubbo协议只能在Dubbo框架内部使用，不够通用
• Triple协议是基于HTTP2，没有性能问题，另外HTTP协议非常通用，兼容起来也比较简单
  • 还有很多额外的功能，比如流式调用
  • 并且兼容了gRPC

triple、dubbo、rest 的比较

• triple协议基于的是HTTP2，rest协议目前基于的是HTTP1，都可以做到跨语言
• triple协议兼容了gPRC（Triple服务可以直接调用gRPC服务，反过来也可以），rest协议不行
• triple协议支持流式调用，rest协议不行
• rest协议更方便浏览器、客户端直接调用，triple协议不行
  • 原理上支持，对triple协议的底层实现比较熟悉才行，得知道具体的请求头、请求体是怎么生成的
• dubbo协议是Dubbo3.0之前的默认协议，triple协议是Dubbo3.0之后的默认协议，优先用Triple协议
• dubbo协议不是基于的HTTP，不够通用，triple协议底层基于HTTP所以更通用
  • 比如跨语言、跨异构系统实现起来比较方便
• dubbo协议不支持流式调用