第二章：金融云总体架构设计

好，咱们进入正题。金融云的架构设计，说白了就是回答三个问题：怎么分层、选什么组件、怎么保证不出事。我做了这么多年金融系统，见过太多「看起来很美」的架构图，一上线就崩。今天我把自己的经验摊开来讲。

2.1 分层架构设计原则

金融云的分层，我习惯按「四层两域」来切。为什么是四层？因为每一层都有明确的职责边界，出了问题能快速定位。

层级	职责	我踩过的坑
接入层	统一入口、协议转换、流量控制	曾经把SSL卸载放在业务层，结果CPU飙到90%
应用层	业务逻辑、服务编排、状态管理	无状态设计一开始没做，后来扩容成了噩梦
数据层	事务处理、数据持久化、缓存加速	分库分表策略没提前规划，半年后重构代价巨大
基础设施层	计算、存储、网络、安全	网络规划没留余量，后期IP地址不够用

这里有个关键原则：每一层只能跟相邻层通信。你想想看，如果应用层直接操作物理机，那还要基础设施层干嘛？我在一个项目中见过业务代码里直接写IP地址，后来机房迁移，改代码改到崩溃。

2.2 金融云逻辑架构图

下面这张图是我自己画的，基本覆盖了金融云的核心模块。注意看，我把「安全域」和「运维域」单独拎出来了——这是金融行业的特殊要求。

嗯，这里要注意：安全域不是一层，而是贯穿所有层的。我在一个银行项目里，就因为安全策略没跟应用层对齐，导致一个合规漏洞被罚了200万。从那以后，我要求安全团队必须参与每一层的架构评审。

2.3 核心组件选型

选型这事儿，我个人的经验是：别追新，要追稳。金融行业最怕什么？怕供应商跑路、怕社区停更、怕出了安全问题没人修。

计算选型

• 容器编排：Kubernetes 是事实标准，别想了。我推荐用 Rancher 或 OpenShift 做管理平台，别自己从头搭。
• 服务网格：Istio 虽然重，但金融场景需要它的流量管理和安全策略。我曾经试过 Linkerd，轻是轻，但功能不够用。
• 无服务器：Knative 可以上，但只适合非核心业务。核心交易系统别碰，冷启动延迟你受不了。

存储选型

类型	推荐方案	我的建议
块存储	Ceph / 商业SAN	核心数据库用商业SAN，别省这个钱
对象存储	MinIO / 商业S3	日志、备份用MinIO就够了
文件存储	NFS / GlusterFS	共享配置用NFS，简单可靠

网络选型

金融云的网络，我建议用 Overlay + Underlay 混合模式。Overlay 用 Calico 或 Cilium，Underlay 用 BGP 协议。为什么？

• Overlay 方便虚拟机迁移，不影响IP地址
• Underlay 性能好，适合高频交易场景
• 两者结合，灵活性和性能都有了

2.4 高可用与容灾设计思路

金融系统的高可用，不是「尽量不挂」，而是「挂了也能自动恢复」。我参与过几个核心交易系统的容灾设计，总结下来就三句话：冗余、隔离、自动化。

高可用设计

• 计算高可用：K8s 的 Pod 反亲和性 + 多可用区部署。我习惯每个服务至少3个副本，分布在不同的物理机上。
• 存储高可用：数据库用主从+半同步复制，缓存用 Redis Sentinel 或 Cluster。注意：主从切换一定要自动化，别等人去敲命令。
• 网络高可用：多网卡绑定 + BGP 多路径。我曾经见过一个案例，因为单网卡故障导致整个集群失联，后来加了 bonding 再也没出过问题。

容灾设计

容灾分三个级别，我直接说结论：

级别	RTO	RPO	实现方式
同城双活	< 1分钟	0	数据库强同步 + 流量双写
异地灾备	< 15分钟	< 5秒	异步复制 + 自动切换
两地三中心	< 30分钟	< 1分钟	同城双活 + 异地备份

最后说一句：容灾设计不是技术问题，是成本问题。你想想看，RPO=0 意味着什么？意味着所有写操作都要跨机房同步，网络延迟至少增加2毫秒。对于高频交易系统，这2毫秒可能就是几百万的损失。所以，容灾方案一定要跟业务方一起定，别自己拍脑袋。

---

公众号:蓝海资料掘金营，微信deep3321