【C++篇】：ServiceBus RPC 分布式服务总线框架项目

✨感谢您阅读本篇文章，文章内容是个人学习笔记的整理，如果哪里有误的话还请您指正噢✨
✨ 个人主页：余辉zmh–CSDN博客
✨ 文章所属专栏：c++篇–CSDN博客

ServiceBus RPC 分布式服务总线框架

项目简介

ServiceBus RPC是一个高性能的分布式服务总线框架，集成了RPC远程调用、服务注册发现、主题发布订阅三大核心功能。采用C++实现，基于Muduo网络库，支持多种调用模式、负载均衡、故障容错、实时消息推送等企业级特性。

核心特性

• ⚡ 高性能网络通信: 基于Muduo高性能网络库，支持异步非阻塞IO
• 🔧 多种调用模式: 同步阻塞、异步延迟、回调驱动三种调用方式
• 🌐 分布式服务治理: 完整的服务注册发现机制，支持动态扩缩容
• ⚖️ 智能负载均衡: 客户端轮转负载均衡，支持算法扩展
• 📨 实时消息系统: 发布-订阅模式的主题消息推送
• 🛡️ 类型安全: 编译时+运行时双重类型检查
• 🔄 模式灵活: 支持简单模式和分布式模式灵活切换

解决的核心问题

• 分布式系统通信复杂性: 提供统一的通信抽象层
• 服务发现和治理难题: 自动化的服务注册发现机制
• 异步编程复杂性: Promise/Future模式简化异步操作
• 消息通信需求: 内置发布-订阅消息系统

技术栈

核心技术依赖

• C++11/17 智能指针，RAII，移动语义等现代C++特性
• CMake 3.10+ 自动化构建系统
• Muduo 高性能网络库 - 提供异步非阻塞IO能力
• JsonCpp JSON处理库 - 消息序列化和RPC参数传递
• MyLogs 自定义日志库 - 分布式系统日志管理

项目结构

ServiceBus-RPC/
├── source/
│   ├── common/          # 框架核心基础模块 (抽象层+具象层)
│   │   ├── detail.hpp   # 工具基础设施 (日志、JSON、UUID)
│   │   ├── fields.hpp   # 字段与类型定义
│   │   ├── abstract.hpp # 抽象接口定义  
│   │   ├── message.hpp  # 消息具体实现
│   │   ├── net.hpp      # 网络通信层实现
│   │   └── dispatcher.hpp # 消息路由层实现
│   ├── client/          # 客户端模块
│   │   ├── requestor.hpp    # 请求管理层 (所有客户端通用)
│   │   ├── rpc_caller.hpp   # RPC调用层 (RPC调用客户端专用)
│   │   ├── rpc_registry.hpp # 服务注册发现层 (双功能模块)
│   │   ├── rpc_topic.hpp    # 主题订阅层 (主题客户端专用)  
│   │   └── rpc_client.hpp   # 客户端业务层整合
│   └── server/          # 服务端模块
│       ├── rpc_router.hpp   # 服务路由层 (RPC服务器专用)
│       ├── rpc_registry.hpp # 服务注册中心层 (注册中心专用)
│       ├── rpc_topic.hpp    # 主题订阅层 (主题服务端专用)
│       └── rpc_server.hpp   # 服务端业务层整合
├── demo/                # 第三方库练习和学习代码
├── test/                # 测试代码
└── README.md            # 本文档
└── BUG_FIX_REPORT.md    # 并发BUG修复文档
└── README_TEST.md       # gao'bing'a压力测试报告

框架整体设计思想

本项目采用三层架构设计：抽象层、具象层、业务层，实现分布式RPC调用、服务注册发现和主题发布订阅功能。

系统架构组成

• 服务注册中心服务器: 全局服务治理
• 服务提供端: RPC调用服务器 + 服务注册客户端（复合架构）
• 服务发现端: RPC调用客户端 + 服务发现客户端（复合架构）
• 主题发布订阅服务端: 独立的消息中间件服务
• 主题订阅客户端: 应用程序的消息订阅功能

---

抽象层 (Abstract Layer)

工具基础设施 (detail.hpp)

全局日志系统

• 三套日志器: server_logger、client_logger、root_logger分别用于不同组件
• 统一初始化: initLoggers()函数使用建造者模式创建日志器

