1. 国密SDK概述
说起国密SDK，我最早接触是在三年前的一次政务云项目里。客户要求所有数据传输必须用SM系列算法，我当时第一反应是“跟OpenSSL差别大吗？”后来踩了不少坑才明白——国密不只是换几个算法库那么简单，整个密码体系的编排方式、密钥管理流程、性能瓶颈热点，跟国际标准完全是两回事。
这一章我们先搭框架。把SM2、SM3、SM4搞清楚，再看SDK架构长什么样，最后落到真实场景中。你理解了这个图景，后面诊断并发瓶颈才有落脚点。
1.1 国密算法标准速览
国密标准现在覆盖了对称、非对称、哈希三大类。我习惯用一张表把它们串起来：
| 算法 | 类型 | 密钥长度 | 典型用途 | 我踩过的坑 |
|---|---|---|---|---|
| SM2 | 非对称（椭圆曲线） | 256位 | 密钥协商、数字签名、加密 | 签名验签性能只有RSA2048的60%，并发上来后瓶颈明显 |
| SM3 | 密码杂凑 | 256位摘要 | 消息完整性、数字摘要 | 与SHA256速度差不多，但国产化审计时需要替换 |
| SM4 | 对称（分组密码） | 128位 | 数据加密、MAC | ECB模式不安全，早期方案直接用了ECB，被评审打回 |
| SM9 | 标识密码 | 256位 | 无需证书的密钥交换 | 还没在产品里大规模用过，但已有客户开始问 |
⚠ 注意： 国密算法 ≠ 国际算法加个壳。SM2的曲线参数、SM4的S盒都重新设计过，直接拿OpenSSL的椭圆曲线接口改参数行不通。我曾经见过团队用OpenSSL的EC_KEY生成SM2密钥对，结果签名结果不符合GMT 0003标准，被测评机构判定为不合规。
1.2 SDK架构设计——我画的那个图
下面这张图是我自己整理的核心架构。它分了三层，最底下是算法引擎，中间是调度与并发控制，上面是API接口层。你看完就明白为什么并发瓶颈经常出在中间那层。
为什么中间层容易出问题？我在项目里遇到过这种情况：8个线程同时调SM2签名，每个签名需要读取一次私钥缓存。如果缓存实现用了全局锁，线程切换开销随线程数线性增长，最后的吞吐量还不如单线程。说白了，调度层的无锁设计直接决定了SDK能不能抗住并发。
1.3 SDK内部模块拆解
再往下拆，SDK内部有这几个关键模块：
- 上下文管理器 —— 每个调用链需要保持状态（比如SM2签名时的随机数池）。我习惯用线程局部存储（TLS）避免全局锁。
- 密钥存储器 —— 私钥按索引分片存储，支持热更新。曾经有个项目密钥更新时没有做读写锁，线上出现签名失败。
- 内存池 —— 频繁申请释放大块内存（比如SM2签名中间结果）会导致性能抖动。用固定大小内存池后，时延下降了40%。
- 日志与监控 —— 调试阶段日志等级别太高，生产环境必须关闭，不然IO会成为瓶颈。
💡 个人习惯： 在设计SDK时，我会把日志打印做成可开关的编译宏，而不是运行时判断。因为即使是日志等级过滤，每次调用也要查一次级别表，在高频调用下累积开销不可忽略。
1.4 典型应用场景
国密SDK现在主要活在下面这些地方：
- 政务云数据加密——SM4加密数据库字段，SM2做密钥协商。我见过一个案例，用户用SM2密钥协商时每次创建新连接都生成密钥对，导致吞吐量只有预期的1/10。后来改成了密钥复用+连接池，问题解决。
- 移动端身份认证——SM2签名用于登录和交易。移动端CPU弱，签名时间超过100ms就影响体验。这时候需要把SM2点乘运算下放到硬件安全模块（SE），或者用预计算加速。
- 物联网证书签发——SM3做摘要，SM2签名证书。IoT设备可能同时发起数千个证书请求，SDK的并发队列如果设计成全局阻塞队列，瞬间就会OOM。我建议用有界队列+拒绝策略。
- 区块链存证——SM3计算区块哈希，SM2签名交易。区块链节点通常多核，但SM3的串行化压缩函数在多核上很难并行，所以常见优化是流水线——一个线程算一个块，多个块之间流水。
🔑 核心观点： 国密SDK的并发瓶颈，十有八九出在调度层和内存管理上，而不是算法本身。算法引擎再快，如果调度层设计不当，在高并发下也会被锁、上下文切换、内存分配拖死。后面的章节我会带着你逐层诊断这些瓶颈，并给出可落地的优化方案。
好了，这一章算是个热身。你把SM2/SM3/SM4的基本定位记牢，再把三层架构记在脑子里——后面所有诊断案例都会回到这张图上。我曾经带过的团队里，有人花两周优化了SM4的单线程加密速度，结果上线后总吞吐量没变，就是因为线程池配置压根没改。所以说，眼界要放在整个架构上，别只盯着局部。