信息的“大动脉”。构建一个生产级集群，核心在于平衡就是在区块链、交易所和高吞吐日志场景中，Kafka 生存能力（高可用）、处理能力（吞吐量）与数据安全。
本文将带您一步步完成 Amazon MSK 的构建，重点解析在Express 代理模式下，如何通过**“先定数量，再定规格”**的科学方法进行精准选型。
第一阶段：基础架构决策 (Foundation)
进入 MSK 控制台，首先要确定集群的“地基”。
1. 创建方法：自定义构建 (Custom Create)
生产指令：必须选“自定义构建”。
运维逻辑：区块链业务对网络隔离要求极高。“快速创建”生成的默认 VPC 配置无法满足生产环境对私有子网和安全组的合规要求。
2. 集群类型：已预置 (Provisioned)
生产指令：选择 “已预置”。
运维逻辑：
可控性：区块链扫链（Indexer）流量通常是持续且平稳的。预置模式允许精细调整 Broker 参数（如
message.max.bytes），这对防止大区块写入失败至关重要。成本透明：对于 7x24 小时运行的核心链路，预置模式通常比 Serverless 更具性价比。
第二阶段：核心选型 (Selection Strategy) —— 先定骨架，再定肌肉
这是最关键的一步。在Express 代理模式下，由于计算与存储分离，选型逻辑变得非常纯粹：遵循**“3+1 法则”定骨架，再看“分区水位”**定肌肉。
1. 代理类型：Express 代理 (Express Brokers)
生产指令：锁定 Express 代理。
核心价值：
极速扩容：行情突变导致 TPS 翻倍时，Express 节点扩容只需几分钟，且无需数据再平衡 (Rebalance)。
吞吐量翻倍：相比 Standard 代理，吞吐量提升高达 3 倍。
免维护存储：全托管弹性存储，无需监控磁盘水位。
2. 定数量（The Skeleton）：确保“活着”
我们先不谈快慢，先谈集群的生存能力。
区数量 (Number of Zones)：
3逻辑：对应 AWS 的 3 个物理可用区 (AZ)。Kafka 依赖多数派选举，挂掉 1 个区，剩余 2 个区依然能正常工作，确保区块链业务 0 中断。
每个区的代理数 (Brokers per Zone)：
1逻辑：“最小高可用单元”。
计算：3 区 × 1 代理 =3 个节点。
策略：起步阶段不要浪费钱选 2 或 3。因为 Express 模式扩容极快，如果不够用，上线后再改成 2 也来得及。
3. 定规格（The Muscle）：决定“快慢”
骨架定好了（3 个节点），现在决定每个节点要长多壮。主要看芯片和分区上限。
芯片家族：认准
m7g(Graviton 3)。理由：ARM 架构在 Java 负载下比 Intel (
m5) 性能强 20% 且更便宜。
大小阶梯选择：
✅ 入门首选：
express.m7g.large配置：2 vCPU / 8 GiB 内存
能力：最大支持 1,000 分区。
场景：90% 的项目起点。足以支撑 5-10 条公链的数据同步。
⏫ 进阶升级：
express.m7g.xlarge配置：4 vCPU / 16 GiB 内存
能力：最大支持 1,000 分区（但处理延迟更低）。
场景：计算密集型。若是开启了高压缩比（Zstd）或 SSL 解密压力大导致 CPU 飙高，升级到该。
旗舰配置：
express.m7g.2xlarge配置：8 vCPU / 32 GiB 内存
能力：最大支持 2,500 分区。
场景：分区数突破 1000 时必须升级。适用于需要为成百上千个币对（Trading Pairs）开设独立 Topic 的大型交易所。
第三阶段：安全与网络 (Security & Networking)
1. 网络配置
子网：必须选择 3 个跨不同 AZ 的私有子网 (Private Subnets)。
安全组：配置入站规则，仅允许 EKS 集群网段访问9098 端口。
2. 访问控制：IAM 身份验证
生产指令：勾选 “基于 IAM 角色的身份验证”。
运维逻辑：
无密钥运维：Java Pod 利用 IAM Role 鉴权，代码不存密码。
细粒度权限：通过 JSON 策略精确控制谁能读写哪个 Topic。
审计：执行记录直连 CloudTrail，满足金融审计。
注意：启用 IAM 后，客户端连接端口为9098，且自动启用 TLS 加密。
3. 加密配置
静态加密：选择 AWS 托管的密钥 (AWS Managed Key)。除非合规部门强制要求使用 Customer Managed Key。
第四阶段：高级配置与监控 (Configuration)
1. 监控级别
生产指令：开启 Enhanced Monitoring (Per Broker)。
理由：默认监控太粗糙。开启后才能看到每个 Broker 的实际吞吐量，作为扩容依据。
2. 参数调优 (Cluster Configuration)
建议创建一个自定义配置组，重点修改：
auto.create.topics.enable = false：必须设为 false。防止开发代码写错导致产生大量垃圾 Topic。min.insync.replicas = 2：配合acks=all，确保数据至少落盘到 2 个机房才算成功，防止数据丢失。
总结：Express 集群“黄金公式”
如果您遵循上述指南，您将构建出如下配置的生产级集群：
| 维度 | 最终选型配置 | 核心价值 |
| 类型 | Provisioned (Express) | 存储计算分离，分钟级无痛扩容 |
| 骨架 (数量) | 3 区 × 1 代理 = 3 节点 | 满足物理 3AZ 容灾，成本最优 |
| 肌肉 (规格) | express.m7g.large | 1000 分区容量，高性价比 Graviton 芯片 |
| 安全 | IAM Auth (Port 9098) | 无密码管理，金融级审计与权限隔离 |
| 兜底策略 | 动态调整 | 上线后若不够用，可随时在控制台无缝升级规格或增加节点 |