JSON序列化工具 (JsonUtil)

• 序列化: 将Json::Value转换为字符串，支持UTF-8编码
• 反序列化: 字符串解析为Json::Value，提供错误处理

全局唯一ID生成器 (UuId)

• ID结构: 随机部分 + 原子递增序列号，确保全局唯一性

字段与类型定义 (fields.hpp)

消息字段常量

定义所有消息字段的键名常量：方法名、参数、主题信息、主机信息、响应码等。

核心枚举系统

• MsgType: 消息类型（RPC、主题、服务操作的请求响应）
• ServiceOpType: 服务操作类型（注册、发现、上线、下线）
• RCode: 响应码系统，包含详细错误分类和errReason()函数

抽象接口定义 (abstract.hpp)

消息抽象体系

• BaseMessage: 定义消息类型、ID、序列化等基本接口
• 多态支持: 统一处理不同类型消息

网络抽象体系

• BaseBuffer: 缓冲区数据读取和管理接口
• BaseProtocol: 协议处理和消息完整性检查接口
• BaseConnection: 连接管理和消息发送接口

服务抽象体系

• BaseServer: 服务端回调设置和启动接口
• BaseClient: 客户端连接管理和消息发送接口
• 回调函数类型: 连接、关闭、消息处理等回调类型定义

消息具体实现 (message.hpp)

JSON消息继承体系

• JsonMessage: 基于JSON的消息基类，实现序列化接口
• 请求消息: RpcRequest、TopicRequest、ServiceRequest，各自有严格的字段检查
• 响应消息: RpcResponse、TopicResponse、ServiceResponse
• 字段验证: 每种消息类型都有严格的字段检查机制

消息工厂模式 (MessageFactory)

• 类型创建: 根据MsgType创建对应消息对象
• 模板支持: 灵活的消息对象创建

---

具象层 (Implementation Layer)

网络通信层 (net.hpp)

网络基础实现

• MuduoBuffer: 基于Muduo的缓冲区实现，封装数据读取接口
• LVProtocal: 长度-值协议实现，格式为总长度-消息类型-ID长度-消息ID-消息体
• MuduoConnection: 基于Muduo的连接实现，封装发送和连接管理
• MuduoServer: 基于Muduo的服务端实现，维护连接映射和消息处理
• MuduoClient: 基于Muduo的客户端实现，支持异步连接和消息处理

工厂模式统一创建

BufferFactory、ProtocalFactory、ConnectionFactory、ServerFactory、ClientFactory提供统一的对象创建接口。

消息路由层 (dispatcher.hpp)

类型擦除设计模式 - 三层架构

1. 类型擦除层 (CallBack基类)

• 作用: 消除类型差异，提供统一抽象接口
• 核心功能: 将不同消息类型的包装器都存放在同一类型的容器中，实现异构类型的同构存储
• 关键接口: 提供onMessage虚函数接口

2. 类型包装层 (CallBackT模板子类)

• 实例对象: 包装器 (Wrapper)，每个包装器对应特定消息类型
• 核心成员: _handler处理器 - 可调用对象
• 核心逻辑: 向下转型 + 调用具体处理器

3. 消息分发层 (Dispatcher类)

• 实例对象: 消息分发器
• 核心数据: 路由映射表_handlers - 存储消息类型与包装器指针的映射

工作流程

注册阶段: 创建包装器 → 包装处理函数 → 建立类型映射
分发阶段: 消息类型查找 → 包装器定位 → 向下转型 → 处理器调用

核心数据流: 基类消息对象 → 查路由映射表 → 找到包装器 → 向下转型 → 调用具体处理器 → 业务层处理

---

客户端中间层模块

请求管理层 (requestor.hpp) - 所有客户端通用

核心设计思想

请求管理层作为客户端服务总线框架的异步转同步适配器，负责管理请求的完整生命周期，将底层异步网络通信转换为不同的响应处理策略（同步等待/回调处理）。

请求描述结构体 (ReqDescribe)

设计目的: 封装单个RPC请求的完整上下文信息

核心成员:

1. 请求消息基类指针 - 利用多态机制支持不同类型的请求消息
2. 响应处理类型标识 - 决定同步还是回调处理方式
3. Promise响应封装器 - Promise/Future模式实现异步转同步的核心机制
4. 回调处理函数 - 支持事件驱动的异步响应处理

