文件网关架构

目录

• 1 场景
• 2 逻辑
• 3 过程
• 4 开发
• 5 物理
• 6 思考与展望
  • 6.1 如何做的分表分库
  • 6.2 目前存在什么问题，将来如何发展

1 场景

旧版的文件管理，封装了 FastDFS 的 API，直接让业务方使用，存在以下问题：

1. 不能鉴权。FastDFS 未提供权限管理、审计功能
2. 不能校验。外部链接不支持规则校验，只要知道地址就可以随意访问
3. 安全隐患。外部链接直接使用 FastDFS 的文件地址拼接，暴露了选型、真实地址

2 逻辑

架构方面，由 client、service 两部分组成，分为上传模块、下载模块。
t_file 文件记录表，逻辑表 5000万，物理表 15万
t_link 外部链接表
t_rule 访问规则表

3 过程

数据量 7000万+，日增量 14万+，峰时QPS 发生在凌晨业务组批量备份合同等文件 1000+。
申请写权限：读1次MySQL（3000 TPS） + 写1次Redis（7W QPS）
申请读权限：读1次MySQL（3000 TPS） + 写1次Redis（7W QPS）
置换文件ID：读1次Redis（7W QPS）+ 生成分布式ID（400W QPS） + 写1次数据库（3000 TPS）

4 开发

使用 SpringBoot 全家桶开发。

5 物理

分别部署在铜牛、马驹桥，共4个实例。
单机QPS 1000，单边2个实例可以满足 1000+ QPS，在一个机房断电情况下实现高可用。

6 思考与展望

6.1 如何做的分表分库

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

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

1. 将来业务创建更多外部连接，那么 t_rule、t_link 会膨胀
   场景是读多、写少，可以使用面向文档的 NoSQL 数据库。