CBDC Wiki

主题

08 · 扩容指南 ​

本章给出当前代码边界内可以成立的扩容判断，不把历史 5 万 TPS 方案当作已实现拓扑。

扩容矩阵 ​

组件横向扩展判断关键约束
Facade可扩无 Token 状态；认证缓存需保持可刷新；所有副本使用一致的 BizHub 与 Wallet Node 路由配置
Central可扩共享 cbdc_central；会话与 WebAuthn/审批语义由数据库保证
BizHub runtime/management可按服务面拆分并扩副本共享 cbdc_biz；mTLS 身份、方法角色、migration 顺序和 worker 重复执行需核实
Wallet Node有条件distributed selector 不等于无状态；Prepare/Submit pending store 和 finality 状态位于进程内
Auditor有条件身份与公共参数、AuditDB、审计请求路由、indexer shard/cursor 都需显式设计
Endorser有条件节点身份、公共参数部署、动态注册与请求路由需保持一致
Issuer业务上通常受控扩容发行权限、钱包与重复发行防护必须由部署策略约束
Orderer / Committer由 Fabric-X 拓扑决定不能把增加容器数直接等同于共识或提交吞吐线性增长

Facade ​

Facade 自身不保存 Token pending 状态，最适合先扩。负载均衡器必须保留 gRPC/HTTP 需要的 TLS 与请求头，并确保各副本都能访问：

  • BizHub 的认证资料与机构信息；
  • 同一组 Wallet Node shard 配置；
  • 相同的证书信任根。

当前 wallet.ShardOf 只返回单一 shard，Facade 会拒绝无法服务该 shard 的配置。不要在外部网关按钱包尾号自造另一套分片算法。

Wallet Node ​

可以共享的部分 ​

  • 使用 distributed Token Selector 时，选币协调可放到 Redis；
  • FSC/Token 持久化可按经过验证的数据库拓扑部署；
  • BizHub 配置与节点 resolver 可由各实例同步。

仍是实例本地的部分 ​

  • Prepare 阶段产生的 PendingTransactionStore；
  • Submit 后接管 selector 的 FinalityWorker 状态；
  • 部分本地缓存与 FSC runtime 状态。

因此多副本至少需要粘性路由、共享 pending store 或协议级实例提示之一。当前仓库没有提供通用的跨副本 pending store。

BizHub 与 Central ​

两者必须分库：BizHub 使用 cbdc_biz，Central 使用 cbdc_central。扩副本前：

  1. 先单独运行对应 migrate 命令；
  2. 保证所有副本使用同一 schema 版本；
  3. 汇总计算数据库连接数；
  4. 验证 settlement/indexer 等后台 worker 的并发领取语义；
  5. 不要让 Central 直接连 cbdc_biz 代替 management RPC。

BizHub 可用 runtime 与 management mode 拆分服务面；空 mode 注册完整集合，all 无效。

Auditor 与 Endorser 的 Node Registry ​

Auditor、Endorser 启动时注册自身 P2P/View 地址；Issuer、Wallet Node 拉取它们的快照。增加 Auditor 或 Endorser 实例时，必须验证：

  • 每个实例使用可区分且受信任的节点身份；
  • BizHub registry 中的地址可从调用方实际网络到达；
  • TLS SAN 与拨号 host 匹配；
  • resolver 更新后业务路由符合预期。

仅注册多个地址并不能证明 Auditor 分片或高可用已经实现。

数据库和迁移 ​

开发环境可把多个数据库放在同一 PostgreSQL 实例中，但逻辑所有权仍然分离。生产扩容至少要分别规划：

  • Fabric-X ledger/state database；
  • 四类 FSC 节点数据库；
  • BizHub cbdc_biz；
  • Central cbdc_central；
  • Redis（若启用 distributed selector）。

迁移是显式步骤，不应依赖应用启动自动建表。

证书与 P2P ​

FSC P2P 使用 WebSocket + TLS。开发脚本生成的节点证书包含双向用途和节点域名/短名/localhost SAN；生产副本应为真实 DNS 名生成证书，避免所有副本复用同一私钥。

Wallet Node 的同一张节点证书还用于 FSC P2P 与访问 BizHub 的 mTLS 身份。证书轮换必须同时验证这两条链路。

推荐扩容顺序 ​

  1. 固化一套基准配置，记录 driver 与公共参数；
  2. 先扩无 Token pending 状态的 Facade；
  3. 分别压测 BizHub/Central 数据库与服务副本；
  4. 为 Wallet Node 设计并验证实例亲和；
  5. 再评估 Auditor、Endorser 和 Fabric-X 拓扑；
  6. 用 cbdc-stress 做端到端 finality 压测，而不是只测 RPC 返回。

上线前检查 ​

  • [ ] 使用 ./dev/cbdc-dev 或等价的明确编排入口，配置来源可追踪
  • [ ] 记录实际 Token driver 与 pp 文件
  • [ ] Facade 只暴露银行 API，不向客户端泄露 shard 路由
  • [ ] Wallet Node Prepare/Submit 具备实例亲和或共享状态
  • [ ] BizHub 与 Central 分库并分别完成 migration
  • [ ] Auditor/Endorser registry 地址与 TLS SAN 可达且匹配
  • [ ] Submit 成功与 ledger finality 使用不同指标
  • [ ] 容量结论来自目标环境压测，而不是历史规划数字

相关文档 ​