【即时通讯系统】项目框架与微服务拆分设计

项目的核心功能

一、用户账户管理

1. 用户注册：允许用户通过设置用户名（昵称）和密码创建新账户。

2. 用户登录：已注册用户可通过用户名和密码进行登录。

3. 短信验证码获取：在使用手机号注册或登录时，用户可请求获取短信验证码。

4. 手机号注册：用户通过输入手机号及对应的短信验证码完成账户注册。

5. 手机号登录：用户通过输入手机号及短信验证码直接登录账户。

6. 用户信息获取：登录后，用户可查看并展示个人资料信息。

7. 头像修改：允许用户上传并设置个人头像。

8. 昵称修改：支持用户更改个人昵称。

9. 签名修改：允许用户编辑并更新个人签名。

10. 手机号修改：用户可更换已绑定的手机号。

二、好友与社交管理

1. 好友列表获取：登录成功后，系统自动加载并展示用户的好友列表。

2. 申请好友：用户可通过搜索其他用户并发送好友申请。

3. 待处理申请获取：登录后自动获取离线期间收到的好友申请，供用户处理。

4. 好友申请处理：用户可对收到的好友申请执行同意或拒绝操作。

5. 删除好友：允许用户从好友列表中移除指定好友。

6. 用户搜索：提供基于用户名或ID的用户搜索功能，便于发起好友申请。

三、聊天与会话管理

1. 聊天会话列表获取：登录后获取用户参与的所有聊天会话（单聊/群聊），包括历史消息与对方信息。

2. 多人聊天会话创建：支持用户手动创建多人聊天会话（单聊会话在双方成为好友时自动生成）。

3. 聊天成员列表获取：在多人聊天会话中，可查看当前群组成员信息。

4. 发送聊天消息：在聊天界面输入内容并发送，将消息传递至服务器及对应接收方。

5. 获取历史消息：

   • a. 获取最近N条消息：用于进入聊天界面时加载最近的聊天记录。

   • b. 获取指定时间段消息：支持按时间范围查询历史消息。

6. 消息搜索：允许用户通过关键词在聊天记录中进行全文检索。

四、文件与媒体管理

1. 文件上传：

   • a. 单个文件上传：主要用于服务端接收文件消息后，将其转发至文件存储服务。

   • b. 多个文件上传：用于服务端批量接收文件消息并进行存储处理。

2. 文件下载：

   • a. 单个文件下载：用于客户端获取头像、图片、语音或文件消息中的媒体数据。

   • b. 多个文件下载：支持服务端批量获取用户头像，或客户端批量下载文件。

3. 语音消息转文字：提供客户端功能，将语音消息转换为文字内容。

---

五、后台服务与数据管理

除上述客户端交互功能外，系统还包含以下后端支撑功能：

1. 消息存储：持久化保存文本消息，支持消息搜索与离线消息缓存。

2. 文件存储：集中管理用户头像、消息附件（图片、语音、文件等）的存储与访问。

3. 数据管理：对用户信息、好友关系、会话数据等结构化数据进行存储、查询与维护。

一.微服务框架

1.1.什么是微服务

微服务 是一种软件架构风格。它将一个大型的、复杂的单体应用程序，按照业务功能 或领域 ，拆分成一组小型 、独立 、自治的服务。

• 微：强调的是服务的粒度，即每个服务的职责范围小、功能集中。

• 服务：强调的是每个拆分后的单元都是一个独立的、通过网络接口（通常是HTTP API或RPC）对外提供能力的进程。

核心思想：与单体架构的对比

要理解微服务，最简单的方式是看它解决了什么问题，即对比传统的单体架构。

