openFeign用的什么协议，dubbo用的什么协议
简单直接的答案是：
OpenFeign：默认使用 HTTP 协议（通常是 HTTP/1.1，也支持 HTTP/2），通信格式为 RESTful JSON。
Dubbo：默认使用 Dubbo 协议（一种自定义的、基于 TCP 的高性能二进制 RPC 协议），通信格式为 二进制序列化（如 Hessian2, Kryo）。
下面我们进行详细的对比和解释。
1. OpenFeign
协议：HTTP (应用层协议)
本质：OpenFeign 是一个声明式的 HTTP 客户端，它的目标是让远程 HTTP 调用像调用本地方法一样简单。它严格遵循 RESTful 风格的设计原则，将 API 调用映射为 HTTP 请求。
通信过程：
开发者定义一个接口，并使用
@FeignClient注解。OpenFeign 在运行时根据接口上的注解（如
@RequestMapping,@GetMapping）生成具体的 HTTP 请求。请求的协议、主机名、端口来自于服务名（通过 Nacos 等注册中心解析）。
参数会被序列化成 JSON 放在请求体（Body）中，或作为查询参数（Query Param）。
响应体的 JSON 数据再被反序列化成 Java 对象。
优点：
通用性强：HTTP 是互联网通用标准，任何语言、任何平台都能理解和调用，非常适合做跨语言、跨平台的开放式 API。
可读性好：使用 JSON 格式，日志、抓包都很容易阅读和调试。
与 Spring Cloud 生态无缝集成：天生就是为 RESTful 服务设计的，与 Spring MVC 的注解可以完美共用。
缺点：
性能相对较低：HTTP 协议的头部（Header）较大，且 JSON 序列化/反序列化的效率和传输后的数据体积都比二进制协议差。
通信模型受限：基于 HTTP 的请求-响应模型，不支持其他通信模式（如单向调用、流式处理）。
2. Dubbo
协议：Dubbo Protocol (传输层协议)
本质：Dubbo 是一个高性能的 Java RPC 框架。RPC（Remote Procedure Call）的目标是让远程方法调用在表现上完全和本地调用一样，它更关注于服务治理和高性能。
通信过程：
提供者（Provider）向注册中心注册服务，并暴露自己的地址。
消费者（Consumer）从注册中心订阅服务，获取提供者地址列表。
消费者与提供者之间建立一条或多条长连接的 TCP 连接，而不是每次调用都像 HTTP 一样进行“三次握手、四次挥手”。
调用时，方法名、参数等被序列化成二进制字节流，通过长连接传输。
提供者接收后，将二进制流反序列化成参数对象，执行本地方法，再将结果序列化后返回。
优点：
性能极高：
长连接：省去了频繁建立 TCP 连接的开销。
二进制协议：协议头很小，有效负载高。
高效序列化：默认使用 Hessian2，也支持更快的 Kryo、FST 等，比 JSON 效率高得多。
功能丰富：原生支持更复杂的 RPC 模式，如异步调用、参数回调、泛化调用、流式处理等。
服务治理能力强：内置了强大的负载均衡、容错策略、隐式参数传递等。
缺点：
通用性差：自定义的二进制协议对语言和平台不友好。虽然 Dubbo 3 推出了 Triple 协议（基于 HTTP/2）以改善跨语言支持，但其核心默认仍是 Dubbo 协议。
可读性差：传输的是二进制流，需要专门的工具才能解析，调试不如 HTTP 方便。
对比总结表
特性 | OpenFeign | Dubbo |
|---|---|---|
核心定位 | 声明式 RESTful HTTP 客户端 | 高性能 Java RPC 框架 |
默认协议 | HTTP/1.1 (文本协议) | Dubbo 协议 (二进制协议) |
序列化方式 | JSON (文本) | Hessian2 等 (二进制) |
连接方式 | 通常为短连接（HTTP/1.1可Keep-Alive） | 长连接 |
性能 | 相对较低（头部大，序列化效率低） | 极高（头部小，序列化效率高） |
通用性 | 极强，跨语言、跨平台 | 较弱，主要面向 Java 生态（默认协议下） |
可读性/调试 | 好，可直接查看 HTTP 请求和 JSON 内容 | 差，需要工具解析二进制流 |
通信模式 | 主要支持请求-响应 | 支持异步、流式、回调等多种模式 |
适用场景 | 对外提供开放 API、内部对性能要求不极高的微服务 | 内部对性能要求极高的微服务调用 |
在 Spring Cloud Alibaba 中如何选择？
选择 OpenFeign：
你的服务需要提供给前端、移动端或其他语言团队（如 Python, Go）调用。
系统内部大部分是 CRUD 操作，性能瓶颈通常在数据库，HTTP 的性能开销可以接受。
团队非常熟悉 Spring MVC 和 RESTful 风格，希望开发简单、调试方便。
选择 Dubbo：
系统内部存在大量高性能、高并发的内部服务调用（如核心交易链路上的服务）。
对响应延迟（Latency）非常敏感。
需要利用 Dubbo 的高级特性（如异步调用、泛化调用等）。
服务调用方和提供方基本都是 Java 技术栈。
值得注意的是：Spring Cloud Alibaba 完美支持这两种方式，你甚至可以在一个项目中同时使用 Feign 和 Dubbo，让它们分别应用于不同的场景。例如，对外用 OpenFeign 提供 RESTful API，内部核心服务之间用 Dubbo 进行高性能 RPC 调用。