Dubbo之_2_基础知识
前言
Github：https://github.com/HealerJean
一、什么是RPC
RPC（Remote Procedure Call Protocol）远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。简言之，RPC使得程序能够像访问本地系统资源一样，去访问远端系统资源。比较关键的一些方面包括：通讯协议、序列化、资源（接口）描述、服务框架、性能、语言支持等。
RPC就是从一台机器(客户端)上通过参数传递的方式调用另一台机器(服务器)上的一个函数或方法(可以统称为服务)并得到返回的结果。
二、dubbo 协议
1、Dubbo 协议
协议描述：基于 TCP 的二进制协议，性能高，适合 Dubbo 之间的 RPC 调用。
优点：
- 高性能，低延迟。
- 支持长连接，减少连接开销。
- 序列化效率高，适合大数据量传输。
缺点：
- 仅适合
Dubbo应用之间的通信，跨语言支持较差。
适用场景：
- 内部服务之间的高性能 RPC 调用。
- 服务提供者和消费者都是基于 Dubbo 的应用。
2、HTTP 协议
协议描述：基于 HTTP/HTTPS 的文本协议，兼容性强。
优点：
- 跨语言支持，兼容性强。
- 易于与外部系统集成。
- 调试方便，支持浏览器访问。
缺点：
- 性能较低，不适合高频调用。
- 文本协议，序列化效率低。
适用场景：
- 跨语言调用。
- 与外部系统集成。
- 对协议兼容性要求高的场景。
3、RMI 协议
协议描述：基于 Java RMI 的协议，适合 Java 应用之间的调用。
优点：
- 适合
Java应用之间的通信。 - 与现有
RMI系统集成方便。
缺点：
- 依赖 ` Java` 序列化，性能较低。
- 跨语言支持较差。
适用场景：
Java应用之间的通信。- 需要与现有
RMI系统集成的场景。
4、Hessian 协议
协议描述：基于 Hessian 的二进制协议，跨语言支持较好。
优点：
- 跨语言支持较好。
- 序列化效率较高，性能优于 HTTP。
缺点：
- 性能低于
Dubbo协议。 - 依赖
Hessian库，集成复杂度较高。
适用场景：
- 需要跨语言调用。
- 对性能要求较高，但不需要极致性能的场景。
5、Thrift 协议
协议描述：基于 Apache Thrift 的协议，支持多种语言，性能较高。
优点：
- 支持多种语言，跨语言支持好。
- 性能优异，适合大规模分布式系统。
缺点：
- 需要额外依赖
Thrift库，集成复杂度较高。
适用场景：
- 多语言环境下的 RPC 调用。
- 对性能要求较高的场景。
6. gRPC 协议
协议描述：基于 gRPC 的协议，支持多种语言，性能高。
优点：
- 基于 HTTP/2，性能极高。
- 支持流式传输，适合实时通信。
- 跨语言支持好。
缺点：
- 需要额外依赖 gRPC 库，集成复杂度较高。
适用场景：
- 多语言环境下的 RPC 调用。
- 对性能要求极高的场景。
- 实时通信场景。
7. WebService 协议
协议描述：基于 SOAP 的协议，适合与遗留系统集成。
优点：
- 兼容性强，适合与旧系统集成。
- 支持
SOAP标准，易于与 Web 服务集成。
缺点：
- 性能较低，不适合高频调用。
- 文本协议，序列化效率低。
适用场景：
- 需要与
SOAP服务集成。 - 对协议兼容性要求高的场景。
8. Redis 协议
协议描述：基于 Redis 的协议，适合简单的服务调用。
优点：
- 轻量级，适合小规模应用。
- 易于与
Redis集成。
缺点：
- 性能较低，不适合复杂
RPC场景。 - 功能有限，仅适合简单调用。
适用场景：
- 简单的服务调用场景。
- 需要与
Redis集成的场景。
9. Memcached 协议
协议描述：基于 Memcached 的协议，适合简单的服务调用。
优点：
- 轻量级，适合小规模应用。
- 易于与
Memcached集成。
缺点：
- 性能较低，不适合复杂
RPC场景。 - 功能有限，仅适合简单调用。
适用场景：
- 简单的服务调用场景。
- 需要与
Memcached集成的场景。
三、Dubbo 集群容错方案
| 方案名称 | 描述 | 适用场景 |
|---|---|---|
Failover |
默认策略，调用失败后自动切换到其他提供者并重试。 | 适合读操作或幂等操作（如查询、读取数据）。 |
Failfast |
调用失败后立即抛出异常，不进行重试。 | 适合非幂等操作（如写操作），避免重复执行。 |
Failsafe |
调用失败后忽略错误，记录日志并返回空结果。 | 适合非核心业务，允许调用失败不影响主流程。 |
Failback |
调用失败后记录失败请求，并定时重试。 | 适合异步操作或最终一致性场景。 |
Forking |
并行调用多个提供者，只要有一个成功就返回结果。 | 适合对实时性要求高的场景（如实时计算、实时推荐）。 |
Broadcast |
向所有提供者发送请求，任意一个失败则抛出异常。 | 适合需要通知所有提供者的场景（如缓存更新、配置同步）。 |
Available |
只调用当前可用的提供者，忽略不可用的提供者。 | 适合核心业务，保证调用成功。 |
Mergeable |
调用多个提供者，并将结果合并后返回。 | 适合需要从多个提供者获取数据的场景（如数据聚合、分片查询）。 |
2、Dubbo 核心的配置有哪些
3、Dubbo 服务暴露的过程
Dubbo 会在 Spring 实例化完 bean 之后，在刷新容器最后一步发布 ContextRefreshEvent 事件的时候，通知实现了 ApplicationListener 的 ServiceBean 类进行回调 onApplicationEvent 事件方法，Dubbo 会在这个方法中调用 ServiceBean 父类 ServiceConfig 的 export 方法，而该方法真正实现了服务的（异步或者非异步）发布。
8、Dubbo里面有哪几种节点角色
- dubbo是一个分布式开发框架
- Provider: 暴露服务的服务提供方。
- Consumer: 调用远程服务的服务消费方。
- Registry: 服务注册与发现的注册中心。
- Monitor: 统计服务的调用次调和调用时间的监控中心。
- Container: 服务运行容器。
9、服务注册与发现的流程图
流程说明：
1.Provider(提供者)绑定指定端口并启动服务
2.指供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储
3.Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心
4.注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。
5.Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。
6.Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer
设计的原因：
1.Consumer 与Provider 解偶，双方都可以横向增减节点数。
2.注册中心对本身可做对等集群，可动态增减节点，并且任意一台宕掉后，将自动切换到另一台
3.去中心化，双方不直接依懒注册中心，即使注册中心全部宕机短时间内也不会影响服务的调用
4.服务提供者无状态，任意一台宕掉后，不影响使用 ———————————————