特性	单体架构	微服务架构
应用结构	一个巨大的、包含所有功能的代码库和进程。	多个小的、独立的服务进程，每个进程负责一个特定的业务功能（如用户管理、订单处理）。
数据库	通常使用一个集中的、共享的数据库。	每个服务拥有自己独立的数据库或数据存储，数据不直接共享。
技术栈	整个项目通常使用统一的技术栈（如Java+Spring+MySQL）。	每个服务可以根据自身需求，选择最适合的技术栈（如用户服务用Python，订单服务用Java）。
部署	牵一发而动全身。即使只修改一小处代码，也需要重新构建和部署整个庞大的应用。	独立部署。可以单独修改、测试和部署某一个服务，不影响其他服务。
扩展性	只能通过复制整个应用（水平扩展）来应对高负载，浪费资源。	细粒度扩展。可以对负载高的特定服务（如图片处理服务）进行单独扩展，无需扩展整个系统。
团队协作	所有开发人员在一个大代码库上工作，沟通和协调成本高，容易冲突。	团队可以围绕服务来组织（"双披萨团队"），每个小团队负责一个或几个服务的全生命周期，权责清晰。

微服务架构的关键特征

1. 服务拆分（核心） ：拆分是手段，不是目的。目标是实现高内聚、低耦合。高内聚指一个服务内部的元素联系紧密；低耦合指服务之间依赖和影响最小。通常按业务领域（如电商中的用户、商品、订单、库存）来拆分。

2. 独立性与自治：

   • 独立开发：每个服务有自己的代码仓库，团队可独立决定开发节奏。

   • 独立部署：这是最重要的特性之一。意味着你可以随时发布某个服务的更新，而无需协调整个系统停机。

   • 独立扩展：见上表。

   • 独立技术选型 ：每个服务可以根据自身需求，选择最适合的技术栈（如用户服务用Python，订单服务用Java）。

3. 去中心化治理与数据管理：

   • 治理：没有强制统一的技术标准，鼓励使用最合适的工具。通常会建立一些公司级的指导规范，而非硬性规定。

   • 数据 ：每个服务管理自己的私有数据库，并通过API 暴露数据操作。**其他服务不能直接访问其数据库表。**这确保了服务的边界清晰和数据封装。

4. 服务间通信：

   • 服务是独立的进程，可能分布在不同的机器上，因此必须通过网络进行通信。

   • 主要方式有两种：

     • 同步通信：如HTTP RESTful API、gRPC。调用方会等待响应。

     • 异步通信：如消息队列（RabbitMQ, Kafka）。调用方发出消息后不等待，由消费者服务异步处理。这能提高系统解耦性和抗压能力。

5. 支撑性基础设施（运维复杂度所在）：

   • 服务发现：服务实例的IP和端口是动态变化的（例如在容器云中）。需要一个中心化的注册中心（如Nacos, Eureka, Consul）来让服务能找到彼此。

   • API网关：系统的统一入口。它负责路由客户端请求到后端服务、聚合结果、进行认证、限流、监控等。对内隐藏了微服务的复杂性。

   • 配置中心：统一管理所有服务的配置信息，实现配置的动态更新，无需重启服务。

   • 容错机制 ：网络调用一定会失败。需要引入断路器（如Hystrix, Sentinel）等模式，防止一个服务的故障引发整个系统雪崩。

   • 监控与日志 ：问题排查变得复杂，因为一次请求可能流经多个服务。需要分布式链路追踪（如Zipkin, SkyWalking）来追踪整个请求路径，并集中收集日志和指标。

总结：微服务是什么？

微服务是一种通过将大型应用拆分为多个互相协作的小型服务，以追求 独立性**、** 敏捷性**、** 可扩展性和 韧性的软件架构方法。

它的本质是：将系统复杂性从应用代码内部（混乱的模块依赖），转移到了服务之间的协同和运维基础设施上。

给初学者的核心提示：

• 优势：微服务带来了开发敏捷、技术自由、弹性伸缩、局部故障隔离等巨大好处。

• 代价：它引入了分布式系统的固有复杂性（网络延迟、数据一致性、调试困难）和对强大运维基础设施（部署、监控、发现）的依赖。

• 原则 ：不要为了拆而拆。对于初创项目或小型团队，单体架构往往是更简单高效的选择。当单体应用变得过于庞大、团队协作效率低下、需要不同部分独立伸缩时，才应考虑向微服务演进。

1.2.聊天室子服务拆分设计

基于微服务的思想，以及聊天室项目的业务功能，将聊天室项目进行服务拆分为以下 几个子服务：

1.2.1.网关服务

由于我们采用的是微服务架构，那么会有多个提供服务的进程，那么我们客户端怎么知道要去哪个服务进程呢？

