企业圈系统设计
1 | 根据需求,出一份符合规范的设计文档。 |
企业圈系统设计文档
一、引言
本设计文档描述了企业圈系统的整体架构设计、数据库设计、功能模块设计以及API接口设计。该系统旨在为企业内部员工提供类似微信朋友圈的社交功能,支持企业内容发布、点赞、评论等功能,并通过智能置顶算法提升优质内容的曝光度。
文档变更日志
*版本* | *变更日期* | *变更内容* | *变更人* |
---|---|---|---|
v1.0 | 2024-12-19 | 初始版本,包含系统架构、数据库设计、API设计 | 系统架构师 |
v1.1 | 2024-12-19 | 优化架构图为Mermaid格式,完善技术实现细节 | 系统架构师 |
二、项目概述
2.1 需求背景
随着企业数字化转型的推进,企业内部员工之间的信息交流和协作需求日益增长。传统的企业内部沟通方式往往缺乏互动性和即时性,难以满足现代企业的沟通需求。
本项目旨在构建一个企业级的内部社交平台,具体实现以下核心需求:
****核心功能需求****:
- ****内容管理****:企业用户可以发布或删除企业圈内容
- ****权限控制****:同企业成员互相可见,跨企业内容隔离
- ****智能置顶****:24小时内发布且点赞数超过10的内容中,点赞数前三的自动置顶
- ****互动功能****:支持企业圈内容评论,增强用户互动
****系统规模指标****:
- ****企业数量****:10,000家企业
- ****每日新增内容****:500,000条
- ****日活用户数****:5,000,000人
- ****峰值QPS预估****:~15,000 QPS(考虑高峰时段集中访问)
- ****存储预估****:每日新增约100GB数据(包含文本、图片、元数据等)
三、详细设计
3.1 系统架构设计
3.1.1 系统整体架构图
系统采用微服务架构,分为客户端层、网关层、应用服务层、数据存储层和基础设施层。通过水平分层和垂直拆分,确保系统的高可用性和可扩展性。
graph TB subgraph "客户端层" WebClient["Web客户端"] MobileApp["移动端APP"] ThirdParty["第三方应用"] end subgraph "网关层" Gateway["API网关
负载均衡
限流熔断"] end subgraph "应用服务层" AuthService["认证服务
- 用户登录注册
- JWT令牌管理
- 权限验证"] ContentService["内容服务
- 企业圈CRUD
- 动态Feed生成
- 置顶算法"] LikeService["点赞服务
- 点赞/取消
- 计数统计
- 热度计算"] CommentService["评论服务
- 评论CRUD
- 二级回复
- 内容审核"] end subgraph "数据存储层" MySQL["MySQL集群
- 主从分离
- 分库分表
- 读写分离"] Redis["Redis集群
- 缓存热点数据
- 计数器
- 分布式锁"] FileStorage["文件存储
- 图片存储
- CDN加速"] end subgraph "基础设施层" MQ["消息队列
- 异步处理
- 削峰填谷"] Monitor["监控告警
- 性能监控
- 业务监控"] Schedule["定时任务
- 置顶更新
- 数据同步"] end WebClient --> Gateway MobileApp --> Gateway ThirdParty --> Gateway Gateway --> AuthService Gateway --> ContentService Gateway --> LikeService Gateway --> CommentService AuthService --> MySQL AuthService --> Redis ContentService --> MySQL ContentService --> Redis ContentService --> FileStorage ContentService --> MQ LikeService --> MySQL LikeService --> Redis LikeService --> MQ CommentService --> MySQL CommentService --> Redis MQ --> Schedule Schedule --> ContentService Monitor --> AuthService Monitor --> ContentService Monitor --> LikeService Monitor --> CommentService
3.1.2 核心业务流程时序图
主要展示用户登录、内容发布、点赞等核心业务流程的交互时序。
sequenceDiagram participant Client as 客户端 participant Gateway as API网关 participant Auth as 认证服务 participant Content as 内容服务 participant Like as 点赞服务 participant MySQL as MySQL数据库 participant Redis as Redis缓存 Note over Client,Redis: 用户登录流程 Client->>Gateway: POST /api/v1/auth/login Gateway->>Auth: 转发登录请求 Auth->>MySQL: 验证用户凭证 MySQL-->>Auth: 返回用户信息 Auth->>Redis: 缓存用户会话 Auth-->>Gateway: 返回JWT令牌 Gateway-->>Client: 登录成功响应 Note over Client,Redis: 发布内容流程 Client->>Gateway: POST /api/v1/posts Gateway->>Auth: 验证JWT令牌 Auth-->>Gateway: 令牌有效 Gateway->>Content: 转发发布请求 Content->>MySQL: 插入内容记录 MySQL-->>Content: 插入成功 Content->>Redis: 更新Feed缓存 Content-->>Gateway: 发布成功 Gateway-->>Client: 返回成功响应 Note over Client,Redis: 点赞流程 Client->>Gateway: POST /api/v1/posts/{id}/like Gateway->>Auth: 验证权限 Auth-->>Gateway: 权限验证通过 Gateway->>Like: 处理点赞请求 Like->>Redis: 检查点赞状态 Redis-->>Like: 返回当前状态 Like->>MySQL: 更新点赞记录 Like->>Redis: 更新点赞计数 Like->>Content: 异步检查置顶条件 Like-->>Gateway: 点赞操作完成 Gateway-->>Client: 返回操作结果
3.1.3 智能置顶算法流程图
展示自动置顶机制的具体执行流程,确保24小时内高质量内容能够获得更多曝光。
flowchart TD A[定时任务启动
每小时执行] --> B[获取所有企业列表] B --> C{遍历每个企业} C --> D[查询24小时内
点赞数>10的内容] D --> E{是否有符合条件的内容?} E -->|否| F[清空当前置顶内容] E -->|是| G[按点赞数降序排序] G --> H[取前3名内容] H --> I[清空旧置顶状态] I --> J[设置新置顶内容] J --> K[更新is_pinned=1
设置pinned_at时间] K --> L[清理Redis置顶缓存] L --> M[预热新置顶内容到缓存] F --> N[继续下一个企业] M --> N N --> C C -->|所有企业处理完成| O[任务完成
等待下次执行] style A fill:#e1f5fe style O fill:#c8e6c9 style K fill:#fff3e0
3.2 数据库设计
3.2.1 数据库ER图
系统核心实体关系图,展示企业、用户、内容、点赞、评论之间的关联关系。
erDiagram enterprises { bigint id PK "企业ID" varchar name "企业名称" varchar code "企业代码" varchar logo "企业logo" tinyint status "状态" timestamp created_at "创建时间" timestamp updated_at "更新时间" } users { bigint id PK "用户ID" bigint enterprise_id FK "企业ID" varchar username "用户名" varchar email "邮箱" varchar nickname "昵称" varchar avatar "头像URL" varchar password_hash "密码哈希" tinyint status "状态" timestamp created_at "创建时间" timestamp updated_at "更新时间" } posts { bigint id PK "内容ID" bigint user_id FK "发布用户ID" bigint enterprise_id FK "企业ID" text content "内容文本" json images "图片URL列表" int like_count "点赞数" int comment_count "评论数" tinyint is_pinned "是否置顶" timestamp pinned_at "置顶时间" tinyint status "状态" timestamp created_at "创建时间" timestamp updated_at "更新时间" } likes { bigint id PK "点赞ID" bigint post_id FK "内容ID" bigint user_id FK "用户ID" timestamp created_at "点赞时间" } comments { bigint id PK "评论ID" bigint post_id FK "内容ID" bigint user_id FK "评论用户ID" bigint parent_id FK "父评论ID" text content "评论内容" tinyint status "状态" timestamp created_at "创建时间" timestamp updated_at "更新时间" } enterprises ||--o{ users : "包含" enterprises ||--o{ posts : "拥有" users ||--o{ posts : "发布" users ||--o{ likes : "点赞" users ||--o{ comments : "评论" posts ||--o{ likes : "被点赞" posts ||--o{ comments : "被评论" comments ||--o{ comments : "回复"
3.2.2 分库分表策略
****分表策略****:
- 按企业ID进行分表,每个企业的数据存储在独立的表中
- 分表规则:
posts_${enterprise_id % 100}
- 支持最大10,000个企业,平均每表100个企业
****索引优化策略****:
1 | -- 企业圈动态查询优化索引 |
3.2.3 企业表 (enterprises)
1 | CREATE TABLE `enterprises` ( |
3.2.4 用户表 (users)
1 | CREATE TABLE `users` ( |
3.2.5 企业圈内容表 (posts)
支持分表存储,按企业ID取模分布到不同表中,提升查询性能。
1 | -- 分表模板,实际会创建 posts_0 到 posts_99 共100个表 |
3.2.6 点赞表 (likes)
支持分表存储,与posts表采用相同的分片策略。
1 | -- 分表模板,与posts表保持一致的分片策略 |
3.2.7 评论表 (comments)
1 | -- 分表模板,与posts表保持一致的分片策略 |
3.2.8 数据库设计总结
****设计原则****:
- ****数据隔离****:通过enterprise_id实现严格的企业数据隔离
- ****水平扩展****:采用分表策略支持大规模数据存储
- ****查询优化****:针对核心查询场景设计复合索引
- ****数据完整性****:使用外键约束保证数据一致性
- ****软删除****:重要数据采用status字段实现软删除
****核心查询场景及优化****:
1 | -- 场景1:获取企业圈动态(置顶+普通内容) |
3.3 系统功能设计
3.3.1 用户认证与权限管理
****功能描述****:
- 用户注册:企业员工通过企业邀请码注册
- 用户登录:用户名/邮箱 + 密码登录,返回JWT令牌
- 权限验证:基于企业ID的数据隔离,确保跨企业数据安全
- 会话管理:JWT令牌有效期管理,支持令牌刷新
****技术实现方案****:
1 | type AuthService struct { |
3.3.2 企业圈内容管理
****功能描述****:
- 内容发布:支持文本、图片、视频、位置等多媒体内容
- 内容删除:用户只能删除自己发布的内容
- 内容编辑:支持发布后24小时内编辑
- 动态Feed:获取企业内容动态,置顶内容优先展示
****核心业务逻辑****:
1 | type ContentService struct { |
3.3.3 智能点赞系统
****功能描述****:
- 点赞/取消点赞:支持快速响应,防止重复点赞
- 实时计数:使用Redis实现高性能计数器
- 点赞列表:支持分页获取点赞用户列表
- 并发安全:使用分布式锁防止并发问题
****技术实现****:
1 | type LikeService struct { |
3.3.4 智能置顶算法系统
****功能描述****:
- 自动检测:24小时内发布且点赞数超过10的内容
- 智能排序:点赞数前三的内容自动置顶
- 动态更新:每小时重新计算置顶内容
- 公平机制:相同点赞数的内容按发布时间排序
****核心算法实现****:
1 | type PinnedService struct { |
3.3.5 评论系统
****功能描述****:
- 顶级评论:直接对内容进行评论
- 回复评论:支持二级回复(回复具体的评论)
- 评论删除:评论者和内容发布者均可删除
- 评论点赞:支持对评论进行点赞
****技术实现****:
1 | type CommentService struct { |
3.3.6 缓存策略设计
****Redis数据结构设计****:
1 | // 点赞计数器 |
3.4 接口设计
3.4.1 用户认证接口
用户注册
1 | POST /api/v1/auth/register |
****响应示例****:
1 | { |
用户登录
1 | POST /api/v1/auth/login |
****响应示例****:
1 | { |
刷新令牌
1 | POST /api/v1/auth/refresh |
用户登出
1 | POST /api/v1/auth/logout |
3.4.2 企业圈内容接口
发布内容
1 | POST /api/v1/posts |
****响应示例****:
1 | { |
获取企业圈动态
1 | GET /api/v1/posts?page=1&size=20&sort=created_at |
****查询参数****:
page
: 页码,默认1size
: 每页数量,默认20,最大100sort
: 排序方式,可选值:created_at(时间)、like_count(点赞数)
****响应示例****:
1 | { |
获取单个内容详情
1 | GET /api/v1/posts/{post_id} |
编辑内容
1 | PUT /api/v1/posts/{post_id} |
****业务规则****:
- 只能编辑自己发布的内容
- 发布后24小时内可编辑
- 编辑后重置点赞和评论计数
删除内容
1 | DELETE /api/v1/posts/{post_id} |
****响应示例****:
1 | { |
3.4.3 点赞相关接口
点赞/取消点赞
1 | POST /api/v1/posts/{post_id}/like |
****路径参数****:
post_id
: 内容ID,必填
****响应示例****:
1 | { |
获取点赞列表
1 | GET /api/v1/posts/{post_id}/likes?page=1&size=20 |
****查询参数****:
page
: 页码,默认1size
: 每页数量,默认20,最大50
****响应示例****:
1 | { |
批量检查点赞状态
1 | POST /api/v1/posts/likes/batch-check |
****响应示例****:
1 | { |
3.4.4 评论相关接口
发表评论
1 | POST /api/v1/posts/{post_id}/comments |
****响应示例****:
1 | { |
获取评论列表
1 | GET /api/v1/posts/{post_id}/comments?page=1&size=20&sort=created_at |
****查询参数****:
page
: 页码,默认1size
: 每页数量,默认20,最大100sort
: 排序方式,可选值:created_at(时间)、like_count(点赞数)
****响应示例****:
1 | { |
回复评论
1 | POST /api/v1/comments/{comment_id}/replies |
评论点赞
1 | POST /api/v1/comments/{comment_id}/like |
删除评论
1 | DELETE /api/v1/comments/{comment_id} |
****响应示例****:
1 | { |
3.4.5 文件上传接口
图片上传
1 | POST /api/v1/upload/images |
****响应示例****:
1 | { |
视频上传
1 | POST /api/v1/upload/video |
3.4.6 统计接口
获取企业圈统计数据
1 | GET /api/v1/statistics/enterprise |
****响应示例****:
1 | { |
获取个人统计数据
1 | GET /api/v1/statistics/personal |
3.4.7 通用响应格式
所有API接口均采用统一的响应格式:
****成功响应****:
1 | { |
****错误响应****:
1 | { |
****常见错误码****:
- 200: 请求成功
- 400: 请求参数错误
- 401: 未授权(token无效或过期)
- 403: 无权限访问(跨企业访问等)
- 404: 资源不存在
- 409: 资源冲突(重复点赞等)
- 422: 业务逻辑错误(超出编辑时限等)
- 429: 请求频率限制
- 500: 服务器内部错误
- 503: 服务暂不可用
****错误响应详细示例****:
1 | { |
3.5 部署架构设计
3.5.1 容器化部署
****Docker镜像构建****:
1 | # Dockerfile |
****Kubernetes部署配置****:
1 | # deployment.yaml |
3.5.2 监控部署
****Prometheus监控配置****:
1 | # prometheus.yml |
四、技术实现要点
4.1 高并发优化策略
4.1.1 分层缓存体系
****L1缓存 - 本地缓存****:
1 | // 使用sync.Map实现高性能本地缓存 |
****L2缓存 - Redis分布式缓存****:
1 | // Redis缓存策略配置 |
4.1.2 数据库集群架构
****MySQL读写分离配置****:
1 | # 数据库配置 |
****分表路由策略****:
1 | type ShardingRouter struct { |
4.1.3 异步处理架构
****消息队列设计****:
1 | // 消息队列主题设计 |
4.1.4 连接池优化
****数据库连接池配置****:
1 | // MySQL连接池优化配置 |
4.2 数据一致性保障
4.2.1 分布式锁实现
1 | type DistributedLock struct { |
4.2.2 最终一致性方案
****数据同步策略****:
1 | // 定期同步Redis计数器到MySQL |
4.3 性能监控与告警
4.3.1 关键指标监控
****API性能指标****:
1 | type Metrics struct { |
4.3.2 业务监控指标
****关键业务指标****:
- ****内容发布量****:每分钟、每小时、每日发布量统计
- ****用户活跃度****:DAU、MAU统计
- ****点赞互动率****:平均点赞数、点赞参与度
- ****置顶命中率****:24小时内达到置顶条件的内容比例
- ****系统稳定性****:API可用率、平均响应时间
****告警规则配置****:
1 | alerts: |
4.4 安全性设计
4.4.1 认证安全
****JWT令牌安全策略****:
1 | type JWTConfig struct { |
4.4.2 数据安全
****敏感数据处理****:
- 密码使用bcrypt加密存储
- 用户数据按企业ID严格隔离
- API接口添加频率限制
- 关键操作记录审计日志
1 | // 频率限制中间件 |
五、附录
5.1 名词解释
*术语* | *解释* |
---|---|
企业圈 | 类似微信朋友圈的企业内部社交功能,支持内容发布、点赞、评论等交互 |
智能置顶 | 基于点赞数的自动置顶算法,24小时内点赞数超过10的内容参与排名,前3名自动置顶 |
JWT | JSON Web Token,用于分布式系统中的用户身份验证和授权的令牌标准 |
QPS | Queries Per Second,系统每秒处理的查询请求数量,衡量系统吞吐能力的关键指标 |
分库分表 | 数据库水平拆分策略,按照特定规则将数据分布到多个数据库或表中 |
读写分离 | 数据库架构模式,写操作在主库执行,读操作在从库执行,提升并发性能 |
分布式锁 | 在分布式环境中实现互斥访问的机制,防止并发操作导致的数据不一致 |
Feed流 | 用户动态流,按时间或算法排序展示的内容列表 |
缓存击穿 | 缓存失效时大量请求同时访问数据库的现象 |
缓存雪崩 | 大量缓存同时失效导致数据库压力激增的现象 |
热点数据 | 访问频率高的数据,需要特殊的缓存和优化策略 |
5.2 参考资料
****技术框架文档****:
****架构设计参考****:
****数据库设计参考****:
****API设计规范****:
****安全设计参考****:
****性能优化参考****:
****文档版本****:v1.1
****编写日期****:2024-12-19
****最后更新****:2024-12-19
****文档状态****:待评审
****架构师****:系统架构团队