一、为什么档案系统经常纠结架构
档案管理系统有个特点：业务不复杂，但部署环境复杂。
- 有的客户是省级档案馆，要求信创环境、等保三级、异地容灾；
- 有的客户是县级档案馆，一台服务器、内网、无外网；
- 有的客户是大型企业，要接 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、文件走对象存储、定时任务用分布式锁，单体实例可水平扩展，天然支持"单机→高可用"演进。
七、信创适配的架构注意
信创（国产化）是档案行业绕不开的坎（尤其政务和国企）：
- 数据库：适配达梦、人大金仓、openGauss（SQL 要规范，少用数据库特有语法）；
- 中间件：东方通、金蝶天燕等国产应用服务器（Servlet 规范要保守）；
- 操作系统：麒麟、统信（JVM/运行时兼容测试）；
- CPU：鲲鹏、飞腾、龙芯（架构不同，二进制分发要准备多版本或走容器化）；
- 前端：适配国产浏览器内核（Chrome 内核为主，避免依赖特定插件）。
架构层面的教训：信创适配最好在架构选型时就做约束（SQL 规范、标准接口、不绑死特定中间件），而不是等项目做完了再"兼容性改造"——后者成本是前者的 3~5 倍。
八、小结
- 档案系统的瓶颈在存储/检索/部署，不在并发，微服务不是解药；
- 模块化单体 + 预留拆分点是我们的选择：中小项目低成本，大项目可演进；
- 无状态化改造让单体也能水平扩展，覆盖从单机到高可用；
- 信创适配要从架构选型时就约束，别等事后补；
- 判断要不要微服务：团队 >20 人 + 真实高并发 + 独立瓶颈模块，满足再考虑。