这个时候，我们就引入了网关。

网关服务是微服务架构中的核心组件，作为所有客户端请求的唯一入口。

它的核心价值在于统一处理所有与外部交互的公共关注点，使内部的业务微服务能专注于业务逻辑本身。

具体作用如下：

1. 统一入口与路由分发

网关是所有客户端请求（无论是HTTP还是WebSocket连接）的唯一访问点。 它根据请求的路径、方法等信息，像交通指挥中心一样，将请求准确分发到对应的后端业务微服务（如用户服务、订单服务、聊天服务）。客户端无需知道内部有几十个还是上百个微服务，也无需知道它们的地址，只需与网关通信。

网关本身不提供服务，它只是负责将请求分发到对应的独立的微服务程序里面，让微服务程序去提供服务。

网关负责和客户端直接进行通信交互。

2. 集中式认证与鉴权（会话ID机制）

• 机制 ：网关会拦截每一个到达的请求，检查其是否携带了有效的登录会话ID（通常在Cookie或Header中）。

• 判定 ：如果请求包含有效会话ID，网关会识别出用户身份，并放行请求至下游服务；如果请求不包含或会话ID无效，网关会直接拦截，并仅允许访问登录、注册等白名单接口。

• 优势 ：这种设计意味着每个业务微服务自身无需再重复实现身份验证逻辑，它们从网关收到的请求都已是"已认证"的，从而保证了安全策略的一致性，并简化了业务服务的开发。

3. 流量过滤与安全防护

网关是系统的第一道安全防线，可以进行多项防护：

• 限流：防止恶意刷接口或突发流量打垮系统。例如，限制同一个IP地址或用户ID在1分钟内只能调用"获取验证码"接口3次。

• 黑/白名单：直接在网关层屏蔽恶意IP地址。

• 基础校验：对请求的格式、大小进行初步检查，拦截明显异常的请求。

4. 负载均衡

当某个业务微服务（例如"用户服务"）有多个运行实例时，网关可以在将这些实例间智能分配请求，将流量均匀分摊，从而提高系统的处理能力和高可用性。

5. 统一监控与日志收集

由于所有流量都经过网关，这里是收集系统关键指标的黄金位置。网关可以统一记录所有请求的访问日志（谁、在什么时候、访问了什么、响应状态如何），便于进行故障排查、性能分析和数据审计。

6. 降低微服务复杂性

通过将上述的横切关注点（认证、鉴权、路由、限流、日志等）集中到网关层处理，使得内部的业务微服务变得非常"纯粹"，它们只需关心自己的业务逻辑和数据，从而极大降低了整个微服务系统的复杂度和开发维护成本。

7. 客户端与后端解耦

网关将内部复杂的微服务架构细节对客户端完全隐藏。后端服务可以独立地进行升级、拆分或合并，只要网关的路由规则随之调整，客户端就完全感知不到这些变化，提高了系统的灵活性和可维护性。

8.多协议支持：适应不同业务场景

为满足项目中多样化的通信需求，网关向客户端提供了两种主要的通信协议支持，以适应不同的业务交互模式：

1. HTTP通信（请求-响应模式）

   本项目的大部分业务交互基于经典的请求-响应模式。为追求设计的简洁性与良好的可扩展性，我们采用HTTP/REST协议作为实现基础业务功能的主要通信协议。客户端所有的常规功能请求，如信息查询、数据提交、状态变更等，均通过HTTP接口发起，由网关路由至相应的业务微服务进行处理。

2. WebSocket通信（全双工长连接推送）

   在涉及即时交互（如聊天室）的业务场景中，系统不仅需要处理客户端的主动请求，还具备向客户端主动、实时推送消息的需求。由于HTTP协议本身不支持服务端主动推送，我们引入了WebSocket协议来建立持久化的长连接。通过此连接，服务端可将各类实时事件主动推送给在线客户端，典型应用包括：

   • 收到新好友申请的通知

   • 好友申请被通过或拒绝的结果通知

   • 被好友删除的告知通知

   • 新聊天会话建立的通知

   • 实时聊天新消息的推送

有了HTTP协议为什么还需要WebSocket协议？

