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 | 存储用户状态、连接数信息,快速查询 | 超市排队系统,实时统计等待人数 |
四、总结和思路重点
- 多服务器部署:将系统分别部署多个ChatServer,避免单点失效,提升性能
- 动态负载均衡:请求到达GateServer,实时通过StatusServer匹配负载最小的Server,确保公平分配
- grpc端对端通信:多Server可以直接交互,保证消息转发效率
- 连接数管理:实时监控每个Server的连接情况,依据连接数来做负载调度
- 高效通信:利用grpc连接池,减少连接创建/销毁的开销
五、建议理解路径
- 把整体流程图记住:用户-门面-负载调度-聊天处理(跨Server)
- 重点理解