三大功能模块

1. 响应处理函数 (onResponse)

• 注册到消息分发器，作为所有响应消息的统一入口
• 处理流程: 收到响应 → 提取消息ID → 查找请求描述 → 类型分发处理 → 清理资源
• 同步处理: 设置Promise值，唤醒等待的Future
• 回调处理: 直接执行用户回调函数

2. 请求发送接口 (两种处理模式)

• 同步处理模式: 第一个send创建空Future委托给第二个send然后阻塞等待，第二个send是异步发送的真正实现，实现代码复用
• 回调处理模式: 创建回调请求描述，包含用户回调函数，立即发送并返回

3. 请求映射表管理

• 维护消息ID到请求描述的映射关系，支持O(1)查找，线程安全保护

核心技术机制

• Promise/Future异步转同步: 发送时创建Promise获取Future，响应时设置Promise值唤醒阻塞
• 请求-响应精确匹配: 基于消息ID建立映射关系，支持并发多请求处理

RPC调用层 (rpc_caller.hpp) - RPC调用客户端专用

核心设计思想

RPC调用层是客户端服务总线框架的用户API层，为用户提供简洁易用的三种RPC调用方式，将底层复杂的消息处理机制抽象为用户友好的JSON接口。每个RpcCaller对象组合一个Requestor请求管理对象，通过委托模式实现所有底层操作。

三种调用方式深度解析

1. 同步调用方式 - 阻塞等待模式

• 核心特征: 当前线程完全阻塞，等待期间无法处理其他任务
• 线程行为: 发送后阻塞等待，返回时必然已获得结果
• 执行流程: 请求构造 → 同步发送 → 线程阻塞 → 响应处理 → JSON提取返回
• 适用场景: 关键业务逻辑，必须等待结果才能继续

2. 异步调用方式 - 延迟获取模式

• 核心特征: 发送后立即返回，阻塞点延迟到结果获取时
• 线程行为: 发送时不阻塞，可处理其他任务，需要结果时调用future.get()才可能阻塞
• 执行流程: 请求构造 → Promise创建 → Future关联 → 回调绑定 → 立即返回 → 延迟获取
• 技术机制: 单级Promise/Future封装，将JSON结果封装到Future对象
• 关键洞察: 异步只是延迟了阻塞时机，最终处理结果仍需用户线程参与

3. 回调调用方式 - 完全异步模式

• 核心特征: 发送后完全解放当前线程，类似事件驱动的异步IO
• 线程行为: 发送后立即返回，当前线程永不阻塞，控制权完全转移给其他线程
• 执行流程: 请求构造 → 回调包装 → 发送返回 → 线程解放 → 自动处理 → 自动回调
• 编程模型: 类似epoll/select的事件驱动模式，最大化线程利用率

三种模式的本质差异

• 控制权: 同步调用用户完全控制 → 异步调用用户控制获取时机 → 回调调用完全交给框架
• 阻塞特性: 同步调用发送时阻塞 → 异步调用获取时阻塞 → 回调调用永不阻塞
• 线程利用率: 同步最低 → 异步中等 → 回调最高

私有回调处理器

• callBack1: 异步调用处理器，在网络线程中将JSON结果设置到Promise对象
• callBack2: 回调调用处理器，在网络线程中执行用户回调函数

服务注册层 (client/rpc_registry.hpp - Provider类) - 服务注册客户端专用

设计思想

为服务提供端的客户端身份提供向注册中心注册服务的能力。组合请求管理层，专注注册逻辑，构建注册请求并同步发送到注册中心，处理注册响应和错误验证。

服务发现层 (client/rpc_registry.hpp - Discoverer+MethodHost类) - 服务发现客户端专用

MethodHost - 负载均衡主机管理器:

• 设计目的: 管理单个服务方法对应的所有可用主机，提供客户端侧负载均衡能力
• 主机管理: 支持主机新增和移除，线程安全操作
• 负载均衡算法: 使用取模运算实现轮转负载均衡，算法集中易于扩展

Discoverer - 服务发现核心:

• 两级发现机制: 本地缓存优先查找 + 远程注册中心查询
• 缓存管理: 维护服务方法名到主机管理器的本地映射
• 实时通知处理: 处理服务上线/下线通知，实时更新本地缓存
• 连接清理机制: 服务下线时的客户端连接清理