1. HTTP协议的本质：请求-响应的短连接对话

您说得完全正确。HTTP协议就像一次单向问答：

• 客户端发起提问（请求） → 服务端给出回答（响应） → 对话结束，连接关闭。

• 在这种模式下，服务端永远是"被动应答者"。它无法主动发起一个新话题（推送消息）给客户端，必须等客户端来问。

• 这非常适用于浏览网页、提交表单等传统Web交互。

2. 实时应用的挑战与HTTP的"妥协方案"

当我们的应用需要服务端主动推送（如聊天消息、实时通知、股票行情、协同编辑）时，HTTP的短板就暴露了。为了模拟"实时"，历史上出现过几种基于HTTP的变通方案，但都有明显缺陷：

• 短轮询（Polling）：客户端每隔几秒就问一次："有我的新消息吗？" 大部分时间回答是"没有"，造成大量无意义的请求和资源浪费，实时性差。

• 长轮询（Long-Polling）：客户端问："有消息吗？" 服务端如果没有消息，就"hold住"不立刻回答，直到有消息或超时才响应。客户端收到响应后立即再发起下一次询问。这比短轮询实时性好，但仍需要反复建立连接，服务端保持大量挂起请求，压力大。

核心问题：这些方案都是在用"不断提问"来模拟"被主动告知"，本质低效且笨拙。

3. WebSocket协议：真正的全双工长连接通道

WebSocket协议就是为了解决上述问题而生。它在初次建立连接时使用HTTP（即"握手"），握手成功后，协议便从HTTP升级为WebSocket。

这就像将一次性的"电话问答"升级为一条始终在线、双向畅通的电话线：

• 一次握手，持久连接：建立连接后，在不断线的情况下，连接会一直保持。

• 双向主动通信 ：服务端和客户端在任何时刻都可以主动向对方发送数据，没有请求-响应的主从关系。

• 高效轻量：数据传输使用专门的帧格式，头部开销远小于HTTP，特别适合高频、小数据量的实时交互。

服务注册与服务发现

大家仔细看看这个

这个玩意是干啥用的？

在微服务架构中，服务实例（即运行着某个微服务程序的主机或容器）是动态变化的。例如，当"订单服务"的负载过高时，我们通常会启动多个新的订单服务实例来进行水平扩展，以实现负载分担。

此时，一个核心问题随之产生：网关或其他需要调用"订单服务"的组件，如何才能实时地知道这些新实例的地址（IP和端口）呢？

这就需要引入 "服务注册与服务发现" 模块。它是微服务架构中动态协调各服务实例的"电话簿"与"实时导航系统"。

它的工作原理是一个持续循环的三步流程：

1. 服务注册

   当一个微服务实例启动后，它会主动向一个称为 "服务注册中心" 的中央组件上报自己的信息，包括：服务名称（如 order-service）、IP地址、端口号、健康状态等。这个过程就像新开业的店铺在工商局登记自己的地址和经营范围。

2. 服务发现

   当网关或其他服务（服务调用方）需要调用"订单服务"时，它不会在配置中写死某个实例的地址，而是向同一个 "服务注册中心" 查询："当前所有可用的、健康的 order-service 实例列表是什么？"。注册中心会返回最新的实例地址列表。这就像顾客通过地图APP搜索附近的餐馆，总能得到最新的营业门店列表。

3. 心跳与健康检查

   服务注册中心会持续通过"心跳"机制监控所有已注册的实例。如果一个实例因故障停止响应，注册中心会将其从可用列表中自动剔除 。同样，当新的实例启动并注册后，会立刻被加入列表。这确保了服务列表的实时性和准确性，调用方永远不会将请求发送到一个已宕机的实例上。

1.2.2.用户管理子服务

用户管理子服务是系统的核心基础服务之一，承担所有与用户主体相关的核心数据管理与业务逻辑。它负责用户全生命周期的管理，从注册、认证到信息维护，确保用户数据的唯一性、安全性与一致性。作为微服务架构中的独立单元，它封装了所有用户领域的功能，并通过清晰的API为网关及其他服务提供支持。

该服务需提供以下关键业务接口：

