文件网关架构

目录

• 1 项目背景
  • 1.1 为什么要启动这个项目
  • 1.2 项目角色，开发模块
• 2 设计方案
  • 2.1 业务架构图
  • 2.2 有哪些核心表，数据量多大
  • 2.3 有哪些性能指标，比如日访问量、峰时QPS
  • 2.4 部署了多少实例，机器配置
  • 2.5 依赖哪些中间件，要部署多少台，机器配置
• 3 问题难点
  • 3.1 遇到了什么挑战，如何解决
  • 3.2 目前存在什么问题，将来如何发展

1 项目背景

1.1 为什么要启动这个项目

1. FastDFS 未提供权限管理、审计功能，管理上存在风险
2. 业务项目使用 SDK 直接访问 FastDFS，不利于后期改造、升级
3. 外部链接直接使用 FastDFS 的文件地址拼接，暴露了选型、真实地址
4. 外部链接暴露之后无法回收，除非直接删除文件本身
5. 外部链接不支持规则校验，只要知道地址就可以随意访问

1.2 项目角色，开发模块

和同事一起做的设计方案，独立开发，编写文档，落地推广，日常维护。

2 设计方案

2.1 业务架构图

本身是个微服务，架构图就免了。

2.2 有哪些核心表，数据量多大

t_file 文件记录表，逻辑表 5000万，物理表 15万
t_link 外部链接表
t_rule 访问规则表

2.3 有哪些性能指标，比如日访问量、峰时QPS

QPS 峰值发生在凌晨业务组批量备份合同等文件，1000 QPS

2.4 部署了多少实例，机器配置

分别部署在铜牛、马驹桥、无锡，共3个实例。8C32T，内存1G。

2.5 依赖哪些中间件，要部署多少台，机器配置

申请写权限：读1次数据库（3000 TPS） + 写1次Redis（3W QPS）
申请读权限：读1次数据库（3000 TPS） + 写1次Redis（3W QPS）
置换文件ID：读1次Redis（3W QPS）+ 生成分布式ID（400W QPS） + 写1次数据库（3000 TPS）

3 问题难点

3.1 遇到了什么挑战，如何解决

核心表 t_file 数据量大，一天产生14.6万记录，一年产生1.5亿记录。因此使用日期作为维度分表。
信贷一组 300000 * 5 = 150000
信贷二组 500000 * 5 = 250000

3.2 目前存在什么问题，将来如何发展

1. 将来业务创建更多外部连接，那么 t_rule 会更大，这个表读多、写少，建议使用面向文档的 NoSQL 数据库。

标签：文件,网关,架构,哪些,架构图,数据量,机器配置,QPS
来源： https://www.cnblogs.com/mougg/p/13893772.html