主题订阅层 (client/rpc_topic.hpp) - 主题订阅客户端专用

核心设计思想

客户端TopicManager是主题订阅系统的客户端适配器，为客户端提供完整的主题操作能力，将复杂的主题操作封装成简洁的客户端API，同时管理本地的订阅回调函数映射关系。

组合关系设计

核心组件: Requestor(请求管理) + 回调函数管理器

关键成员:

• Requestor对象: 负责与主题服务端的网络通信
• 主题回调映射表: 维护主题名称到订阅回调函数的映射关系
• SubCallBack类型: 订阅回调函数类型，接收主题名称和消息内容

五大主题操作接口

1. 主题创建/删除: 向主题服务端发送创建/删除请求，使用commonRequest统一处理

2. 主题发布: 向指定主题发布消息内容，服务端会广播给所有订阅者

3. 主题订阅 - 复杂的三步操作:

• 本地回调注册: 先在本地注册订阅回调函数
• 服务端订阅请求: 向服务端发送订阅请求
• 失败回滚处理: 服务端订阅失败时删除本地已注册的回调

4. 取消订阅 - 两步清理操作:

• 本地回调删除: 先删除本地订阅回调
• 服务端取消请求: 通知服务端取消订阅

订阅消息处理 (onPublish)

注册机制: 注册到消息分发器，处理服务端推送的主题发布消息

处理流程: 消息类型验证 → 内容提取 → 回调函数查找 → 用户回调执行

通用请求处理 (commonRequest)

模板方法模式: 所有主题操作共享统一的处理流程

处理步骤: 请求消息构建 → 条件字段处理 → 同步请求发送 → 响应验证处理

回调函数管理

• 回调注册: 将用户回调与主题名称建立映射
• 回调删除: 取消订阅时清理回调映射
• 回调查找: 收到主题消息时查找对应处理函数
• 线程安全: 所有回调映射操作都有锁保护

---

服务端中间层模块

服务路由层 (rpc_router.hpp) - RPC调用服务器专用

核心设计思想

RPC服务路由层是服务端服务总线框架的核心中间层，负责处理RPC请求消息，根据方法名提供对应的服务实现，执行业务逻辑后封装结果发送响应。

VType类型系统

为RPC服务参数和返回值提供严格的类型约束系统，包含基础类型和复合类型，与JSON类型系统完美映射。

ServiceDescribe类 - RPC服务抽象

设计目的: 抽象和封装单个RPC服务方法的完整元信息和处理逻辑

核心成员: 服务方法名、服务处理函数、参数描述列表、返回结果类型

三大核心接口:

1. 参数校验接口: 依次检验参数存在性和类型匹配性
2. 服务执行接口: 调用业务处理函数并验证返回结果类型
3. 元信息访问接口: 提供服务方法名访问

ServiceManager - 本地服务管理器

核心职责: 作为单个服务提供端内部的服务管理器，管理当前服务端内部的所有RPC服务方法

存储机制: 哈希表存储方法名到服务描述对象的映射，O(1)查找效率，线程安全保护

服务管理接口: 服务注册insert、服务发现select、服务移除remove

RpcRouter - 服务路由器

设计定位: 服务路由层的核心组件，包含本地服务管理器

RPC请求处理: 注册到消息分发器，四阶段处理流程：

1. 服务发现: 根据方法名查找服务描述对象
2. 参数校验: 严格的参数存在性和类型检查
3. 服务执行: 调用业务处理函数并验证结果类型
4. 响应构建与发送: 构建响应消息发送给客户端

错误处理: 四级错误机制（服务未找到、参数无效、内部错误、处理成功）

全局服务注册中心层 (server/rpc_registry.hpp) - 服务注册中心服务器专用

核心设计思想

全局服务注册中心中间层是分布式服务总线框架的核心治理组件，负责管理整个分布式系统中所有的服务提供端和服务发现端，与本地服务管理器形成本地-全局的两级服务治理架构。

ProviderManager - 服务提供者管理器

设计目的: 管理所有接入注册中心的服务提供端

Provider内部类: 抽象单个服务提供端信息，包含连接对象、主机信息、服务方法列表

