一、为什么档案系统经常纠结架构档案管理系统有个特点业务不复杂但部署环境复杂。有的客户是省级档案馆要求信创环境、等保三级、异地容灾有的客户是县级档案馆一台服务器、内网、无外网有的客户是大型企业要接 OA、ERP、钉钉用户几千人有的客户是中小企业几万预算、一台电脑跑。“一套架构走天下很难微服务在县级馆是灾难部署维护成本超过系统价值单体在大馆又显得不专业”、扩展性受限。这篇把我们踩过的坑和现在的架构决策讲清楚。二、单体 vs 微服务先看真相别追潮流单体Monolith的真相优点部署简单一个包、运维成本低、事务好处理、性能好优化、中小团队开发效率高缺点模块耦合、扩展要整体动、大团队协作冲突多。微服务Microservices的真相优点独立部署、按需扩展、技术栈灵活、大团队并行开发缺点运维复杂度爆炸服务发现、网关、链路追踪、分布式事务、部署要求高、资源占用大——一个 5 人团队 一台服务器玩微服务就是自虐。三、档案系统的真实技术特征档案系统不是电商、不是社交它的负载特征决定了架构选择特征档案系统的实际情况并发低档案馆同时在线用户通常几十~几百数据量大文件大、总量大但访问频次低业务复杂度中权限、流程、著录、检索一致性要求高档案数据错不得但事务粒度小部署环境复杂信创、内网、单机、多级结论档案系统的瓶颈从来不在并发而在存储、检索、部署适配。微服务解决不了存储和检索问题反而引入一堆部署负担——所以无脑微服务是档案系统最常见的架构错误。四、我们的决策模块化单体 可选拆分的半分离架构最终方案既不是纯单体也不是纯微服务而是模块化单体Modular Monolith 预留拆分点┌─────────────────────────────────────────────┐ │ 档案管理系统单体应用 │ ├─────────┬─────────┬─────────┬───────────────┤ │ 权限模块 │ 著录模块 │ 检索模块 │ 流程/借阅模块 │ ├─────────┴─────────┴─────────┴───────────────┤ │ 领域服务层模块间接口化调用 │ ├─────────────────────────────────────────────┤ │ 基础设施层存储/消息/任务调度 │ │ PostgreSQL MinIO Redis ES 任务队列 │ └─────────────────────────────────────────────┘设计要点模块间用接口通信不跨表直连权限模块、著录模块、检索模块之间通过 Service 接口调用模块边界清晰为将来拆分留好缝检索独立成组件ES 本来就是独立部署的中间件检索逻辑封装成独立模块将来需要可单独拆成微服务任务调度独立OCR、图像处理、批处理这些重活走任务队列异步不阻塞主业务——这是单体能扛大项目的关键单库多 schema 或单库单 schema 按规模切换县级馆单库即可省级大馆分库业务库 / 文件索引库 / 审计库。为什么这样选中小项目一套单体包一台服务器运维成本最低大项目单体内部模块已解耦需要时把检索服务加工服务物理拆出去不用推倒重来团队5~15 人的团队开发模块化单体效率远高于微服务。五、什么时候才真的需要微服务我们给出需要上微服务的判据满足 2 条以上再考虑团队规模 20 人且多个小组并行开发互不干扰并发真实高如省级平台、多馆统一平台在线用户数千、检索 QPS 上百部署环境多且独立演进不同客户要独立部署不同版本这其实是多实例部署单体也能做有独立的性能瓶颈模块需要单独扩缩容通常是检索/OCR 加工。即使满足也建议从单体先跑把模块边界设计好按需再拆——拆微服务容易合回去难。六、部署形态矩阵一套代码多种部署我们的架构用一套代码 配置开关支持多种部署形态部署形态适用场景组件裁剪单机版县级馆、中小企业单进程 SQLite/单机 PG内置文件存储标准版市级馆、一般企业单体 PG MinIO ES高可用版省级馆、多馆平台单体多副本无状态化 主备 ES 集群 对象存储集群信创版国产化要求国产 CPU/OS/数据库适配层见后关键无状态化改造——Session 存 Redis、文件走对象存储、定时任务用分布式锁单体实例可水平扩展天然支持单机→高可用演进。七、信创适配的架构注意信创国产化是档案行业绕不开的坎尤其政务和国企数据库适配达梦、人大金仓、openGaussSQL 要规范少用数据库特有语法中间件东方通、金蝶天燕等国产应用服务器Servlet 规范要保守操作系统麒麟、统信JVM/运行时兼容测试CPU鲲鹏、飞腾、龙芯架构不同二进制分发要准备多版本或走容器化前端适配国产浏览器内核Chrome 内核为主避免依赖特定插件。架构层面的教训信创适配最好在架构选型时就做约束SQL 规范、标准接口、不绑死特定中间件而不是等项目做完了再兼容性改造——后者成本是前者的 3~5 倍。八、小结档案系统的瓶颈在存储/检索/部署不在并发微服务不是解药模块化单体 预留拆分点是我们的选择中小项目低成本大项目可演进无状态化改造让单体也能水平扩展覆盖从单机到高可用信创适配要从架构选型时就约束别等事后补判断要不要微服务团队 20 人 真实高并发 独立瓶颈模块满足再考虑。
档案数字化研发手记：档案管理系统整体架构——单体还是微服务？
一、为什么档案系统经常纠结架构档案管理系统有个特点业务不复杂但部署环境复杂。有的客户是省级档案馆要求信创环境、等保三级、异地容灾有的客户是县级档案馆一台服务器、内网、无外网有的客户是大型企业要接 OA、ERP、钉钉用户几千人有的客户是中小企业几万预算、一台电脑跑。“一套架构走天下很难微服务在县级馆是灾难部署维护成本超过系统价值单体在大馆又显得不专业”、扩展性受限。这篇把我们踩过的坑和现在的架构决策讲清楚。二、单体 vs 微服务先看真相别追潮流单体Monolith的真相优点部署简单一个包、运维成本低、事务好处理、性能好优化、中小团队开发效率高缺点模块耦合、扩展要整体动、大团队协作冲突多。微服务Microservices的真相优点独立部署、按需扩展、技术栈灵活、大团队并行开发缺点运维复杂度爆炸服务发现、网关、链路追踪、分布式事务、部署要求高、资源占用大——一个 5 人团队 一台服务器玩微服务就是自虐。三、档案系统的真实技术特征档案系统不是电商、不是社交它的负载特征决定了架构选择特征档案系统的实际情况并发低档案馆同时在线用户通常几十~几百数据量大文件大、总量大但访问频次低业务复杂度中权限、流程、著录、检索一致性要求高档案数据错不得但事务粒度小部署环境复杂信创、内网、单机、多级结论档案系统的瓶颈从来不在并发而在存储、检索、部署适配。微服务解决不了存储和检索问题反而引入一堆部署负担——所以无脑微服务是档案系统最常见的架构错误。四、我们的决策模块化单体 可选拆分的半分离架构最终方案既不是纯单体也不是纯微服务而是模块化单体Modular Monolith 预留拆分点┌─────────────────────────────────────────────┐ │ 档案管理系统单体应用 │ ├─────────┬─────────┬─────────┬───────────────┤ │ 权限模块 │ 著录模块 │ 检索模块 │ 流程/借阅模块 │ ├─────────┴─────────┴─────────┴───────────────┤ │ 领域服务层模块间接口化调用 │ ├─────────────────────────────────────────────┤ │ 基础设施层存储/消息/任务调度 │ │ PostgreSQL MinIO Redis ES 任务队列 │ └─────────────────────────────────────────────┘设计要点模块间用接口通信不跨表直连权限模块、著录模块、检索模块之间通过 Service 接口调用模块边界清晰为将来拆分留好缝检索独立成组件ES 本来就是独立部署的中间件检索逻辑封装成独立模块将来需要可单独拆成微服务任务调度独立OCR、图像处理、批处理这些重活走任务队列异步不阻塞主业务——这是单体能扛大项目的关键单库多 schema 或单库单 schema 按规模切换县级馆单库即可省级大馆分库业务库 / 文件索引库 / 审计库。为什么这样选中小项目一套单体包一台服务器运维成本最低大项目单体内部模块已解耦需要时把检索服务加工服务物理拆出去不用推倒重来团队5~15 人的团队开发模块化单体效率远高于微服务。五、什么时候才真的需要微服务我们给出需要上微服务的判据满足 2 条以上再考虑团队规模 20 人且多个小组并行开发互不干扰并发真实高如省级平台、多馆统一平台在线用户数千、检索 QPS 上百部署环境多且独立演进不同客户要独立部署不同版本这其实是多实例部署单体也能做有独立的性能瓶颈模块需要单独扩缩容通常是检索/OCR 加工。即使满足也建议从单体先跑把模块边界设计好按需再拆——拆微服务容易合回去难。六、部署形态矩阵一套代码多种部署我们的架构用一套代码 配置开关支持多种部署形态部署形态适用场景组件裁剪单机版县级馆、中小企业单进程 SQLite/单机 PG内置文件存储标准版市级馆、一般企业单体 PG MinIO ES高可用版省级馆、多馆平台单体多副本无状态化 主备 ES 集群 对象存储集群信创版国产化要求国产 CPU/OS/数据库适配层见后关键无状态化改造——Session 存 Redis、文件走对象存储、定时任务用分布式锁单体实例可水平扩展天然支持单机→高可用演进。七、信创适配的架构注意信创国产化是档案行业绕不开的坎尤其政务和国企数据库适配达梦、人大金仓、openGaussSQL 要规范少用数据库特有语法中间件东方通、金蝶天燕等国产应用服务器Servlet 规范要保守操作系统麒麟、统信JVM/运行时兼容测试CPU鲲鹏、飞腾、龙芯架构不同二进制分发要准备多版本或走容器化前端适配国产浏览器内核Chrome 内核为主避免依赖特定插件。架构层面的教训信创适配最好在架构选型时就做约束SQL 规范、标准接口、不绑死特定中间件而不是等项目做完了再兼容性改造——后者成本是前者的 3~5 倍。八、小结档案系统的瓶颈在存储/检索/部署不在并发微服务不是解药模块化单体 预留拆分点是我们的选择中小项目低成本大项目可演进无状态化改造让单体也能水平扩展覆盖从单机到高可用信创适配要从架构选型时就约束别等事后补判断要不要微服务团队 20 人 真实高并发 独立瓶颈模块满足再考虑。
