1. 课程导入

在银行交易系统中，数据契约的稳定性直接决定了支付、清算、风控、对账等关键链路能否安全运行。随着微服务化、分布式架构和实时数据管道的普及，交易报文格式频繁变更、上下游系统版本不一致、字段语义漂移等问题日益突出。Schema Registry 作为集中式数据契约管理基础设施，正是解决这类问题的核心抓手。本课程围绕银行交易场景，系统讲解 Schema Registry 的治理方法与实战落地路径。

一、学习目标：从“能注册”到“能治理”

本课程的学习目标分为四个层次，逐层递进：

• 认知层：理解 Schema Registry 在银行交易架构中的定位，掌握 Avro、Protobuf、JSON Schema 等主流格式的适用边界。
• 操作层：能够独立完成 Schema 注册、版本发布、兼容性检查、灰度回滚等日常操作。
• 治理层：建立兼容性策略、命名规范、审批流程、权限模型和审计机制，形成可执行的治理制度。
• 架构层：能够设计跨数据中心、多集群、多租户场景下的 Schema Registry 高可用与容灾方案。

二、核心价值：为什么银行交易必须治理 Schema

银行交易具有强一致性、高合规性和长链路依赖三大特征。一次跨行支付可能经过渠道系统、支付网关、核心账务、清算平台、对账系统等十余个节点，每个节点对交易报文的字段定义、类型、必填性都有严格要求。若缺乏统一 Schema 管理，常见后果包括：

• 上游新增字段导致下游反序列化失败，交易中断；
• 字段类型从 int 改为 long，历史数据无法解析；
• 同一字段在不同系统中语义不一致，对账差异难以定位；
• 版本回滚时找不到历史 Schema，故障恢复时间被拉长。

Schema Registry 的核心价值在于将“数据契约”从代码中剥离，变为可版本化、可审计、可兼容性校验的集中资产。它带来的直接收益包括：降低上下游联调成本、缩短故障定位时间、满足监管审计要求、支撑数据血缘与影响分析。

三、整体知识框架：四层治理模型

本课程将银行交易 Schema Registry 治理划分为四个层次，形成从底层存储到上层制度的完整框架：

四层之间并非孤立，而是相互支撑：存储层提供基础能力，版本层保障演进安全，治理层约束人为操作，架构层确保全局稳定。课程后续章节将逐层展开，并结合真实银行交易场景进行演练。

四、实战路线图：从单集群到多活治理

课程实战路线按照“先通后治、先单后多”的原则设计，共分为五个阶段：

1. 环境搭建：部署单节点 Schema Registry，配置 Kafka 集成，完成首个交易 Schema 注册。
2. 版本演练：模拟字段新增、删除、类型变更，观察不同兼容性模式下的检查结果。
3. 流程固化：引入 CI 流水线，将 Schema 兼容性检查嵌入代码合并请求，实现自动化卡点。
4. 治理落地：制定命名规范与审批矩阵，配置 RBAC 权限，开启审计日志。
5. 多活容灾：搭建双集群同步，验证跨数据中心故障切换与数据一致性。

docker compose up -d schema-registry kafka
curl -X POST http://localhost:8081/subjects/trade-payment-value/versions \
  -H "Content-Type: application/vnd.schemaregistry.v1+json" \
  -d '{"schema": "{\"type\":\"record\",\"name\":\"Payment\",\"fields\":[{\"name\":\"txnId\",\"type\":\"string\"}]}"}'
# 返回 {"id":1} 表示注册成功

五、常见误区与复盘要点

在过往银行客户实践中，以下误区最为高频，值得提前警惕：

• 误区一：兼容性模式设为 NONE。看似灵活，实则放任破坏性变更流入生产，最终导致下游批量故障。
• 误区二：只注册不治理。Schema 数量膨胀后无人维护，命名混乱、重复定义、废弃版本长期堆积。
• 误区三：忽略客户端缓存。Registry 故障时客户端无法获取 Schema，交易链路整体不可用。
• 误区四：多集群各自为政。缺乏同步机制，跨数据中心交易报文解析不一致，对账差异频发。