双重映射表: 服务注册映射表（服务→提供者集合，一对多）+ 连接映射表（连接→提供者，一对一）

四大核心接口:

1. 服务提供者注册: 查找复用连接，创建或复用提供者，建立服务映射
2. 服务提供者查询: 根据连接查找提供者，用于下线通知
3. 服务提供者删除: 级联删除，从两个映射表删除所有映射关系
4. 主机地址查询: 返回能提供指定服务的所有主机地址列表

DiscovererManager - 服务发现者管理器

设计目的: 管理所有服务发现的客户端，提供服务状态变化的实时通知机制

Discoverer内部类: 抽象单个服务发现端的发现历史，包含连接对象、发现过的服务列表

双重映射表: 服务发现映射表（服务→发现者集合，一对多）+ 连接映射表（连接→发现者，一对一）

四大核心接口:

1. 服务发现者注册: 建立服务发现关系，为通知机制奠定基础
2. 服务发现者删除: 客户端断开时级联删除所有发现关系
3. 服务上线通知: 新服务提供者上线时通知所有相关客户端
4. 服务下线通知: 服务提供者下线时通知所有相关客户端

PDManager - 统一协调管理器

设计定位: 整合两个管理器，负责完整的分布式服务治理流程编排

两大核心接口:

1. 服务请求统一处理: 根据操作类型分别处理服务注册和服务发现
   • 服务注册流程: 提供者注册 → 上线通知 → 注册响应
   • 服务发现流程: 发现关系建立 → 可用服务查询 → 发现响应
2. 连接断开处理: 判断连接类型（提供端/发现端），执行差异化清理和通知

主题订阅层 (server/rpc_topic.hpp) - 主题订阅服务端专用

核心设计思想

服务端TopicManager是发布-订阅系统的核心管理器，维护主题与订阅者之间的多对多关系，支持实时消息推送和订阅关系管理。实现了完整的发布-订阅模式的服务端功能。

双重内部类设计

Subscriber类 - 订阅者抽象:

• 设计目的: 抽象单个订阅者（客户端）的订阅信息和连接管理
• 核心成员: 网络连接对象、订阅的主题名称集合、线程安全保护
• 主要接口: 新增订阅主题addTopic、移除订阅主题removeTopic
• 设计亮点: 记录订阅者的完整订阅历史，为连接断开清理提供数据基础

Topic类 - 主题抽象:

• 设计目的: 抽象单个主题的订阅者管理和消息发布能力
• 核心成员: 主题名称、订阅者对象集合、线程安全保护
• 主要接口: 新增/移除订阅者、消息推送pushMessage
• 消息推送: 遍历所有订阅者，通过连接对象批量发送消息，实现一对多广播

双重映射表设计

• 主题映射表: 主题名称 → 主题对象（一对一），用于主题操作的快速定位
• 订阅者映射表: 连接对象 → 订阅者对象（一对一），用于连接断开时的订阅关系清理

主题请求统一处理 (onTopicRequest)

注册机制: 注册到消息分发器，处理所有类型的主题操作请求

五大主题操作:

1. 主题创建: 创建主题对象并建立名称映射
2. 主题删除: 级联清理，删除主题并清理所有相关订阅者的订阅记录
3. 主题订阅: 查找主题，创建或复用订阅者，建立双向订阅关系
4. 取消订阅: 容错处理，从主题和订阅者两边清理关系
5. 主题发布: 查找主题对象，调用消息推送方法广播给所有订阅者

连接断开处理 (onConnshutdown)

处理复杂性: 最复杂的清理逻辑，需要处理订阅者断开时的完整清理

两阶段清理流程:

1. 订阅者识别: 根据连接查找订阅者，收集相关主题对象，删除订阅者映射
2. 批量关系清理: 遍历所有相关主题，逐个移除断开的订阅者

设计亮点

• 双向关系维护: 主题↔订阅者的双向关系确保数据一致性
• 并发安全设计: 三级锁保护（TopicManager、Topic、Subscriber独立加锁）
• 智能指针管理: 确保对象生命周期安全，支持级联清理
• 实时消息推送: 发布消息后立即推送给所有订阅者

---

业务层 (Business Layer)

业务层将具象层模块整合为完整的可部署系统。

服务端业务层

RegisterServer - 服务注册中心服务端

