前言
承接上一节的内容，我们继续深入服务端的设计。为了支撑 RPC 调用、服务注册发现以及消息发布订阅这三大核心功能，我们需要对服务端进行合理的模块拆分。
服务端架构设计
1. 功能需求
在着手具体代码之前，先明确服务端需要对外提供的能力：
- 基于网络通信接收客户端请求，提供 RPC 服务
- 基于网络通信接收客户端请求，提供服务注册与发现，上线及下线通知
- 基于网络通信接收客户端请求，提供主题操作（创建/删除/订阅/取消）及消息发布
明确了这些需求后，我们可以将系统拆解为以下模块，确保职责单一且易于维护。
2. 模块划分
基于上述功能，服务端可划分为以下几个核心模块：
- Network：网络通信模块，负责底层 IO 处理
- Protocol：应用层通信协议模块，负责数据解析
- Dispatcher：消息分发处理模块，负责路由转发
- RpcRouter：远端调用路由功能模块，处理 RPC 逻辑
- Publish-Subscriber：发布订阅模块，管理 Topic 和消息队列
- Registry-Discovery：服务注册/发现/上线/下线功能模块
- Server：整合以上模块的主入口
3. Network 模块
该模块是系统的基石，负责底层的网络通信功能。虽然这是一个庞大且复杂的模块，但考虑到项目重点在于 RPC 业务逻辑的实现，我们直接复用业界成熟的 Muduo 库（陈硕开源）来搭建。这样既能保证高性能，又能减少重复造轮子的风险。
4. 协议层设计
有了 Network 模块，双方即可建立 TCP 连接。但由于 TCP 是流式协议，没有边界概念，数据传输时极易出现粘包问题。因此，必须设计一个应用层通信协议模块：解析数据，解决粘包问题，确保能获取到一条完整的消息。
在 Muduo 的使用中，我们需要设置 onMessage 回调函数来处理收到的原始数据。Protocol 模块的核心任务就是在这个回调中实现协议解析。针对粘包问题，通常有三种处理方式：特殊字符间隔、定长、LV 格式（Length-Value）。在实际开发中，我们会根据业务场景选择最合适的方案，确保消息的完整性与解析效率。
