微服务即时通讯系统——整体架构和组件(1)

微服务架构下的聊天室项目：从功能到架构的解析

在即时通讯领域，聊天室项目看似简单，实则涉及用户管理、消息传递、文件处理等多个复杂模块。随着用户规模增长，单体架构往往面临扩展性差、维护困难等问题。本文将详细介绍一个基于微服务架构的聊天室项目设计，解析其功能拆分、服务架构及核心组件的作用，带你了解如何用微服务思想构建高可用、可扩展的即时通讯系统。

在学习本项目之前建议先学习其核心组件与库，不需要太过深入，基础了解会使用即可，建议边学边写，实践往往更能促进进步。

学习组件流程在博主主页中已经写明，根据个人选择学习顺序。

gittee项目代码地址

一、项目核心功能概览

聊天室项目的核心是满足用户间的实时沟通需求，同时提供完善的用户管理和社交功能。整体功能可分为客户端交互功能和服务器内部功能两大类：

1. 客户端交互功能

涵盖用户从注册登录到消息沟通的全流程，主要包括：

• 用户认证：支持用户名 / 密码注册登录、手机号 + 验证码注册登录，以及短信验证码获取
• 个人信息管理：用户信息查询、头像 / 昵称 / 签名修改、手机号绑定修改
• 社交关系管理：好友列表查询、好友申请（发送 / 处理）、删除好友、用户搜索
• 聊天会话管理：单人 / 多人会话列表查询、多人会话创建、群成员列表查询
• 消息交互：发送消息（文本 / 文件 / 语音）、历史消息查询（最近 N 条 / 指定时间段）、消息关键字搜索
• 文件处理：单文件 / 多文件上传（头像、消息附件）、单文件 / 多文件下载
• 语音处理：语音消息转文字

2. 服务器内部功能

支撑客户端功能的底层能力，包括：

• 消息存储（文本消息、离线消息）
• 文件存储（头像、附件、语音）
• 用户 / 好友 / 会话数据的存储与管理

二、微服务架构设计：拆分原则与核心思想

微服务架构的核心是 “拆分” 与 “自治”，通过将复杂系统拆分为独立服务，实现灵活扩展和高效维护。本项目遵循以下设计思想：

1. 服务拆分：按业务领域划分服务，每个服务专注于单一功能模块
2. 独立部署：各服务可单独升级、扩容，不影响其他服务
3. 多样化技术栈：根据服务特性选择合适的语言和数据库（如消息服务侧重读写性能，用户服务侧重事务一致性）
4. 轻量通信：服务间通过 API（HTTP/REST、gRPC）通信，定义清晰的接口规范
5. 去中心化：各服务独立管理数据和开发流程，团队权责明确
6. 弹性容错：通过断路器、重试机制应对服务故障，保证系统稳定性
7. 自动化运维：结合 CI/CD、监控日志实现高效部署和问题排查

三、核心子服务解析：各司其职的 “功能单元”

基于业务功能和微服务思想，项目拆分为 7 个核心子服务，每个服务专注于特定领域，通过协作完成整体功能。

1. 网关服务：客户端的 “总入口”

核心作用：作为客户端与后端服务的中间层，统一接收请求、分发任务、处理通信协议，是系统的 “交通枢纽”。

关键功能：

• 请求分发：接收客户端请求，根据业务类型转发到对应子服务（如用户注册请求转发给用户管理服务）

• 用户鉴权：验证客户端的会话 ID（登录后生成），仅允许已登录用户访问非公开接口（如好友列表、发送消息）

• 协议适配

  ：同时支持两种通信协议：

  • HTTP 协议：处理客户端主动发起的请求（如注册、修改资料、获取历史消息）
  • Websocket 协议：维持长连接，实现服务器主动推送通知（如好友申请提醒、新消息通知、会话创建通知）

• 流量控制：过滤无效请求，保护后端服务免受恶意攻击

2. 用户管理子服务：用户数据的 “管理员”

核心作用：负责用户全生命周期管理，包括注册、登录、信息维护等，是系统的 “用户中心”。

关键功能：

• 处理用户名 / 手机号注册、登录逻辑，验证用户身份
• 管理短信验证码（对接阿里云短信平台，生成、校验验证码）
• 维护用户基础信息（昵称、头像、签名、绑定手机号），支持信息修改
• 提供用户信息查询接口（供其他服务调用，如好友列表展示用户资料）

数据特点：用户数据需强一致性（如登录状态、手机号唯一性），通常存储在 MySQL 中。

3. 好友管理子服务：社交关系的 “维护者”

核心作用：管理用户间的社交关系，包括好友列表、申请流程、会话创建等，是系统的 “社交中枢”。

关键功能：

• 好友关系维护：好友列表查询、删除好友
• 好友申请处理：发送申请、查询待处理申请、同意 / 拒绝申请
• 用户搜索：支持按昵称 / 手机号搜索用户（用于添加好友）
• 会话管理：查询聊天会话列表、创建多人会话、查询群成员列表
• 触发会话创建：单人会话在好友申请通过时自动创建