整合设计: 将全局服务注册中心中间层整合为完整的注册中心服务端

三层协作: PDManager(核心业务逻辑) + Dispatcher(消息分发) + BaseServer(网络通信)

初始化流程: 组件创建 → 消息处理链建立 → 网络服务器配置 → 连接生命周期管理

RpcServer - RPC服务调用服务端

复合架构: RPC调用服务器+服务注册客户端（可选）

双重地址管理: access_addr(服务监听地址) + registry_server_addr(注册中心地址)

双模式支持:

• 注册模式: 创建RegistryClient，同时具备RPC服务器和服务注册客户端能力
• 独立模式: 只具备RPC服务器功能，简单部署

双重注册机制:

• 远程注册: 向注册中心注册，让其他客户端能发现
• 本地注册: 注册到本地路由器，确保能处理服务请求
• 设计哲学: 能力优先，先确保能提供服务再考虑对外公开

TopicServer - 主题发布订阅服务端

整合设计: 将主题订阅服务端中间层整合为完整的发布-订阅中心服务端

三层协作: TopicManager(核心业务逻辑) + Dispatcher(消息分发) + BaseServer(网络通信)

初始化流程:

1. 组件创建: 创建TopicManager和Dispatcher，主题管理器优先
2. 消息处理注册: 将TopicManager的onTopicRequest注册到Dispatcher处理REQ_TOPIC消息
3. 网络服务器配置: 创建MuduoServer，建立完整的消息处理链路
4. 连接关闭处理: 设置连接断开回调，委托给TopicManager进行订阅关系清理

架构简化特点:

• 单一架构: 不需要复合架构，专注主题消息处理
• 专业化: 只处理主题相关请求，架构相对简单
• 独立部署: 可作为独立的消息中间件服务部署

客户端业务层

RegistryClient - 服务注册客户端

整合设计: 为服务提供端的客户端身份提供完整的服务注册能力

四层组件栈: Provider + Requestor + Dispatcher + MuduoClient

回调链建立: 响应处理注册 + 网络消息注册 + 自动连接

DiscoveryClient - 服务发现客户端

整合设计: 提供完整的服务发现和通知处理能力

四层组件栈: Discoverer + Requestor + Dispatcher + MuduoClient

双重消息注册:

• 服务发现响应处理: 处理主动发起的发现请求响应
• 服务状态通知处理: 处理注册中心推送的上线/下线通知

双向通信能力: 既能主动查询又能被动感知

RpcClient - RPC调用客户端

复合架构: RPC调用客户端 + 服务发现客户端(可选) + 连接池管理器

双模式支持:

• 服务发现模式: 组合DiscoveryClient + 连接池管理，支持多服务调用和负载均衡
• 独立模式: 单连接模式，直接连接目标RPC服务，简单高效

call()方法统一处理: 所有调用方式都遵循统一模板：获取连接 → 委托给RpcCaller

getRpcClient()核心逻辑:

• 服务发现模式: 服务发现（缓存优先+远程查询+负载均衡） → 连接池管理（缓存优先+动态扩展）
• 独立模式: 直接返回预配置连接，零开销

连接池管理:

• 连接创建: 消息回调复用、立即连接、自动入池
• 连接CRUD: 高效查找、映射建立、资源清理，使用AddressHash自定义哈希函数
• 生命周期: 智能指针确保连接安全管理

模式对比: 连接管理、服务范围、负载均衡、故障容错、部署复杂度、适用场景等维度差异

TopicClient - 主题发布订阅客户端

整合设计: 将主题订阅客户端中间层整合为完整的主题客户端，为用户提供简洁的主题操作接口

四层组件栈: TopicManager + Requestor + Dispatcher + MuduoClient

双重消息注册:

• 主题响应处理: 将Requestor的onResponse注册处理RSP_TOPIC类型的主题操作响应
• 主题发布消息处理: 将TopicManager的onPublish注册处理服务端推送的主题发布消息
• 自动分发: 收到主题消息后自动调用用户订阅回调

网络连接建立: 初始化时立即连接到主题服务端，建立消息处理链路

用户接口完全委托:

• 五大接口: 主题创建、删除、订阅、取消订阅、发布，全部委托给TopicManager处理
• 接口简化: 用户无需提供连接对象，内部自动使用维护的连接
• 连接管理: 提供优雅关闭接口shutdown()