1. 用户注册（用户名方式）：用户通过输入唯一用户名（或昵称）及密码，完成账户注册。

2. 用户登录（用户名密码方式）：用户凭注册时的用户名与密码进行登录，验证身份凭证。

3. 短信验证码获取：为通过手机号注册或登录的流程，向指定手机号发送一次性短信验证码。

4. 手机号注册：用户输入手机号及收到的有效短信验证码，完成账户注册。

5. 手机号登录：用户通过手机号及有效的短信验证码完成快捷登录。

6. 用户信息获取：用户登录后，获取其完整的个人信息（如昵称、头像URL、签名等），用于前端展示。

7. 头像修改：允许用户上传并设置个人头像图片。

8. 昵称修改：允许用户修改其显示昵称。

9. 签名修改：允许用户设置或修改个人签名/简介。

10. 绑定手机号修改：允许已登录用户更换其绑定的手机号码。

1.2.3.好友管理子服务

好友管理子服务是社交类系统的核心组件之一，负责管理与"用户关系"及"聊天会话"相关的核心数据与逻辑。

它将好友生命周期管理（从搜索、申请、同意到删除）以及聊天会话的元数据管理（创建、列表获取）封装成一个独立的服务，确保关系数据的一致性，并为即时通讯、社交互动等上层功能提供基础支持。

1. 获取好友列表

   用户登录成功后，获取其全部好友的概要信息列表，用于前端展示。该接口通常需要关联用户管理服务，以获取好友的最新头像、昵称及在线状态。

2. 删除好友

   解除与指定用户的好友关系。此操作将双向删除关系记录，并可能触发关联聊天会话的清理或状态更新。

3. 搜索用户 根据昵称或ID等关键词搜索平台用户。为提升体验，结果通常会过滤掉当前用户自身及已有好友关系的用户。

4. 申请添加好友

   向目标用户发送好友申请。系统会校验双方关系状态，避免重复申请。申请创建后，需实时通知对方用户。

5. 获取待处理申请列表

   获取当前用户收到的所有待处理的好友申请，用于前台集中展示与处理。

6. 处理好友申请

   对申请执行"同意"或"拒绝"操作。同意后将建立双向好友关系，并自动创建一个对应的单人聊天会话；无论同意或拒绝，均需将处理结果实时通知给申请发起方。

7. 获取聊天会话列表用户登录后，获取其参与的所有单聊和群聊会话的元数据列表，包括会话名称、头像、最后活动时间等。

8. 创建多人聊天会话

   用户可选取多名好友，创建一个新的多人聊天群组。此操作将建立会话实体，并初始化所有选中成员的会话关联关系。

9. 获取聊天成员列表

   查询指定聊天会话（尤其是多人群聊）的所有成员ID列表。为完整展示成员信息，前端通常需根据此列表向用户管理服务请求获取详细的用户资料。

多人聊天会话

在后台系统中，所有聊天消息都需要被持久化保存，通常通过数据库中的消息存储表来实现。

每条消息都必须明确记录其来源与去向，即消息由谁发出、最终要送达给谁。

在单聊场景中，这种设计是可行的，因为每一条消息只涉及发送方和接收方两个明确的用户ID。

然而，在群聊场景中，同一消息需要送达给多个用户，如果仍在单条消息中记录所有接收者，则面临存储结构上的难题------一条消息难以合理承载多个用户ID，这样的设计既不灵活，也不符合数据库规范。

为此，我们引入了"聊天会话"这一中间概念。**每个会话在后台都有独立的元数据，其中记录了参与该会话的所有成员信息。**当一条群消息发送时，系统只需关联到对应的会话ID，即可通过会话成员表确定所有接收者，从而避免在单条消息中冗余存储多个用户ID。这样既保证了数据的规范化，也提升了系统的可扩展性与维护性。

1.2.4.文件管理子服务

文件管理子服务主要用于存储与管理用户头像及消息中的各类文件（如图片、语音、文档等），为系统提供稳定、高效的文件存取支持。

该服务需提供以下核心接口：

1. 文件上传

• 单文件上传

  适用于后台接收并存储单个文件的场景，例如处理用户上传的头像，或接收消息中的文件数据并转发至文件服务进行持久化存储。

