dubbo

RPC

https://cn.dubbo.apache.org/zh-cn/docs/concepts/rpc-protocol/

dubbo

弄清楚一个东西，需要知道，为什么需要dubbo，dubbo解决了哪些问题，dubbo的流程，dubbo的使用。

RPC通信协议

协议是 RPC 的核心，它规范了数据在网络中的传输内容和格式。除必须的请求、响应数据外，通常还会包含额外控制数据，如单次请求的序列化方式、超时时间、压缩方式和鉴权信息等。

协议的内容包含三部分

• 数据交换格式： 定义 RPC 的请求和响应对象在网络传输中的字节流内容，也叫作序列化方式
• 协议结构： 定义包含字段列表和各字段语义以及不同字段的排列方式
• 协议通过定义规则、格式和语义来约定数据如何在网络间传输。一次成功的 RPC 需要通信的两端都能够按照协议约定进行网络字节流的读写和对象转换。如果两端对使用的协议不能达成一致，就会出现鸡同鸭讲，无法满足远程通信的需求。

HTTP/1.1

基于HTTP协议之上的远程的调用更好的通用性，可扩展性，协议穿透性。

问题

1. 一个链路上只能有一个等待的Request请求。
2. 人类可以懂得传输格式，但性能相当差。
3. 无直接 Server Push 支持，需要使用 Polling Long-Polling 等变通模式

gRpc

上面提到了在 HTTP 及 TCP 协议之上构建 RPC 协议各自的优缺点，相比于 Dubbo 构建于 TCP 传输层之上，Google 选择将 gRPC 直接定义在 HTTP/2 协议之上。 gRPC 的优势由HTTP2 和 Protobuf 继承而来。

• 基于 HTTP2 的协议足够简单，用户学习成本低，天然有 server push/ 多路复用 / 流量控制能力
• 基于 Protobuf 的多语言跨平台二进制兼容能力，提供强大的统一跨语言能力
• 基于协议本身的生态比较丰富，k8s/etcd 等组件的天然支持协议，云原生的事实协议标准

但是也存在部分问题

• 对服务治理的支持比较基础，更偏向于基础的 RPC 功能，协议层缺少必要的统一定义，对于用户而言直接用起来并不容易。
• 强绑定 protobuf 的序列化方式，需要较高的学习成本和改造成本，对于现有的偏单语言的用户而言，迁移成本不可忽视

Triple协议

支持更多的协议。

部署架构

• 注册中心
• 配置中心
• 元数据中心