架构简化特点:

• 单连接管理: 不需要像RpcClient的连接池管理，直连固定主题服务端
• 纯回调驱动: 主题消息处理天然是回调驱动的，无需多种调用模式
• 无服务发现: 直连固定的主题服务端，无需动态发现机制

---

架构总结

三层架构优势

• 抽象层: 稳定的基础设施和统一接口定义
• 具象层: 专业分工的模块化功能实现
• 业务层: 完整解决方案的用户友好接口

复合架构设计价值

• 身份切换: 同一端点在不同场景下展现不同网络角色
• 功能正交: 服务器和客户端功能独立，可独立配置使用
• 架构弹性: 支持从简单模式到复杂模式的平滑升级

核心技术特性

1. 类型安全: 编译时类型检查 + 运行时类型验证
2. 异步转同步: Promise/Future模式支持多种调用方式
3. 服务治理: 完整的分布式服务注册、发现、上线、下线机制
4. 负载均衡: 客户端侧轮转负载均衡，支持算法扩展
5. 实时通知: 服务状态变化的主动推送机制
6. 连接池管理: 动态连接创建、复用、清理机制
7. 模式灵活: 支持分布式模式和简单模式的灵活切换
8. 并发安全: 全面的线程安全保护
9. 发布-订阅: 完整的主题消息系统，支持实时消息推送和订阅管理
10. 多功能集成: 同时支持RPC调用、服务治理、消息订阅等多种分布式功能

设计模式应用

1. 类型擦除模式 (Type Erasure)

设计思路: 消息分发器需要处理多种不同类型的消息(RpcRequest、TopicRequest、ServiceRequest等)，每种消息对应不同的处理函数。通过基类CallBack统一接口，模板子类CallBackT包装具体类型的处理器，实现异构类型在同一容器中的存储和统一调用。
体现位置: dispatcher.hpp的三层架构设计
解决问题: 异构类型的同构存储，避免为每种消息类型单独设计存储容器

2. 工厂模式 (Factory Pattern)

设计思路: 框架中需要创建多种类型的对象(消息对象、网络对象等)，且这些对象都有继承关系。工厂模式根据类型参数自动创建对应的具体类型对象，返回基类指针，支持多态使用。
体现位置: MessageFactory创建各种消息对象，ServerFactory/ClientFactory创建网络组件
解决问题: 对象创建的统一管理，支持多态对象的类型安全创建

3. 建造者模式 (Builder Pattern)

设计思路: 服务描述对象ServiceDescribe包含方法名、回调函数、参数列表、返回类型等多个字段，直接用构造函数会导致参数过多且容易出错。建造者模式将复杂对象的构建过程分解为多个简单步骤，每个步骤设置一部分属性。
体现位置: rpc_router.hpp的SDescribeBuilder类
解决问题: 复杂对象的分步构建，提高代码可读性和参数设置的清晰度

4. 策略模式 (Strategy Pattern)

设计思路: 在多种算法可选的场景中，将算法的选择和使用分离。RPC调用有三种不同的处理策略(同步、异步、回调)，用户可以根据业务需求选择；负载均衡也可以有多种算法(轮转、随机、权重等)，算法集中在一个方法中便于替换。
体现位置: rpc_caller.hpp的三种调用方式重载，rpc_registry.hpp的MethodHost::chooseHost方法
解决问题: 算法与使用场景解耦，支持算法的灵活切换和扩展

5. 发布-订阅模式 (Publish-Subscribe Pattern)

设计思路: 消息的发布者和订阅者需要解耦，发布者不需要知道有哪些订阅者，订阅者也不需要知道消息从哪里来。通过主题作为中介，发布者向主题发布消息，订阅者从主题订阅消息，实现一对多的消息分发。
体现位置: server/rpc_topic.hpp的Topic类维护订阅者列表并推送消息，client/rpc_topic.hpp的TopicManager管理订阅回调
解决问题: 发布者和订阅者的解耦，支持动态的订阅关系和实时消息推送

这个框架实现了一个完整的分布式通信中间件系统，集成了RPC远程调用、服务注册发现、主题发布订阅三大核心功能，支持多种调用模式、负载均衡、故障容错、实时消息推送等企业级特性。