3、自建KMS架构设计：以HashiCorp Vault为例，部署架构与高可用方案

讲KMS迁移，绕不开自建KMS的架构设计。说实话，我见过不少团队，Vault的部署只做了个单点。某个周末，机房一个电源故障，整个密钥服务挂了。那场面，真的很尴尬。

今天我就拿HashiCorp Vault当例子，把它的部署架构和高可用方案拆开揉碎。你想想看，密钥管理系统要是挂了，所有依赖它的业务都得跟着停。这玩意儿，必须提前想清楚。

3.1 部署模式的选择

Vault的部署，我个人习惯先分成三种模式。这决定了你后续所有的架构决策。

3.2 存储后端选型：数据放在哪？

高可用架构的核心问题，就是后端存储用什么。Vault本身不存数据，它靠存储后端来干活。说白了，你选什么后端，决定了你的脑裂风险有多大。

我个人比较推荐Consul，原因有三：强一致性、原生支持、运维成熟。当然，也有人用Raft或Etcd。我用个表格帮你对比一下。

3.3 高可用架构：到底怎么搭？

高可用的Vault集群，说白了就两个关键点：共享存储和负载均衡。

举个例子，我用Consul做存储后端，搭了个三节点集群。架构图我手绘了一下，你感受感受。

这个图里，关键点有三个：

• 负载均衡器：我推荐用Nginx或HAProxy。它负责把请求分到活跃节点，做好健康检查。健康检查的端口，建议用8200/v1/sys/health。
• Standby节点：不是闲着没事干。它接收所有请求，然后自动转发给Active节点。一旦Active挂了，Consul里存的锁释放，Standby立刻顶上。整个过程，对客户端来说几乎是透明的。
• 存储后端：所有节点共享同一个Consul集群。数据一致性由Consul保证，Vault只负责读写。

3.4 性能与容量考量

架构搭好了，性能怎么算？我给你一个大概的指标公式：

并发吞吐 ≈ 单节点QPS × 节点数 × 0.8
（0.8 是集群内转发损耗系数）

举个例子，我在一个金融客户现场，单节点Vault的QPS大约是5000（用Consul后端）。三节点集群，理论值就是5000×3×0.8=12000 QPS。实际跑下来，他们线上峰值9000左右，很稳定。

存储后端也要注意磁盘IO。Consul写操作是强一致的，每一笔都要等多数节点确认。磁盘慢，整个集群就慢。我建议至少用SSD，不然写入超过500 QPS，Consul的磁盘排队就开始长了。

3.5 核心高可用配置片段

光说理论不够，我贴一段真实配置。这是Vault的HCL配置文件，ha_enabled一定要打开，storage指向Consul。

# vault-config.hcl
storage "consul" {
  address = "127.0.0.1:8500"
  path    = "vault/"
  ha_enabled = "true"
  # 记得配置服务发现，我习惯用 consul_service
  service = "vault"
}

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = 0
  tls_cert_file = "/etc/vault.d/certs/vault.crt"
  tls_key_file  = "/etc/vault.d/certs/vault.key"
}

api_addr     = "https://vault.example.com:8200"
cluster_addr = "https://10.0.1.10:8201"  # 内网通信地址

seal "shamir" {
  secret_shreshold = 3
  secret_shares    = 5
}

ui = true

3.6 避坑指南：我踩过的三个大坑

聊到高可用，有几个坑我得提前跟你说清楚。这些都是真金白银换来的教训。

1. 单点解封问题：如果你只用Shamir Seals，且密钥托管在磁盘上，那解封就是单点。我的做法是：加上auto-unseal，可以用云KMS或者另一个Vault集群来解封。别把所有鸡蛋放一个篮子里。
2. 集群脑裂：网络分区时，Consul可能会踢掉一个节点，Vault自动切换到另一个。但如果你后面挂的是数据库而不是Consul，脑裂概率极高。所以，存储后端一定要用强一致性的。
3. 日志满盘：Vault的审计日志默认不轮转。我曾经在一个项目里，审计日志直接把磁盘写满，集群挂了。后来我用logrotate做自动截断，才解决。