• 多文件上传

  支持批量文件同时上传，主要用于后台处理包含多个文件的消息，提升文件存储效率与处理能力。

2. 文件下载

• 单文件下载

  可供后台获取用户头像文件，也可用于客户端下载消息中的文件、语音或图片等资源。

• 多文件下载

  支持批量获取文件，适用于后台批量导出用户头像（例如获取用户列表时附带头像），以及前端实现多文件同时下载功能。

1.2.5.消息管理子服务

消息管理子服务主要用于维护与存储消息的元信息，为上层应用提供规范的消息查询与检索能力。该服务主要提供以下两类核心接口：

1. 获取历史消息

• a. 获取最近N条消息：适用于用户登录后快速加载最新聊天记录的场景，例如点击联系人头像打开聊天框时，自动展示最近的对话内容。
• b. 获取指定时间段内的消息：支持用户根据时间范围查询历史消息，便于按时间线回溯或筛选特定时期的聊天记录。

2. 消息搜索

提供基于关键字的全文检索功能，用户可通过输入关键词快速定位包含该内容的聊天消息，提升信息查找效率。

1.2.6.消息转发子服务

注意：这个消息转发子服务并不是提供进行消息的转发功能，它实现是是获取一条消息应该发送给哪些用户的功能。

客户端是与网关进行直接连接的，网关收到客户端的一条消息，需要对消息进行转发，但是网关它自己不知道要转发给哪个用户，那么网关就来询问这个消息转发子服务，获取转发的用户列表。

1.2.7.语音转换子服务

语音转换子服务，用于调用语音识别SDK，进行语音识别，将语音转为文字后返回给 网关。

通过一个功能：语音消息的文字转换：客户端进行语音消息的文字转换。

二.项目所使用到的框架/库

本项目在开发过程中，依托一系列成熟、高效的开源与云服务框架，构建了稳定可靠的技术底座。以下为各核心组件及其在项目中的主要作用：

基础工具与框架

• gflags：用于解析命令行参数与配置文件，统一管理程序运行时的各项配置。

• gtest：提供单元测试支持，保障核心代码的可靠性与可维护性。

• spdlog：高性能日志库，用于输出结构化日志，便于系统监控和问题排查。

• cmake：作为项目构建工具，管理编译依赖，支持跨平台构建。

• docker：提供容器化部署能力，实现环境一致性与一键式服务发布。

网络通信与序列化

• protobuf：用于网络数据的序列化与反序列化，保障通信高效、结构清晰。

• brpc：作为RPC框架，支持高性能服务间调用，提升系统分布式协作能力。

• cpp-httplib：用于搭建轻量级HTTP服务器，处理部分 RESTful 接口请求。

• websocketpp：用于构建WebSocket服务器，支持实时双向通信。

数据存储与访问

• mysql：作为核心关系型数据库，存储用户、消息等业务结构化数据。

• ODB：作为ORM框架，简化数据库操作，实现对象与关系的映射。

• redis：用作高性能缓存与会话存储，管理用户登录状态及热点数据。

• elasticsearch：提供历史消息的全文检索与文档存储能力，支持快速查询。

中间件与分布式支持

• etcd：用于服务注册与发现，实现分布式环境下服务的动态管理。

• rabbitMQ：作为消息队列中间件，支持消息的异步转发与持久化消费。

第三方云服务集成

• 语音云平台（百度）：集成语音识别能力，实现语音消息转文字功能。

• 短信云平台（阿里云）：用于发送手机短信验证码，支持用户安全登录。

安装基础工具

此外，还有一些基础的工具，我们都是需要进行安装的，那么我直接给出这些基础工具的安装代码，大家没安装的自己去安装

# 更新软件包列表并安装项目基础开发工具套件
sudo apt-get update && sudo apt-get install -y \
    vim \               # 编辑器
    gcc g++ \          # C/C++编译器
    gdb \              # 调试器
    make cmake \       # 项目构建工具
    lrzsz \            # 文件传输工具(Zmodem协议)
    git                # 版本管理工具

至于上面那些工具的话，我们后面会出专门的文章来讲解它们的安装以及简单的使用教程。