llfc项目分布式服务笔记

一、系统整体架构流程图（简明版）

复制代码

+---------------+             +------------------+          +----------------+
|  客户端 (Client) |--------->|   GateServer    |----------|  StatusServer  |<--+
+---------------+             +------------------+          +----------------+   ||                                  |         |连接状态、用户登录、客户端请求                     |  管理所有chatserver的连接数|                                  |+----------------+       |                                  ||     chatserver1   |-----|                                  |+----------------+       |                                  || 连接用户数管理     |<-------------------------------------+| grpc端点处理       |+------------------+|   |                               TCP服务监听  |   |  grpc通信  (端对端聊天、好友请求...)|   |                               +--------+  +---------+| chatserver2  |  | chatserverN |（未来可扩展多台）+--------------+  +--------------+

客户端（用户手机/网页）发起请求（登录、聊天消息等）
GateServer：作为“门面”，收发客户端请求。它负责：
- 用户登录转发到特定的chatserver
- 获取聊天内容
- 获取负载最小的chatserver进行分配（通过StatusServer）
StatusServer：监控所有chatserver的连接数，做负载均衡决策
多个ChatServer：实际处理用户的聊天逻辑
Grpc端点通信：ChatServer之间通过grpc实现端对端通信
连接池（ChatConPool）：优化grpc连接管理，避免频繁建立连接

二、详细逐步讲解（用比喻辅助）

1. 系统的基本目标

分布式部署：多个ChatServer共享压力
负载平衡：避免某台ChatServer超载
端对端通信：确保不同ChatServer可以直接互传消息
状态监控：动态获取每台Server的连接数，确保由负载最小的Server处理用户请求

2. 核心技术点及其作用

a. 多个ChatServer

就像超市里有多收银台，用户随机排队，但我们想让“服务快”的收银台快点帮用户结账。
每个ChatServer都有自己的连接数（“排队人数”）

b. GateServer（门面）

就像路口柜台，负责迎接客户（用户）
核心职责：
- 让用户登录后，告知它们“去哪台聊天服务器”
- 通过调用StatusServer查找连接最少的ChatServer
- 转发后续聊天请求到对应的ChatServer

c. StatusServer（负载调度）

管理所有ChatServer的连接数（“排队人数”）
动态统计，做负载最小的Server的选择
作用类似：超市每个收银台可以实时看到等待人数，然后引导客户去排队少的柜台

d. grpc通信

grpc：一种高效的远程通信协议，像快递包裹一样，快速、可靠地传递信息
通过grpc，ChatServer之间端对端可以直接调用，相当于两个超市的收银员可以直接交换信息，不需要经过中转站

e. 连接池（ChatConPool）

连接grpc的“桥梁”，如超市里备用的快速通道
避免每次通信都重新建连接，节省资源，提高效率

3. 工作流程（用户请求全流程）

假设用户要登录，系统是如何实现的？

用户发起登录请求（输入账号密码）
GateServer收到请求
- 通过调用StatusServer查询负载信息, 发现“ChatServer A”连接数最少
GateServer把用户登录请求（ID、Token等信息）转发到“ChatServer A”
ChatServer A确认用户信息后，返回登录成功
GateServer将用户ID绑定到会话中，存入Redis（或者内存）
用户正式登录成功（连接完毕）

之后用户发消息：

用户消息发到GateServer
GateServer识别到用户已登录
直接将消息转发到对应的ChatServer
聊天内容由目标ChatServer处理

负载均衡（动态匹配）

每次用户登录或请求，GateServer会实时调用StatusServer，#找到连接数最少的ChatServer
这样确保每个服务都不会过载，从而保证系统平稳运行

4. 跨Server通信（端对端grpc）

由于多个ChatServer都通过grpc连接，彼此可以调用服务
这样可以实现：
- 跨Server转发消息（比如：A和B两个Server的用户聊天）
- 其他交互（好友关系校验、同步消息等）

5. 用户连接数管理

每个ChatServer：启动后，向Redis设置自己的连接数（初始为0）
每当用户连接/断开：更新连接数
- 连接：增加
- 断开：减少
StatusServer：实时读取所有Server的连接数，做出负载匹配

三、各个组件详细作用介绍

组件	作用	作用比喻
GateServer	客户端入口，负责请求转发、负载均衡	超市门口的工作人员，迎接客户
StatusServer	监控每个ChatServer连接数，提供负载分配依据	超市中监控排队人数的管理员
ChatServer	具体处理聊天逻辑，存储好友关系、聊天历史等	超市的收银台，客户排队等候
grpc通信	各Service端点间可靠、快速的网络通讯	快递车，直接送货到不同超市的货架
连接池（ChatConPool）	管理grpc连接，避免频繁创建，提升效率	超市备用通道，快速通达收银台
Redis	存储用户状态、连接数信息，快速查询	超市排队系统，实时统计等待人数