1. 服务提供者启动与注册

1. 服务发布：
• 服务提供者启动时，将实现的服务接口通过 Dubbo 框架发布出来。通常，使用 @Service 注解或者在 XML 配置文件中进行配置。
• 例如，DemoService 是一个服务接口，DemoServiceImpl 是其实现类。在启动时，DemoServiceImpl 会被发布成一个服务。

2. 服务注册：
• Dubbo 服务提供者在启动时，会通过 Registry 接口向注册中心（如 Zookeeper、Nacos 等）注册自己所提供的服务。注册的信息包括服务接口名称、版本号、协议、服务地址（IP+端口）等。
• 这个过程由 Dubbo 的 RegistryProtocol 类负责。注册完成后，注册中心会维护一个服务列表，供消费者查询使用。

2. 服务消费者启动与订阅

1. 服务引用：
• 服务消费者通过 @Reference 注解或 XML 配置文件来引用服务。Dubbo 框架会根据配置的信息，从注册中心订阅所需服务的地址信息。
• 例如，消费者引用 DemoService 接口：

2. 服务发现与订阅：
• 消费者启动时，通过 Registry 接口向注册中心订阅自己所需的服务。注册中心将匹配到的服务提供者地址列表推送给消费者。
• 这个过程中，Dubbo 的 RegistryDirectory 负责管理从注册中心获取的服务列表，并且维护服务提供者的动态变化（如上线、下线等）。

3. 代理对象生成：
• Dubbo 为服务接口生成一个代理对象，这个代理对象实现了服务接口，并在内部封装了 RPC 调用逻辑。当应用程序调用这个代理对象的方法时，实际触发的是一次远程调用。
• 代理对象的生成由 ProxyFactory 完成，通常使用 Javassist 或 JDK 动态代理。

3. 远程调用的执行

1. 参数序列化：
• 调用方法的参数首先会被序列化为字节流，通常使用 Dubbo 内置的序列化机制（如 Hessian2、Kryo、Protobuf 等）。

2. 请求组装：
• Dubbo 将序列化后的参数、方法名、服务接口、版本号等信息封装成一个 RpcInvocation 对象，然后再封装为 RpcRequest，这个对象表示一次完整的 RPC 请求。
• 这一过程由 Invoker 接口的实现类 AbstractInvoker 和 InvokerInvocationHandler 处理。

3. 负载均衡与调用选择：
• 在多个服务提供者的场景下，Dubbo 会根据配置的负载均衡策略（如随机、轮询、一致性哈希等）选择一个具体的服务提供者进行调用。
• 选择过程由 LoadBalance 接口的实现类完成。

4. 网络通信：
• 选择好服务提供者后，Dubbo 将 RpcRequest 通过网络传输到服务提供者。网络通信通常使用 Netty 或者其他支持的通信框架。
• DubboProtocol 和 ExchangeClient 等组件负责将请求发送出去，并等待服务提供者返回响应。

4. 服务提供者处理请求

1. 请求反序列化：
• 服务提供者接收到请求后，会先对请求字节流进行反序列化，将其还原为 RpcInvocation 对象。

2. 请求分发：
• RpcInvocation 对象被传递给服务端的 Invoker，具体由 AbstractProxyInvoker 处理。它会根据请求信息找到对应的服务实现类，并调用相应的方法。

3. 方法执行：
• 服务实现类的方法被调用，传入反序列化后的参数，并执行业务逻辑，产生返回值。

4. 响应序列化：
• 方法的返回值会被序列化为字节流，并封装成 RpcResponse 对象。RpcResponse 包含了调用结果或异常信息。

5. 响应发送：
• RpcResponse 通过网络传输返回给消费者。

5. 消费者接收响应

1. 响应接收与反序列化：
• 消费者端接收到服务提供者的响应后，会对响应字节流进行反序列化，还原成原始的返回值对象。

2. 结果处理：
• 反序列化后的返回值将被传递给调用代理对象的方法，最终返回给消费者应用程序。

3. 异常处理：
• 如果调用过程中发生异常，Dubbo 会将异常信息封装在 RpcResponse 中返回给消费者，消费者可以根据业务需求进行处理或重试。

6. 调用结束与资源清理

结论