高可用概念与重要性
做PKI接口高可用，得先搞清楚「高可用」到底在说什么。我记得刚入行时，领导让我设计一个CA集群，我上来就堆了两台服务器，以为这样就高可用了。结果线上一个网络抖动，证书签发全停了。后来才明白——高可用不是多部署几台机器那么简单。
这一节，我们把核心概念拎清楚：CAP理论、故障切换目标、RTO与RPO指标。这些是决策的依据，也是你将来和运维、产品吵架的底气。
1. 再说CAP理论
CAP理论是分布式系统的铁三角：
- C (Consistency) —— 一致性。所有节点在同一时刻看到的数据相同。
- A (Availability) —— 可用性。每次请求都能收到非错误的响应。
- P (Partition Tolerance) —— 分区容错性。网络分区发生时，系统仍能正常工作。
但三角形最多只能选两个，你没法三个全保。为什么？因为网络分区是必然会发生的，你没法避免机房光缆被挖断，所以 P 必须选。剩下的就是 C 和 A 的权衡。
PKI 接口场景下的选择：
我做过一个金融级CA，监管要求证书吊销信息必须严格一致，所以选了 CP (Consistency + Partition Tolerance)，牺牲了一点可用性——分区时部分请求会返回“服务暂不可用”，但数据不会乱。另一个互联网 PKI 项目，用户对响应速度敏感，我们选了 AP (Availability + Partition Tolerance)，允许短时间的不一致（比如CRL延迟几分钟），但保证任何时候都能发证书。
说白了，没有银弹。你得根据业务场景定。
这理论听着抽象，实际落地时你要回答三个问题：
- 网络分区了，我是等数据同步完再响应，还是先返回旧数据？
- 多个节点同时写同一个证书状态，谁说了算？（主从？多主？）
- 用户查一个刚吊销的证书，我能给他旧状态吗？
这些问题没有标准答案，但CAP可以帮你理清取舍。
2. 故障切换的核心目标
故障切换不是简单的“A挂了切到B”。你得明确目标，不然切换了也没用。我个人习惯把目标归纳为三点：
- 自动发现故障 —— 不能等人报障。心跳检测、健康检查必须够快。
- 平滑切换 —— 切换时客户端不能感知。会话、连接、缓存怎么迁移？
- 恢复后回切 —— 原主节点修好了怎么办？自动回切还是手动？回切时会不会再断一次？
避坑指南：我曾经做一个HSM的故障切换，心跳只配了3秒超时。结果网络抖动超过3秒就误切，来回切了五次。后来把超时调到了15秒，结合连续失败次数判断，才稳定下来。别把监控周期设太短，误切换比不切换更可怕。
三个目标优先级：可用 > 一致 > 性能。在切换过程中，宁可短暂服务降级，也不要让证书服务整体挂掉。
3. RTO与RPO：灾难恢复的两个数字
这两个指标是聊高可用、灾备方案时绕不开的。我经常被业务问：“故障多久能恢复？” “会丢多少数据？” —— 答案就是 RTO 和 RPO。
| 指标 | 全称 | 定义 | PKI场景的例子 |
|---|---|---|---|
| RTO | Recovery Time Objective | 从故障发生到服务恢复的最大可接受时间 | CA节点宕机，必须在5分钟内切换到备用节点 |
| RPO | Recovery Point Objective | 可容忍的最大数据丢失量（用时间衡量） | 最多允许丢失1分钟内的证书签发记录 |
举个例子：你要求RTO=5分钟，RPO=30秒。那就意味着故障发生时，需要同步机制（比如准实时日志复制）把数据延迟控制在30秒以内，并且切换流程必须在5分钟内完成。我见过不少团队盯着RTO猛做，却忽略了RPO——结果切换成功了，数据丢了一小时，审计过不了。
个人经验：初期把RTO/RPO定松一点，比如RTO=30分钟、RPO=5分钟，先跑顺再收紧。上来就要求“零数据丢失，秒级切换”，技术成本和复杂度会陡增，往往得不偿失。
4. 本章要点速查
- CAP：P必选，C和A根据业务权衡。PKI强一致性场景选CP，高吞吐场景选AP。
- 故障切换目标：自动发现 → 平滑切换 → 回切稳定。避免误切换，宁可慢不可错。
- RTO/RPO：用具体数字量化恢复要求，先松后紧，逐步优化。
这些概念是所有高可用设计的地基。后面几章讲具体策略时，你会不断回来对照这张图。嗯，建议你保存下来，跟团队讨论方案时直接画出来——比讲一堆理论管用。