数据特点：好友关系、会话信息需高频读写，通常存储在 MySQL 中，配合缓存提升查询效率。

4. 消息管理子服务：消息数据的 “保管员”

核心作用：负责消息的存储、查询和搜索，是系统的 “消息仓库”。

关键功能：

• 存储文本消息元信息（内容、发送时间、发送者、会话 ID）
• 提供历史消息查询：支持按会话获取最近 N 条消息、指定时间段内消息
• 消息搜索：基于关键字检索历史消息（依赖 Elasticsearch 实现高效全文检索）
• 管理离线消息：用户未在线时，暂存消息供后续获取

技术选型：采用 Elasticsearch 存储消息，利用其分布式特性和全文检索能力，满足消息的高效查询和搜索需求。

5. 转发管理子服务：消息传递的 “调度员”

核心作用：负责消息的路由和分发，确保消息准确送达目标用户，是系统的 “消息路由器”。

关键功能：

• 确定消息接收者：根据会话 ID（单人 / 多人）解析目标用户列表
• 消息转发：将消息传递给网关服务，由网关通过 Websocket 推送给接收者
• 消息队列管理：将消息放入 RabbitMQ，供消息管理子服务（存储文本）和文件管理子服务（存储附件）消费
• 确保消息可靠性：通过消息队列的持久化机制，避免消息丢失

核心价值：解耦消息发送与存储流程，通过异步处理提升系统吞吐量。

6. 文件管理子服务：文件数据的 “存储柜”

核心作用：管理所有文件类数据（头像、图片、语音、附件）的上传与下载，是系统的 “文件中心”。

关键功能：

• 文件上传：接收单文件 / 多文件（如头像、消息附件），存储到文件系统或对象存储
• 文件下载：提供文件访问接口，支持单文件下载（如查看头像、下载附件）和批量下载（如批量获取用户头像）
• 文件元信息管理：记录文件路径、大小、类型等信息，关联用户和消息

技术特点：需考虑大文件处理、存储扩容和访问速度，通常结合分布式文件系统或云存储服务实现。

7. 语音转换子服务：语音消息的 “翻译官”

核心作用：将语音消息转换为文字，提升消息可读性，是系统的 “语音处理中心”。

关键功能：

• 接收客户端上传的语音文件
• 调用百度语音识别 SDK，将语音转为文字
• 返回转换结果给网关，最终同步到消息中（供接收方查看文字内容）

技术依赖：依赖第三方语音识别 API，需处理接口调用失败、识别超时等异常情况。

四、核心组件与技术栈：支撑系统运行的 “基础设施”（优先学习）

除子服务外，项目还依赖一系列工具和中间件，保障微服务架构的稳定运行：

• 服务注册与发现：Etcd用于记录各子服务的地址和状态，网关服务通过 Etcd 动态发现可用的服务实例，实现服务的动态扩缩容。
• 通信框架：brpc、protobufbrpc 提供高性能的 RPC 通信能力，服务间通过 protobuf 定义接口和数据结构，实现跨服务高效通信。
• 数据存储：
  • MySQL：存储用户信息、好友关系、会话信息等结构化数据（依赖 ODB 作为 ORM 框架简化数据库操作）
  • Redis：存储用户登录会话（会话 ID 与用户信息的映射），支持高频读写和过期自动清理
  • Elasticsearch：存储历史消息，支持高效的全文检索和按时间范围查询
  • RabbitMQ：作为消息队列，实现转发子服务与消息 / 文件服务的异步通信，削峰填谷并保证消息可靠传递
• 网络协议框架：
  • cpp-httplib：搭建轻量 HTTP 服务器，处理客户端的 HTTP 请求
  • websocketpp：实现 Websocket 长连接，支持服务器向客户端主动推送通知
• 运维与监控：
  • spdlog：轻量日志库，记录服务运行日志，用于问题排查
  • gtest：单元测试框架，保障服务功能正确性
  • gflags：解析运行参数和配置文件，方便服务部署时调整参数
  • Docker：容器化部署工具，实现服务的环境一致性和一键部署
  • CMake：项目构建工具，管理跨平台编译流程

五、总结：微服务架构的优势与设计启示

本聊天室项目通过微服务架构，将复杂业务拆分为 7 个核心子服务，配合完善的中间件和工具链，实现了：

1. 高扩展性：各服务可独立扩容（如消息服务压力大时单独增加实例）
2. 高可用性：单个服务故障不影响整体系统（如文件服务故障时，文本消息仍可发送）
3. 开发效率提升：团队可按服务分工，并行开发，接口定义清晰后互不干扰
4. 技术适配灵活：不同服务选择最适合的技术栈（如消息服务用 Elasticsearch，用户服务用 MySQL）