第三章 密钥服务部署模式：单机还是集群？
部署模式的选择，直接决定了密钥服务的可用性、吞吐量和运维复杂度。很多团队在初期图省事选了单机，结果线上出问题才急急忙忙改集群。我见过不止一次这样的教训。好，咱们把两种模式掰开揉碎讲清楚。
单机模式：简单但不一定省心
单机部署就是把密钥服务跑在一台机器上，所有请求都打到这里。听起来够简单吧？确实，从搭建到调试，半小时就能搞定。
适用场景：开发测试环境、内部工具、对可用性要求不高的内部系统。比如你只是给团队内部做签名验证，日均请求量不超过几千次，单机完全够用。
但别被“简单”迷惑了。我在项目里遇到过这么一件事：有个支付系统的密钥服务跑了两年单机，一直很稳。结果某天磁盘满了，服务挂了十分钟。就是这十分钟，订单签名失败导致大量交易回退……嗯，从那以后我再也不敢在核心链路上用单机。
| 对比维度 | 单机模式 | 说明 |
|---|---|---|
| 部署成本 | 极低，一台虚拟机或容器就行 | 不需要任何分布式组件 |
| 性能上限 | 受单机CPU/内存/磁盘限制 | 通常QPS几千到几万（取决于硬件） |
| 可用性 | 低，单点故障 | 宕机=服务不可用，恢复时间取决于运维速度 |
| 数据一致性 | 天然一致，无分布式问题 | 本地文件或数据库即可 |
| 运维复杂度 | 几乎没有，日常监控即可 | 但故障时压力全在一个人身上 |
单机避坑：我曾经见过有人把密钥服务单机部署在云服务器上，没做任何备份。结果云服务商磁盘故障，密钥材料直接丢失，连恢复都没办法。所以单机至少要做好两件事：定时备份密钥库、准备快速切换脚本。
集群模式：高可用是刚需
集群部署就是多台机器同时提供服务，背后往往需要一致性算法来保证密钥数据的同步。最常见的模式有两种：主从复制和多活（Raft/Paxos）。
主从复制：一台主节点写，多台从节点读。写操作必须发给主节点，主节点写完再异步或同步复制给从节点。这种模式读写分离，适合读多写少的场景——比如密钥轮换不频繁，但验证签名请求量很大。
我优化过一个案例：原先是单机支撑3万QPS的验签请求，改用一主两从后，读QPS直接干到15万。因为把验签请求全部分发给从节点了。
多活模式（Raft类）：所有节点都接受读写，但通过共识算法保证数据一致性。比如Hashicorp Vault的集成存储后端就用了Raft。这种模式没有单点瓶颈，但写入性能会受到共识开销的影响——三次网络往返才能确认一次写入。
| 模式 | 一致性保证 | 写入性能 | 读性能 | 故障恢复 |
|---|---|---|---|---|
| 主从异步复制 | 最终一致，可能丢数据 | 高（不等待从节点） | 极高（水平扩展） | 手动或自动切换主节点 |
| 主从同步复制 | 强一致（等待所有从节点确认） | 中等（写入延迟增加） | 极高 | 自动切换，但丢数据风险小 |
| Raft共识 | 强一致 | 较低（需要多数节点确认） | 高（所有节点可读） | 自动选举，无需干预 |
我的建议：如果你的密钥写入频率少于每秒10次，Raft模式的额外延迟完全可以接受。但如果你的密钥库频繁轮换（比如每分钟几千次），考虑用主从同步复制更稳妥。我曾经给一家加密交易所调优，他们每秒要写入200多次密钥更新，用Raft直接导致写入队列堆积……后来改成主从同步，延迟从15ms降到3ms。
部署选型与性能权衡
选单机还是集群？不能光看功能，更要看三个关键指标：可用性要求、吞吐量要求、运维团队能力。
- 可用性要求：如果SLA要求99.99%以上（每年宕机不超过52分钟），集群是必选项。单机你只能做到99.9%左右，因为硬件故障、断电、网络抖动都可能导致宕机。
- 吞吐量要求：单机QPS天花板通常在几万，而集群可以通过增加节点线性扩展。但注意：密钥服务的瓶颈往往不是CPU，而是加密运算的硬件加速能力（比如HSM模块、Intel SGX），集群扩节点不一定会线性提升性能——如果加密操作都挤在同一台HSM上，加再多应用节点也没用。
- 运维团队能力：集群需要维护一致性算法、负载均衡、健康检查、故障切换。团队没有人熟悉这些，硬上集群反而容易出更多问题。我见过一个小团队为了“高可用”上了三节点Raft，结果每次节点重启都触发重新选主，服务抖动半小时……后来退回到主从复制+手动切换，反而更稳定。
一个小技巧：如果你们刚开始做密钥服务，可以先从单机开始，但一定要预留集群化接口。比如密钥存储层设计成可插拔的，上层用域名访问而不是直连IP。这样将来迁移到集群时，改个配置就行，不用重构代码。我记得有个创业公司就是因为最开始写死了本地文件路径，后来扩集群时改了整整两周代码。
我的实战建议
最后给你几条实在的建议：
- 用单机起步，但把它当成“可替换的”。把密钥存储和业务逻辑分离，密钥库放在外部数据库或持久卷上。这样哪怕机器坏了，换一台机器挂载同一个密钥库就能恢复，比重新配置密钥快得多。
- 集群方案先做“读扩展”。如果业务增长后单机压力上来了，先加从节点做读负载均衡。写入仍然走主节点，这样数据一致性风险最小，而且代码改动也少。
- 选一致性算法要看峰值写入。我记得有一次帮一个客户压测，他们用Raft每秒钟更新密钥100次，结果延迟从2ms飙升到60ms。后来我建议他们把批量更新合并成每5秒一次，单次写入20个密钥，延迟立刻降到5ms。所以，调优不是改配置，而是改使用模式。
- 千万别忽略硬件差异。密钥服务是CPU密集+IO敏感型业务。同样的集群，用普通云主机和用了SGX/Nitro Enclaves的虚拟机，性能差3-5倍。你在做容量规划时，一定要基于你的实际硬件做压测，不能看理论数字。