目录
Dubbo 是一款高性能、轻量级的开源 RPC（远程过程调用）框架，主要用于构建分布式服务和微服务架构。
要说 Dubbo 运行流程就不得不先来了解一下 Dubbo 的核心组件了，因为 Dubbo 的交互流程是和核心组件息息相关的。
Dubbo 核心组件有以下几个：
服务提供者（Provider）：暴露服务的应用，通过 Dubbo 框架将自身的服务接口及实现注册到注册中心。
服务消费者（Consumer）：调用远程服务的应用，从注册中心订阅所需的服务，然后通过远程调用消费服务。
注册中心（Registry）：集中管理服务的地址信息，服务提供者和服务消费者均在此注册或订阅服务信息。常见的注册中心有 ZooKeeper、Nacos 等。
Dubbo 运行流程如下图所示：
它的执行流程如下：
服务提供者会将实例（URL 地址）注册到注册中心，注册中心负责对数据进行聚合（健康检测）。
消费者从注册中心读取地址列表并订阅变更，每当地址列表发生变化，注册中心将最新的列表通知到所有订阅的消费者实例。
消费者得到服务实例之后，通过 Dubbo 内置的负载均衡策略，选择其中的一个节点，之后使用 RPC 的方式与服务提供者建立连接，并进行通讯和服务调用。
更详细的调用流程如下：
Dubbo通讯协议
Dubbo 框架提供了自定义的高性能 RPC 通信协议：基于 HTTP/2 的 Triple 协议和基于 TCP 的 Dubbo2 协议。除此之外，Dubbo 框架支持任意第三方通信协议，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2 等，更多协议可以通过自定义扩展实现。这对于微服务实践中经常要处理的多协议通信场景非常有用。Dubbo 框架不绑定任何通信协议，在实现上 Dubbo 对多协议的支持也非常灵活，它可以让你在一个应用内发布多个使用不同协议的服务，并且支持用同一个 port 端口对外发布所有协议。
通过 Dubbo 框架的多协议支持，你可以做到：
将任意通信协议无缝地接入 Dubbo 服务治理体系。Dubbo 体系下的所有通信协议，都可以享受到 Dubbo 的编程模型、服务发现、流量管控等优势。比如 gRPC over Dubbo 的模式，服务治理、编程 API 都能够零成本接入 Dubbo 体系。
兼容不同技术栈，业务系统混合使用不同的服务框架、RPC 框架。比如有些服务使用 gRPC 或者 Spring Cloud 开发，有些服务使用 Dubbo 框架开发，通过 Dubbo 的多协议支持可以很好的实现互通。
让协议迁移变的更简单。通过多协议、注册中心的协调，可以快速满足公司内协议迁移的需求。比如如从自研协议升级到 Dubbo 协议，Dubbo 协议自身升级，从 Dubbo 协议迁移到 gRPC，从 HTTP 迁移到 Dubbo 协议等。
Dubbo负载均衡策略
目前 Dubbo（3.X）内置了如下负载均衡算法如下：
Weighted Random LoadBalance（加权随机）：默认负载均衡算法，默认权重相同。按权重设置随机概率。缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
RoundRobin LoadBalance（加权轮询）：借鉴于 Nginx 的平滑加权轮询算法，默认权重相同，按公约后的权重设置轮询比率，循环调用节点。缺点：同样存在慢的提供者累积请求的问题。
LeastActive LoadBalance（最少活跃优先+加权随机）：背后是能者多劳的思想，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数 - 响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。
Shortest-Response LoadBalance（最短响应优先+加权随机）：更加关注响应速度，在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。使得响应时间越快的提供者，处理更多的请求。缺点：可能会造成流量过于集中于高性能节点的问题。
ConsistentHash LoadBalance（一致性哈希）：确定的入参，确定的提供者，适用于有状态请求。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
P2C LoadBalance（随机选择两个节点+连接数较小）：随机选择两个节点后，继续选择“连接数”较小的那个节点。对于每次调用，从可用的 provider 列表中做两次随机选择，选出两个节点 providerA 和 providerB，比较 providerA 和 providerB 两个节点，选择其“当前正在处理的连接数”较小的那个节点。
Adaptive LoadBalance（自适应负载均衡）：在 P2C 算法基础上，选择二者中 load 最小的那个节点，是一种能根据后端实例负载自动调整流量分布的算法实现，它总是尝试将请求转发到负载最小的节点。
RPC和HTTP有什么区别？
RPC（Remote Procedure Call，远程过程调用）和 HTTP（Hypertext Transfer Protocol，超文本传输协议）都是用于服务间通讯的，它们主要区别如下：
概念和使用场景不同：
RPC：RPC 是一种通信模式，允许一个程序在另一个地址空间上执行远程计算过程，使得客户端调用远程服务就像调用本地方法一样。
HTTP：HTTP 是一个应用层协议，用于在客户端和服务器之间传输文本、图像、视频等超媒体资源，通常用于 Web 应用之间的通信。
传输数据不同：
RPC：RPC 通常基于二进制数据传输，可以使用更高效的序列化方式（如 Protobuf、Thrift）进行数据交换。
HTTP：HTTP 使用文本协议，请求和响应数据通常是基于文本格式（如 JSON、XML）进行传输。
传输效率与性能不同：
RPC：因为 RPC 通常使用更高效的二进制序列化（如 Protobuf、Thrift），减少了数据传输的体积，且由于其针对性的设计，往往在性能上更为优越，特别是在大量小数据包的传输场景。
HTTP：传统上使用文本格式如 JSON 进行数据交换，这可能导致更大的数据包和更多的序列化/反序列化开销，但在 HTTP/2 中引入了头部压缩和多路复用，提升了效率。
让你设计一个RPC框架，如何考虑数据序列化问题？
数据序列化需要考虑的以下问题：
性能问题：选择高性能的序列化库至关重要。二进制序列化（如 Protocol Buffers, Apache Thrift, FlatBuffers）通常比文本格式（如 JSON、XML）更高效，因为它们占用的空间小，序列化和反序列化的速度更快。对于高性能要求的场景，应优先考虑这些二进制格式。
安全性：在序列化过程中，应考虑数据的安全性，避免敏感信息的泄露。可以采用加密序列化内容、过滤敏感字段或使用安全的传输层协议（如 TLS/SSL）来增加安全性。
兼容性：良好的版本兼容性是长期维护 RPC 框架的关键。设计时要考虑向前和向后兼容，即新老版本的序列化库应能互相理解和处理对方生成的数据格式。可以采用预留字段、版本标识符等机制来支持这一点。
跨语言支持：RPC 框架往往需要支持多种编程语言，因此选择一种跨语言的序列化方案是必要的。Protocol Buffers、Apache Thrift、Avro 等都是很好的选择，它们提供了多种语言的编解码库。
可扩展性：设计时应考虑到未来可能增加的数据结构和字段，序列化方案应易于扩展，支持动态字段、自定义类型等特性。
可配置性：允许用户根据实际需求选择或切换序列化策略。例如，对于对性能要求极高的场景，用户可以选择最高效的序列化方式；而对于调试或日志记录，可能会偏好人类可读性更好的格式。
异常处理：在序列化或反序列化过程中可能会遇到错误（如数据损坏、不兼容的版本等）。框架应能优雅地处理这些异常，并提供清晰的错误信息，帮助开发者诊断问题。