EAAB v1.0：我们打造了电子会计档案行业第一套业务级性能评测体系
不看TPS，看业务——数凭正式发布EAAB（Electronic Accounting Archive Benchmark）电子会计档案性能评测规范v1.0，覆盖归档、查询、导出、OFD生成、海量翻页、长期稳定性和灾难恢复七大场景，让性能不再是纸面数字，而是客户真正关心的业务体验。
行业内一直缺一样东西：一套电子会计档案系统到底"跑不跑得动"，怎么衡量？
传统软件公司的做法是拉一台压测机跑个脚本，出一张 TPS 曲线图，报告上写"单机 TPS 10000、QPS 50000"，然后告诉客户"性能没问题"。
但客户真正关心的问题从来不是 TPS。
客户关心的是：年底 5000 万张发票归档，系统会不会崩？领导要导出 5 万份凭证，要等多久？100 个会计同时翻页查账，到第 500 页会不会卡死？
这些问题，传统压测报告一个都回答不了。
所以我们自己做了一套。
什么是 EAAB
EAAB 的全称是 Electronic Accounting Archive Benchmark——电子会计档案性能评测规范。它的定位是电子会计档案行业的 TPC-C：一套公开的、可复现的、面向业务场景的评测体系。
核心原则只有一句话：不测抽象吞吐量，只测客户天天在用的业务。
EAAB 目前是 v1.0 版本，覆盖七大场景，每个场景都对应一个客户一定会遇到的真实问题：
| 场景编号 | 场景名称 | 回答的业务问题 |
|---|---|---|
| EAAB-A | 归档能力 | 月末集中归档，系统吞得下吗？ |
| EAAB-S | 查询能力 | 千万人在查，秒级返回吗？ |
| EAAB-E | 批量导出 | 领导要 10 万份凭证，多久能下载完？ |
| EAAB-O | OFD 生成 | 百万级 OFD 版式文件，国产化是不是真做好了？ |
| EAAB-B | 海量翻页 | 第 1000 页和第 1 页一样快吗？ |
| EAAB-L | 长期稳定性 | 连续跑 7 天，系统还正常吗？ |
| EAAB-C | 灾难恢复 | 归档到一半对象存储断了，数据会不会丢？ |
六大场景详解
EAAB-A：归档——系统吞得下吗？
月末、季末、年末，是财务归档的高峰期。我们按照"一天新增量"来设计测试档位：500 万份、1000 万份、3000 万份。连续归档 24 小时不停，全程监测 CPU、磁盘 IO、数据库锁等待、ES 写入速率和消息队列堆积。
为什么是 24 小时连续归档，而不是跑 10 分钟取个"瞬时 TPS"？因为真实业务中，归档不是一波流。系统扛得住前 10 分钟不代表扛得住 24 小时——内存碎片、连接池泄漏、MQ 堆积，这些慢病只有长时间运行才能暴露。
最终我们看的不是"峰值 TPS 多少"，而是：归档成功率有没有达到 99.99%？P99 长尾有没有收敛？MQ 有没有越堆越多？24 小时后，系统还能不能继续归档？
EAAB-S：查询——千万人在查，秒级返回吗？
这是客户最关心的一项。我们设计了 1000、5000、10000 三个并发档位，阶梯加压，每档稳定运行至少 5 分钟。查询类型也不是"select * limit 10"，而是八种真实查询场景：
- 发票号精确查询
- 凭证号精确查询
- 供应商模糊查询
- 金额区间筛选
- OCR 全文检索
- 组合条件查询（例如：
2024年 + 金额>10000 + 供应商=华为 + 合同编号=XXX） - 附件类型过滤（PDF / OFD / XML）
每种查询 × 每个并发档位，单独出数。最后交出的不是一行 TPS，而是一张矩阵表：每种查法在不同并发下，平均响应多少、P95 多少、P99 多少、失败率多少。客户一眼就能看到自己的使用场景在不在安全区。
EAAB-E：批量导出——几乎所有厂商都不测，但客户天天用
审计来了要导出，税务局检查要导出，领导要看也要导出。但绝大多数系统的导出功能在设计时只考虑了"导出几十条"，一旦数据量上到万条级别，内存直接打满，浏览器卡死，甚至连带把其他用户的查询也拖慢。
我们按 1000、5000、10000、50000、100000 份五个档位测试，覆盖 PDF、OFD、ZIP、RAR 全部格式，全部真实下载。测试指标包括总耗时、压缩耗时、下载速度、CPU/内存/IO 全程采样，以及最关键的一条：100000 份不允许中途失败。
EAAB-O：OFD 版式生成——国产化的试金石
OFD 是电子会计档案特有的版式格式，也是信创合规的硬性要求。生成 OFD 不是简单的文件格式转换——它需要字体嵌入（含中文字体子集化）、二维码渲染、电子签章、XML 结构化数据嵌入，每一步都可能成为吞吐瓶颈。
我们设置了 100 万、500 万、1000 万份三个档位，覆盖全部要素。除了生成速度和失败率外，还要抽样校验渲染正确性——字体对不对、二维码能不能扫、签章完不完整。这一项比 TPS 有价值得多，因为它直接回答了一个客户没法自己验证的问题：国产化是不是真做好了？
EAAB-B：海量翻页——第 1000 页和第 1 页一样快吗？
稍有经验的 DBA 都知道深翻页有多疼。第一页 300ms，很漂亮；第 1000 页 30 秒，会计直接怀疑人生。
我们在百万至千万级数据集上连续翻页、滚动分页、排序、过滤，按页深逐级出数。验收标准很明确：第 1000 页的响应时间不得超过第 1 页的 10 倍，且绝对值不能超过 3 秒。超过这个线的，必须改用游标分页后复测。
这项测试暴露的问题往往不是"数据库不够快"，而是应用层的分页策略选错了——但客户不关心是谁的问题，客户只关心"翻到后面会不会卡"。EAAB 把这个问题摆到桌面上，谁也别想糊弄过去。
EAAB-L：长期稳定性——连续跑 7 天，系统还能不能继续跑？
这是几乎所有厂商都不做的一项，但恰恰是企业最怕的：上线两个月开始慢。
我们施加 168 小时的混合负载——查询 50%、翻页 30%、归档 15%、导出 5%，模拟真实业务比例。第 168 小时的 P95 和第 1 小时的 P95 对比，如果漂移超过 20%，判定不通过。
监控指标覆盖：堆内存是否有持续爬升（Full GC 前后对比）、老年代 GC 频率和耗时是否恶化、线程数和文件句柄是否泄漏、数据库连接池是否耗尽、缓存命中率是否稳定。最终结论必须是一句话：系统还能不能继续跑。
EAAB-C：灾难恢复——归到一半出事，数据会不会丢？
Netflix、阿里、腾讯都不是只测 TPS——他们做混沌工程。电子档案行业其实特别适合做混沌工程，因为客户的核心恐惧从来不是"查询慢了几百毫秒"，而是"归到一半出事，数据会不会丢"。
我们设计了一套故障注入矩阵：数据库断开、ES 节点宕机、Redis 不可用、消息队列中断、对象存储超时、网络延迟抖动，每种故障注入后观察系统的优雅降级和自动恢复能力。
其中最具代表性的标杆场景是：归档 100 万份，进行到 50 万时对象存储中断 5 分钟。 恢复后必须回答四个问题：
- 系统是不是继续归档了？（断点续传，不是从头开始）
- 有没有重复归档？（uniqueBizId 幂等校验，必须为 0）
- 有没有丢数据？（提交数 = 成功数 + 明确失败数，对账必须平衡）
- 有没有坏数据？（抽样校验版式文件 checksum）
四个问题全部通过，客户才能真正放心把数据交给你。
标准数据集：不是"几百条测试数据"出报告
所有 EAAB 测试必须基于标准数据集。我们定义了四个规模档位：
| 数据集 | 电子凭证份数 | 适用客户 |
|---|---|---|
| DS-1M | 100 万 | 中小企业 |
| DS-10M | 1000 万 | 大型集团 |
| DS-50M | 5000 万 | 超大型集团 / 共享中心 |
| DS-100M | 1 亿 | 行业极限验证 |
每个档位的数据集不是简单复制——它包含真实元数据（约 40 个字段）、OFD 和 PDF 版式文件（含字体、二维码、签章）、结构化 XML、OCR 全文文本，以及附件。时间跨度超过 5 个会计年度，月度分布有真实的波峰波谷——月末和季末是平日的 3 到 5 倍。供应商超过 10 万个不同值，金额呈幂律分布。
用几句 SQL 随手造几千条测试数据就跑压测的做法，在 EAAB 体系下不成立。
统一环境：结果必须可复现
同样一套压测脚本，在 2 核 4G 云主机上跑和在 16 核 32G 物理机上跑，结果当然不一样。如果不公开环境，任何性能数字都没有意义。
EAAB 要求所有报告必须附带完整的环境表：CPU 型号、磁盘类型、操作系统和内核版本、中间件版本和关键参数（连接池大小、ES 分片数、JVM 参数），缺一栏即视为报告无效。数据集生成器和测试脚本全部随产品仓库版本化管理，保证任何时间可以复现历史结果。
最终交付：一张表格，不是一叠曲线图
每次 EAAB 评测报告只发一张汇总表加各场景明细。客户不需要看得懂火焰图，只需要看得懂这张表：
| 测试项目 | 数据规模 | 并发 | 平均耗时 | P99 | 成功率 |
|---|---|---|---|---|---|
| 发票查询 | 5000万份 | 5000 | 180ms | 420ms | 99.99% |
| 全文检索 | 5000万份 | 2000 | 650ms | 1.2s | 99.97% |
| OFD生成 | 100万份 | 100 | 52份/秒 | - | 100% |
| 批量导出 | 10万份 | 100 | 16分钟 | - | 100% |
| 批量归档 | 3000万份 | 持续24h | 480份/秒 | - | 100% |
| 连续运行 | 168小时 | 混合负载 | 无异常 | - | 无内存泄漏 |
注：上表为报告结构示例，具体数值以实际测试结果为准。
为什么我们要自己做
国家标准——包括 DA/T 94《电子会计档案管理规范》、DA/T 95《电子会计凭证档案管理技术规范》、GB/T 39784《电子档案管理系统通用功能要求》——都对系统提出了"保证真实性、完整性、可用性、安全性"的要求。但没有一个标准规定了"怎么测"——没有统一的压测方法、没有标准数据集、没有公开的评价指标。
这意味着行业在性能这件事上没有统一语言。各家厂商说"我们支持亿级数据""我们查询秒级响应"，但你没法横向比较，因为根本不知道这些说法是在什么数据规模、什么并发、什么硬件环境下测出来的。
这反而给了我们一个机会。既然没有标准，那就建立标准。EAAB 的长期目标是：不只我们自己用，也欢迎同行按同一规范发布结果，让客户可以横向比较。每当我们自己的产品版本升级，按同一基准复测，让客户看到我们是不是在持续变好——而不是悄悄变慢。
后续
EAAB 的规范文档、测试脚本、数据生成器已随产品仓库版本化管理。后续每一次产品大版本发布，都会同步发布一份 EAAB 评测报告。我们把自己放在阳光下面——每一次版本升级是在变好还是在变慢，数据说了算。
相关推荐
电子会计档案电子签章要求：法规依据、技术形态与合规落地指南
电子签章是电子会计档案真实性保障的关键环节。本文从《电子签名法》可靠电子签名要件、电子印章管理方向、国密算法（SM2/SM3/SM4）到OFD版式内置签章与验签机制，系统拆解电子会计档案电子签章的合规要求、验证路径与常见误区。
电子会计档案长期保存：开放格式、格式迁移与30年可读性保障
电子会计档案长期保存全解：从格式过时、软件淘汰、介质老化与加密失效四大挑战，到长期保存与备份、归档的关系辨析，OFD/PDF-A 开放格式选择、格式迁移触发时机与流程、OAIS/AIP 封装与信息包概念、存储介质生命周期与翻录，以及 SM3 完整性校验、可读性抽检与签名重验的定期巡检机制，帮助财务与 IT 团队构建覆盖 30 年保管期的档案可读性保障体系。
电子发票归档全指南：从财会〔2020〕6号文到系统落地的合规路径
财会〔2020〕6号文对电子发票归档提出了明确的合规要求。本文从文件格式（OFD/PDF）、元数据采集、红字发票处理到报销-入账-归档全链路，为您拆解电子发票电子化归档的完整合规框架与实操要点。