本文是《AI云原生实战调研》系列第五篇。上一篇我们聊了GPU调度的MIGTime Slicing方案这一篇我们走进金融行业——一个把稳字刻进骨髓、出一次事故就可能上315的领域。目录目录目录开篇那个差点上315的凌晨一、金融AI的核心需求不是性能是确定性二、腾讯云TCE银行风控平台整体架构三、K8s Namespace隔离不是分个名字就完了问题出在哪正确的金融级隔离应该是四层四、数据加密与合规PCI-DSS和等保三级不是贴在墙上的4.1 数据全链路加密TCE的三层防护4.2 等保三级 PCI-DSS 在云原生里的对照表五、南北向东西向流量管控金融网络安全的双刃剑5.1 南北向层层安检的Ingress5.2 东西向mTLS AuthorizationPolicy 双重防护六、高可用多AZ部署全年停机不能超过26分钟6.1 反亲和 拓扑分布约束6.2 故障转移时序七、HPA弹性扩缩双11级别的流量洪峰怎么扛7.1 多指标组合 快扩慢缩八、金丝雀发布模型更新零事故的五个阶段8.1 五阶段金丝雀流程8.2 金丝雀发布各阶段一览九、完整落地清单十、写在最后金融AI的慢哲学开篇那个差点上315的凌晨2024年3月某股份制银行信用卡中心凌晨2:47。风控值班群里突然炸了——风控引擎的P99延迟从42ms飙到了870ms。而正常交易的风控超时阈值是500ms。这意味着什么意味着大量正常交易在超时后被直接放行——没有经过任何风控检查。相当于银行金库的安检门突然断电所有人直接被放了进去。运维紧急排查后发现运维凌晨在做数据库索引优化大量写入导致TDSQL主库延迟飙升风控引擎的模型推理结果无法写入Redis缓存只能等数据库——而数据库这时候正在重建索引一个查询要等800ms。好消息是那天的异常交易不多。坏消息是问题不是因为恶意攻击而是因为自己人的一次凌晨运维。这就是金融AI最残酷的地方——你不是在和黑客斗你是在和自己的运维操作、网络抖动、硬件故障、代码Bug斗。任何一个环节出问题后果就是真金白银的损失。今天这篇我们就来拆一个真实的生产级方案——基于腾讯云TCE的银行智能风控平台。从Namespace隔离到mTLS加密从多AZ高可用到金丝雀发布——完整YAML配置、真实踩坑经验一次性给你。一、金融AI的核心需求不是性能是确定性先问你一个问题互联网公司的风控延迟标准是多少200ms300ms差不多。那银行的风控延迟标准呢答案是P99 ≤ 50ms。而且规则不是尽量是必须。为什么差距这么大因为互联网支付失败用户最多骂一句卡了重新刷。银行支付失败用户一个投诉电话打到银监会这事就可能变成监管事件。所以金融AI和互联网AI的本质区别不是模型更大、数据更多——而是对确定性的要求不在一个次元维度互联网AI金融AI延迟目标P99 200ms尽力而为P99 50ms强制要求可用性99.9%99.995%全年≤26分钟误杀代价用户体验下降客户投诉 监管关注发布时间随时灰度几分钟审批流程 金丝雀 72小时模型可解释性“效果好就行”必须能解释每一个拒贷理由安全审批基础渗透测试等保三级 PCI-DSS 红蓝对抗⚠️血泪教训很多技术团队第一次做金融项目上来就问模型AUC多少第二个问题问GPU集群配多大。但金融客户先问的是——“你这个系统一年能停机几分钟数据加密用的是国密还是AES审计日志保留多久”如果你答不上来这三个问题后面的演示都不用做了。核心认知金融AI不是技术竞赛是合规竞赛。技术是基础分合规才是及格线。二、腾讯云TCE银行风控平台整体架构先看全景。腾讯云TCETencent Cloud Enterprise在银行智能风控场景下的部署架构graph TB subgraph 接入层[ 接入层 - 多AZ流量入口] SLB[CLB负载均衡br/跨AZ-A/AZ-B/AZ-Cbr/健康检查5s一次] WAF[WAF防火墙br/SQL注入/XSS/CCbr/自定义风控规则] APIGW[API网关br/限流10000 QPSbr/JWT鉴权] end subgraph K8s[ TCE托管K8s集群 (v1.28)] subgraph ns_prod[Namespace: tce-risk-prod] ENGINE[风控引擎Deploymentbr/Replicas: 6br/跨3个AZ反亲和] TRITON[Triton推理服务br/GPU: T4 x4br/INT8量化模型] RULES[Drools规则引擎br/500风控规则br/实时热加载] end subgraph ns_gray[Namespace: tce-risk-gray] ENGINE_C[风控引擎(金丝雀)br/Replicas: 1br/流量: 5%] end subgraph ns_dev[Namespace: tce-risk-dev] DEV[开发环境br/ResourceQuota限制br/CPU限额: 16核] end end subgraph 数据层[ 数据层] KAFKA[CKafka消息队列br/交易流水实时接入br/10万TPS] FLINK[Oceanus实时计算br/CEP复杂事件处理br/滑动窗口聚合] REDIS[CRedis缓存br/命中率 99.2%br/延迟 1ms] TDSQL[TDSQL分布式库br/3AZ 3副本br/强一致同步] end subgraph AI平台[ AI平台 TI-ONE] TRAIN[模型训练GPU集群br/XGBoost/DeepFM/PLEbr/天级增量训练] REGISTRY[模型注册中心br/版本管理审批流br/AUC/KS自动对比] EVAL[模型评估br/PSI稳定性监控br/特征偏移告警] end subgraph 安全[ 安全合规] KMS[密钥管理KMSbr/国密SM4AES-256br/密钥自动轮转] AUDIT[CloudAudit审计br/全链路操作留痕br/日志保留180天] ENCRYPT[透明加密br/存储传输使用br/三不原则] end SLB -- WAF -- APIGW APIGW -- ENGINE APIGW -- ENGINE_C ENGINE -- TRITON ENGINE -- RULES ENGINE -- REDIS TRITON -- REDIS KAFKA -- FLINK FLINK -- REDIS FLINK -- TDSQL ENGINE -- KAFKA TRAIN -- REGISTRY REGISTRY -- EVAL REGISTRY -- TRITON KMS -.- ENCRYPT AUDIT -.- ENGINE style ns_prod fill:#e8f5e9,stroke:#2e7d32 style ns_gray fill:#fff8e1,stroke:#f57f17 style ns_dev fill:#e3f2fd,stroke:#1565c0 style 安全 fill:#fce4ec,stroke:#c62828看懂这张图说三个关键点。第一流量链路是命脉。交易请求从CLB进来到风控决策出去整个链路要求在50ms内完成。任何一个环节的抖动——数据库慢查询、Redis热点Key、GC停顿——都会直接体现在P99延迟上。所以你看图中的数据层CKafka做异步解耦、CRedis做毫秒级缓存、Flink做实时特征计算——每一层都是为确定性低延迟服务的。第二三个Namespace对应三种隔离等级。prod是纯生产环境gray是金丝雀灰度区dev是开发测试。这三个环境之间通过NetworkPolicy严格隔离——dev环境的一个测试Pod永远摸不到prod的数据。第三安全合规不是事后补丁是和业务系统同层设计的一等公民。KMS、CloudAudit、透明加密——这些都是基础设施级别的东西不是上完线再配的。架构心得很多人画架构图喜欢堆组件好像组件越多越厉害。但在金融场景下架构的好坏不取决于你用了多少花哨的东西而是每增加一个组件你能否说清楚它对P99延迟、可用性、安全性的影响。如果你说不清楚那这个组件就不该加。三、K8s Namespace隔离不是分个名字就完了好现在来聊一个最容易被忽视、但出了事就致命的话题——Namespace隔离。很多团队对Namespace隔离的理解停留在kubectl create ns prod、kubectl create ns dev搞定。问题出在哪有一天开发环境的小王在写一个数据迁移脚本需要连数据库。他复制了生产环境的ConfigMap配置因为公司Wiki上只贴了生产的连接信息改了个表名准备在dev环境跑。结果——他忘了改Namespace。kubectl apply -f migration-job.yaml默认打到了default命名空间但default被配置了生产集群的网络访问权限。脚本跑了40秒truncate了生产库的一张从表。虽然是从表、虽然从库、虽然数据后来从主库恢复了。但你想象一下如果你的Namespace隔离做对了这个脚本连数据库的TCP连接都建不起来因为NetworkPolicy直接拒绝了跨Namespace的流量。这就是金融环境里Namespace隔离的意义——不是防坏人是防好人犯错误。正确的金融级隔离应该是四层# 第一层Namespace ResourceQuota资源隔离 apiVersion: v1 kind: Namespace metadata: name: tce-risk-prod labels: environment: production >四、数据加密与合规PCI-DSS和等保三级不是贴在墙上的金融行业有两条红线绝对不能碰PCI-DSS支付卡数据安全标准和等保三级。每年审计时审计员不会问你你用了什么加密算法他们假设你会用AES-256而是会问——“过去180天所有访问过生产数据库的操作记录给我拉出来。”一句话问倒一半团队。4.1 数据全链路加密TCE的三层防护# TCE KMS etcd加密 apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets - configmaps # ConfigMap也可能存敏感配置一并加密 providers: - kms: name: tce-kms-provider endpoint: unix:///var/run/kmsplugin/socket.sock cachesize: 1000 timeout: 3s - identity: {} # ⚠️ 仅过渡期保留生产必须移除 --- # 应用层统一的敏感数据脱敏规则 apiVersion: v1 kind: ConfigMap metadata: name:>4.2 等保三级 PCI-DSS 在云原生里的对照表合规要求云原生落地方案TCE对应能力卡号脱敏PCI 3.4ConfigMap统一脱敏规则WAF 安全组Web应用防护PCI 6.6WAF RASPTCE WAFblock模式最小权限PCI 7.1RBAC PodSecurityContextTKE RBAC CAM双因素认证PCI 8.3运维VPN 堡垒机MFATCE堡垒机审计日志PCI 10.2CloudAudit全量操作记录日志保留180天入侵检测PCI 11.4Falco运行时检测SOC安全运营中心数据加密等保三KMS TDE mTLS国密SM4/AES-256审计小抄每次等保三级复审前先把这三个命令跑通基本能过一半的检查项kubectl get events --all-namespaces --sort-by.lastTimestamp | tail -100集群事件cloudaudit lookup-events --lookup-attributes AttributeKeyEventName,AttributeValueDeleteDBInstance高危操作回溯kubectl auth can-i create pods --assystem:serviceaccount:tce-risk-dev:default -n tce-risk-prod权限校验期望结果是no五、南北向东西向流量管控金融网络安全的双刃剑K8s网络流量分两路南北向North-South外面请求进来 → Ingress → Service → Pod东西向East-WestPod A 调 Pod B服务间内部调用互联网公司通常只关注南北向配个Ingress就完事了但在金融行业东西向才是真正的盲区。大多数内部安全事件不是外部攻击而是——一个已经被入侵的Pod在集群内部做横向移动。5.1 南北向层层安检的Ingress# 南北向IngressWAF 限流 SSL策略 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: risk-api-ingress namespace: tce-risk-prod annotations: # TCE WAF 接入 qcloud-waf.enable: true qcloud-waf.domain: risk-api.bank.com qcloud-waf.mode: block # ⚠️ observe改block才生效 # 七层限流基于CLB qcloud-clb.rate-limit: | {default:{qps:10000,burst:20000},source-ip:{qps:100,burst:200}} # TLS最低版本策略禁止TLS 1.0/1.1 qcloud-clb.ssl-policy: TLSv1.2-TLSv1.3 qcloud-clb.cipher-suite: ECDHE-RSA-AES256-GCM-SHA384 # 请求体大小限制防大包攻击 nginx.ingress.kubernetes.io/proxy-body-size: 8m nginx.ingress.kubernetes.io/proxy-read-timeout: 30 nginx.ingress.kubernetes.io/proxy-send-timeout: 30 spec: ingressClassName: nginx tls: - hosts: - risk-api.bank.com secretName: risk-api-tls-cert rules: - host: risk-api.bank.com http: paths: - path: /api/v1/risk/check pathType: Prefix backend: service: name: risk-engine-svc port: number: 80805.2 东西向mTLS AuthorizationPolicy 双重防护# 东西向Istio STRICT mTLS apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: strict-mtls namespace: tce-risk-prod spec: mtls: mode: STRICT # 拒绝一切明文连接连kubelet探针都走TLS --- # 东西向细粒度调用白名单 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: risk-engine-access-control namespace: tce-risk-prod spec: selector: matchLabels: app: risk-engine action: ALLOW rules: # 只有API Gateway能调风控接口 - from: - source: principals: [cluster.local/ns/tce-risk-prod/sa/api-gateway] to: - operation: methods: [POST] paths: [/api/v1/risk/check] # 只有模型服务能读取特征数据 - from: - source: principals: [cluster.local/ns/tce-risk-prod/sa/model-serving] to: - operation: methods: [GET] paths: [/api/v1/features/*] # 审计服务只读访问日志 - from: - source: principals: [cluster.local/ns/tce-risk-prod/sa/audit-collector] to: - operation: methods: [GET] paths: [/api/v1/logs/*]⚠️现实暴击PeerAuthentication STRICT模式下你Prometheus的健康检查会直接挂。因为Prometheus默认发的是HTTP明文不是HTTPS。两个解决方案(1)给Prometheus ServiceAccount加例外(2)开启Istio的PERMISSIVE模式作为过渡最终切STRICT。我们的做法是先PERMISSIVE跑一个月统计所有明文连接逐一整改最后切STRICT——零事故。核心认知南北向解决外面的人能不能进来东西向解决进来之后能摸哪些东西。大多数安全事件的真实路径是外部漏洞入侵 → 获取低权限Pod → 东西向横向移动 → 摸到数据库。横向移动才是攻击链条中最致命的那一步。六、高可用多AZ部署全年停机不能超过26分钟银行核心系统的高可用要求是99.995%。简单算一下365天 × 24小时 × 60分钟 × (1 - 0.99995) 26.28分钟。一年只能停26分钟。这包括计划内停机和计划外故障。6.1 反亲和 拓扑分布约束# 多AZ高可用Deployment apiVersion: apps/v1 kind: Deployment metadata: name: risk-engine namespace: tce-risk-prod labels: app: risk-engine tier: critical spec: replicas: 6 # 3个AZ × 2副本 strategy: type: RollingUpdate rollingUpdate: maxSurge: 2 # 滚动时多2个Pod maxUnavailable: 1 # ⚠️ 金融场景这个值必须是1 selector: matchLabels: app: risk-engine template: metadata: labels: app: risk-engine tier: critical spec: # 反亲和Pod必须分散在不同主机 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: [risk-engine] topologyKey: kubernetes.io/hostname preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: [risk-engine] topologyKey: topology.kubernetes.io/zone # 拓扑分布约束K8s 1.27 # 确保Pod均匀分布在3个AZ topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: risk-engine # 固定调度到金融专区节点 nodeSelector: node-type: financial-computing containers: - name: risk-engine image: tce-registry.tencentcloudcr.com/risk/engine:v3.2.1 ports: - containerPort: 8080 name: http - containerPort: 9090 name: metrics # ⚠️ 金融级健康检查参数比一般应用严3倍 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 # Java应用给足启动时间 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 5 # 5次连续失败才重启防误杀 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 15 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 3 # /ready 接口内部做了什么 # 1. 检查TDSQL连接池是否正常 # 2. 检查Redis连接是否正常 # 3. 检查模型服务gRPC调用是否可达 # 4. 返回200 → 加入到Service Endpoints # 优雅终止给进行中的请求画句号 lifecycle: preStop: exec: command: [/bin/sh, -c, sleep 15] env: - name: JAVA_OPTS value: - -Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis50 # GC暂停不超过50ms -XX:HeapDumpOnOutOfMemoryError resources: requests: cpu: 4 memory: 8Gi limits: cpu: 8 memory: 12Gi6.2 故障转移时序sequenceDiagram participant Client as 客户端 participant DNS as DNS/GSLB participant CLB as ⚖️ 跨AZ CLB participant AZ_A as AZ-A Pod participant AZ_B as AZ-B Pod participant Monitor as Prometheus Note over AZ_A,AZ_B: 三个AZ各2个Pod正常工作 Client-DNS: 解析 risk-api.bank.com DNS--Client: 返回CLB VIP Client-CLB: POST /api/v1/risk/check CLB-AZ_A: 健康检查通过轮询转发 AZ_A--CLB: 200 OK (38ms) CLB--Client: 返回风控结果 rect rgb(255,235,238) Note over AZ_A: AZ-A 电力故障交换机宕机 AZ_A--xCLB: 健康检查连续3次失败 Monitor-Monitor: 告警AZ-A全部Pod NotReady CLB-CLB: 自动摘除AZ-A全部后端 CLB-AZ_B: 100%流量切换至AZ-B Note over AZ_B: AZ-B承接全部流量br/HPA触发扩容 end rect rgb(232,245,233) Note over AZ_A: ✅ AZ-A电力恢复 AZ_A-CLB: 健康检查恢复 CLB-CLB: 自动加回AZ-A后端 Note over AZ_A,AZ_B: 流量重新均衡各33.3% end Client-CLB: POST /api/v1/risk/check CLB-AZ_A: 恢复正常转发 AZ_A--CLB: 200 OK (42ms) CLB--Client: 返回风控结果 Note over Client: 全程用户无感知⚠️反亲和的大坑requiredDuringScheduling要求Pod不在同一个hostname上但如果你只有2个节点第3个Pod会永远Pending。而且maxSkew: 1whenUnsatisfiable: DoNotSchedule意味着如果某个AZ只有一个节点、其他AZ有两个调度器会认为就算调度了也会违反均匀分布干脆不调度。所以反亲和规则不是写了就完事一定要检查节点数量能不能满足分布要求。七、HPA弹性扩缩双11级别的流量洪峰怎么扛金融交易有明显的峰谷效应工作日上午9-11点是流量高峰工资到账、理财申购凌晨2-5点是低谷。双11期间峰值可能是平时的15倍。HPA怎么配7.1 多指标组合 快扩慢缩# HPA四维指标驱动弹性 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: risk-engine-hpa namespace: tce-risk-prod spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: risk-engine minReplicas: 6 maxReplicas: 30 metrics: # 指标1: CPU使用率 - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 # 指标2: 内存使用率 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 70 # 指标3: P99延迟自定义Prometheus指标 - type: Pods pods: metric: name: http_request_duration_p99_ms target: type: AverageValue averageValue: 80 # P99超过80ms触发扩容 # 指标4: 单Pod TPS自定义业务指标 - type: Pods pods: metric: name: risk_check_tps target: type: AverageValue averageValue: 3000 # 单Pod超过3000TPS扩容 # ⚠️ 关键配置扩容要快缩容要慢 behavior: scaleUp: stabilizationWindowSeconds: 60 # 60秒稳定窗口 policies: - type: Percent value: 100 periodSeconds: 60 - type: Pods value: 10 periodSeconds: 60 selectPolicy: Max # 取扩容最多的策略 scaleDown: stabilizationWindowSeconds: 600 # 10分钟稳定窗口 policies: - type: Percent value: 10 periodSeconds: 120 - type: Pods value: 2 periodSeconds: 120 selectPolicy: Min # 取缩容最少的策略 --- # KEDA ScaledObjectKafka消息积压驱动 apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: risk-engine-kafka-scaler namespace: tce-risk-prod spec: scaleTargetRef: name: risk-engine minReplicaCount: 6 maxReplicaCount: 30 triggers: - type: kafka metadata: bootstrapServers: ckafka-broker.tce-risk-prod:9092 consumerGroup: risk-engine-consumer topic: risk-check-requests lagThreshold: 5000 # 积压超过5000条就扩容 activationLagThreshold: 1000 # 低于1000条不动金融HPA第一定律扩容要快缩容要龟速。扩容慢了→用户排队→投诉→银监会缩容快了→频繁震荡→Pod冷启动→GC预热→P99延迟抖动→继续扩容→死循环。所以看到那个scaleDown.stabilizationWindowSeconds: 600了吗它意味着HPA会等10分钟才决定缩不缩——这不是保守是血泪教训。⚠️指标选型陷阱千万别只挂CPU指标。金融应用是典型的IO密集型等数据库返回、等模型推理、等RedisCPU可能只有35%但用户已经在骂了。一定要挂业务指标——P99延迟、TPS、Kafka积压量。这些比CPU更能反映用户体验。八、金丝雀发布模型更新零事故的五个阶段AI模型的发布和传统软件不一样。传统软件回滚kubectl rollout undo→ 等30秒 → 恢复。AI模型回滚模型v2给1000个客户发了错误的风控评分 → 有人被误拒了贷款 →真金白银的损失已经发生了。所以金融AI的发布必须走金丝雀而且每个阶段的观察周期比普通应用长得多。8.1 五阶段金丝雀流程# 阶段1部署金丝雀Deployment apiVersion: apps/v1 kind: Deployment metadata: name: risk-engine-canary namespace: tce-risk-gray spec: replicas: 1 selector: matchLabels: app: risk-engine version: canary template: metadata: labels: app: risk-engine version: canary spec: containers: - name: risk-engine image: tce-registry.tencentcloudcr.com/risk/engine:v3.3.0-canary # ... 其他配置同生产 --- # 阶段2Header分流内部测试人员 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: risk-api-canary-header namespace: tce-risk-prod annotations: nginx.ingress.kubernetes.io/canary: true nginx.ingress.kubernetes.io/canary-by-header: x-risk-canary nginx.ingress.kubernetes.io/canary-by-header-value: v3.3.0 spec: rules: - host: risk-api.bank.com http: paths: - path: /api/v1/risk/check pathType: Prefix backend: service: name: risk-engine-canary-svc port: number: 8080 --- # 阶段3-5权重逐步放量 5%→20%→50%→100% # 只需改一行配置 # nginx.ingress.kubernetes.io/canary-weight: 5 → 20 → 50 → 1008.2 金丝雀发布各阶段一览阶段流量持续关键观察指标回滚条件1.Header分流内部人员4h功能正确性任何异常立即停2.权重5%真实流量5%24hP99延迟、错误率、风控通过率通过率偏离3%回滚3.权重20%真实流量20%48h模型AUC/KS、误杀率模型指标低于基线5%4.权重50%真实流量50%24h客诉量、交易成功率误杀率上升1%回滚5.权重100%全量-全量观察7天旧版本保留待命-# 金丝雀自动监控告警规则 apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: canary-alerts namespace: tce-risk-prod spec: groups: - name: canary-release rules: # 规则1金丝雀错误率超过1% → 告警 - alert: CanaryErrorRateSpike expr: | sum(rate(http_requests_total{versioncanary,status~5..}[5m])) / sum(rate(http_requests_total{versioncanary}[5m])) 0.01 for: 2m labels: severity: critical action: auto-rollback annotations: summary: 金丝雀错误率异常: {{ $value | humanizePercentage }} # 规则2风控通过率偏离基线3% → 人工介入 - alert: CanaryPassRateDeviation expr: | abs( sum(rate(risk_check_total{versioncanary,decisionpass}[15m])) / sum(rate(risk_check_total{versioncanary}[15m])) - sum(rate(risk_check_total{versionstable,decisionpass}[15m])) / sum(rate(risk_check_total{versionstable}[15m])) ) 0.03 for: 15m labels: severity: critical action: manual-review annotations: summary: ⚠️ 通过率偏差: {{ $value | humanizePercentage }} # 规则3P99延迟劣化1.5倍 → 人工介入 - alert: CanaryLatencyDegradation expr: | histogram_quantile(0.99, rate(http_request_duration_ms_bucket{versioncanary}[5m])) / histogram_quantile(0.99, rate(http_request_duration_ms_bucket{versionstable}[5m])) 1.5 for: 5m labels: severity: warning action: manual-review金丝雀第一定律宁可慢72小时不能快1小时酿事故。金融行业没有hotfix直接上生产这种操作——审批流程 金丝雀观察 至少3天。这不是官僚主义是风险管理。九、完整落地清单把前面八章串起来一个银行智能风控平台在腾讯云TCE上的完整落地清单序号领域关键技术点优先级说明1多环境隔离Namespace NetworkPolicy ResourceQuota RBAC P0四层全上缺一不可2数据加密KMS TDSQL TDE mTLS 应用层脱敏 P0存储/传输/使用三不原则3流量管控Ingress(WAF限流) Istio STRICT mTLS AuthZ P0南北向东西向都要管4高可用多AZ Pod反亲和 TopologySpread PDB P099.995%全年≤26分钟5弹性扩缩HPA(多指标) KEDA(Kafka积压) ClusterAutoscaler P1扩容快缩容慢6金丝雀发布五阶段渐进 Prometheus自动监控 自动回滚 P1最少3天观察期7合规审计CloudAudit Falco 等保三级 PCI-DSS P0日志保留≥180天8可观测性Prometheus Grafana ELK OpenTelemetry P1业务指标 基础设施指标十、写在最后金融AI的慢哲学做了这么多年金融AI我最大的感受是四个字克制比快重要。互联网的节奏是先上线不行再改——灰度5分钟出问题回滚。金融的节奏是想清楚测充分看三天再放量——你看到那些繁琐的审批流程、冗余的安全配置、看似影响效率的隔离策略都是无数金融事故换来的。K8s的NetworkPolicy因为有人用dev集群摸到了生产数据库。stabilizationWindowSeconds: 600因为有人HPA缩容太快导致服务雪崩。五阶段金丝雀发布因为有人模型v2上线后有0.3%的误杀率损失了几十万。所以下次有人跟你聊金融AI云原生不要只聊我们用了K8s多厉害要聊——你们的流量管控能做到多细数据加密用的是国密还是AES金丝雀发布最短观察多久审计日志保留多长时间这些问题的答案才决定了你的系统能不能真正扛在银行核心业务上。下篇预告医疗行业AI云原生实战——阿里云ACK智能诊疗平台。我们将走进三甲医院看看如何在ACK上用Kata Containers安全沙箱搭建CT影像AI辅助诊断系统解决患者数据的隐私保护HIPAA/个人信息保护法、医疗AI的GPU混部调度、以及PACS系统的高并发阅片体验。340万用户、日均20万访问的智能审方系统是怎么扛住的下一篇揭晓。 本文为《AI云原生实战调研》系列第五篇。 往期回顾[01-AI云原生全景为什么75%的企业都在用混合云部署AI][02-Docker容器化AI模型从PyTorch到TensorFlow的最佳实践][03-Kubernetes管理AI工作负载Job/Deployment/StatefulSet怎么选][04-GPU资源调度深度实战NVIDIA MIG与Time Slicing与HAMi] 本文场景金融行业 · 腾讯云TCE · 银行智能风控平台 交流欢迎评论区说说你们团队做金融AI云原生踩过的坑。你遇到过最离谱的生产事故是什么⭐ 关注点赞收藏不迷路下一期医疗AI云原生Kata Containers安全沙箱 340万用户智能审方系统我们不见不散。️ 标签#金融AI #腾讯云TCE #智能风控 #Kubernetes #银行AI #云原生安全 #金丝雀发布
AI云原生实战05-金融AI上云最难的不是技术，是“不出事“——TCE银行风控架构拆解
本文是《AI云原生实战调研》系列第五篇。上一篇我们聊了GPU调度的MIGTime Slicing方案这一篇我们走进金融行业——一个把稳字刻进骨髓、出一次事故就可能上315的领域。目录目录目录开篇那个差点上315的凌晨一、金融AI的核心需求不是性能是确定性二、腾讯云TCE银行风控平台整体架构三、K8s Namespace隔离不是分个名字就完了问题出在哪正确的金融级隔离应该是四层四、数据加密与合规PCI-DSS和等保三级不是贴在墙上的4.1 数据全链路加密TCE的三层防护4.2 等保三级 PCI-DSS 在云原生里的对照表五、南北向东西向流量管控金融网络安全的双刃剑5.1 南北向层层安检的Ingress5.2 东西向mTLS AuthorizationPolicy 双重防护六、高可用多AZ部署全年停机不能超过26分钟6.1 反亲和 拓扑分布约束6.2 故障转移时序七、HPA弹性扩缩双11级别的流量洪峰怎么扛7.1 多指标组合 快扩慢缩八、金丝雀发布模型更新零事故的五个阶段8.1 五阶段金丝雀流程8.2 金丝雀发布各阶段一览九、完整落地清单十、写在最后金融AI的慢哲学开篇那个差点上315的凌晨2024年3月某股份制银行信用卡中心凌晨2:47。风控值班群里突然炸了——风控引擎的P99延迟从42ms飙到了870ms。而正常交易的风控超时阈值是500ms。这意味着什么意味着大量正常交易在超时后被直接放行——没有经过任何风控检查。相当于银行金库的安检门突然断电所有人直接被放了进去。运维紧急排查后发现运维凌晨在做数据库索引优化大量写入导致TDSQL主库延迟飙升风控引擎的模型推理结果无法写入Redis缓存只能等数据库——而数据库这时候正在重建索引一个查询要等800ms。好消息是那天的异常交易不多。坏消息是问题不是因为恶意攻击而是因为自己人的一次凌晨运维。这就是金融AI最残酷的地方——你不是在和黑客斗你是在和自己的运维操作、网络抖动、硬件故障、代码Bug斗。任何一个环节出问题后果就是真金白银的损失。今天这篇我们就来拆一个真实的生产级方案——基于腾讯云TCE的银行智能风控平台。从Namespace隔离到mTLS加密从多AZ高可用到金丝雀发布——完整YAML配置、真实踩坑经验一次性给你。一、金融AI的核心需求不是性能是确定性先问你一个问题互联网公司的风控延迟标准是多少200ms300ms差不多。那银行的风控延迟标准呢答案是P99 ≤ 50ms。而且规则不是尽量是必须。为什么差距这么大因为互联网支付失败用户最多骂一句卡了重新刷。银行支付失败用户一个投诉电话打到银监会这事就可能变成监管事件。所以金融AI和互联网AI的本质区别不是模型更大、数据更多——而是对确定性的要求不在一个次元维度互联网AI金融AI延迟目标P99 200ms尽力而为P99 50ms强制要求可用性99.9%99.995%全年≤26分钟误杀代价用户体验下降客户投诉 监管关注发布时间随时灰度几分钟审批流程 金丝雀 72小时模型可解释性“效果好就行”必须能解释每一个拒贷理由安全审批基础渗透测试等保三级 PCI-DSS 红蓝对抗⚠️血泪教训很多技术团队第一次做金融项目上来就问模型AUC多少第二个问题问GPU集群配多大。但金融客户先问的是——“你这个系统一年能停机几分钟数据加密用的是国密还是AES审计日志保留多久”如果你答不上来这三个问题后面的演示都不用做了。核心认知金融AI不是技术竞赛是合规竞赛。技术是基础分合规才是及格线。二、腾讯云TCE银行风控平台整体架构先看全景。腾讯云TCETencent Cloud Enterprise在银行智能风控场景下的部署架构graph TB subgraph 接入层[ 接入层 - 多AZ流量入口] SLB[CLB负载均衡br/跨AZ-A/AZ-B/AZ-Cbr/健康检查5s一次] WAF[WAF防火墙br/SQL注入/XSS/CCbr/自定义风控规则] APIGW[API网关br/限流10000 QPSbr/JWT鉴权] end subgraph K8s[ TCE托管K8s集群 (v1.28)] subgraph ns_prod[Namespace: tce-risk-prod] ENGINE[风控引擎Deploymentbr/Replicas: 6br/跨3个AZ反亲和] TRITON[Triton推理服务br/GPU: T4 x4br/INT8量化模型] RULES[Drools规则引擎br/500风控规则br/实时热加载] end subgraph ns_gray[Namespace: tce-risk-gray] ENGINE_C[风控引擎(金丝雀)br/Replicas: 1br/流量: 5%] end subgraph ns_dev[Namespace: tce-risk-dev] DEV[开发环境br/ResourceQuota限制br/CPU限额: 16核] end end subgraph 数据层[ 数据层] KAFKA[CKafka消息队列br/交易流水实时接入br/10万TPS] FLINK[Oceanus实时计算br/CEP复杂事件处理br/滑动窗口聚合] REDIS[CRedis缓存br/命中率 99.2%br/延迟 1ms] TDSQL[TDSQL分布式库br/3AZ 3副本br/强一致同步] end subgraph AI平台[ AI平台 TI-ONE] TRAIN[模型训练GPU集群br/XGBoost/DeepFM/PLEbr/天级增量训练] REGISTRY[模型注册中心br/版本管理审批流br/AUC/KS自动对比] EVAL[模型评估br/PSI稳定性监控br/特征偏移告警] end subgraph 安全[ 安全合规] KMS[密钥管理KMSbr/国密SM4AES-256br/密钥自动轮转] AUDIT[CloudAudit审计br/全链路操作留痕br/日志保留180天] ENCRYPT[透明加密br/存储传输使用br/三不原则] end SLB -- WAF -- APIGW APIGW -- ENGINE APIGW -- ENGINE_C ENGINE -- TRITON ENGINE -- RULES ENGINE -- REDIS TRITON -- REDIS KAFKA -- FLINK FLINK -- REDIS FLINK -- TDSQL ENGINE -- KAFKA TRAIN -- REGISTRY REGISTRY -- EVAL REGISTRY -- TRITON KMS -.- ENCRYPT AUDIT -.- ENGINE style ns_prod fill:#e8f5e9,stroke:#2e7d32 style ns_gray fill:#fff8e1,stroke:#f57f17 style ns_dev fill:#e3f2fd,stroke:#1565c0 style 安全 fill:#fce4ec,stroke:#c62828看懂这张图说三个关键点。第一流量链路是命脉。交易请求从CLB进来到风控决策出去整个链路要求在50ms内完成。任何一个环节的抖动——数据库慢查询、Redis热点Key、GC停顿——都会直接体现在P99延迟上。所以你看图中的数据层CKafka做异步解耦、CRedis做毫秒级缓存、Flink做实时特征计算——每一层都是为确定性低延迟服务的。第二三个Namespace对应三种隔离等级。prod是纯生产环境gray是金丝雀灰度区dev是开发测试。这三个环境之间通过NetworkPolicy严格隔离——dev环境的一个测试Pod永远摸不到prod的数据。第三安全合规不是事后补丁是和业务系统同层设计的一等公民。KMS、CloudAudit、透明加密——这些都是基础设施级别的东西不是上完线再配的。架构心得很多人画架构图喜欢堆组件好像组件越多越厉害。但在金融场景下架构的好坏不取决于你用了多少花哨的东西而是每增加一个组件你能否说清楚它对P99延迟、可用性、安全性的影响。如果你说不清楚那这个组件就不该加。三、K8s Namespace隔离不是分个名字就完了好现在来聊一个最容易被忽视、但出了事就致命的话题——Namespace隔离。很多团队对Namespace隔离的理解停留在kubectl create ns prod、kubectl create ns dev搞定。问题出在哪有一天开发环境的小王在写一个数据迁移脚本需要连数据库。他复制了生产环境的ConfigMap配置因为公司Wiki上只贴了生产的连接信息改了个表名准备在dev环境跑。结果——他忘了改Namespace。kubectl apply -f migration-job.yaml默认打到了default命名空间但default被配置了生产集群的网络访问权限。脚本跑了40秒truncate了生产库的一张从表。虽然是从表、虽然从库、虽然数据后来从主库恢复了。但你想象一下如果你的Namespace隔离做对了这个脚本连数据库的TCP连接都建不起来因为NetworkPolicy直接拒绝了跨Namespace的流量。这就是金融环境里Namespace隔离的意义——不是防坏人是防好人犯错误。正确的金融级隔离应该是四层# 第一层Namespace ResourceQuota资源隔离 apiVersion: v1 kind: Namespace metadata: name: tce-risk-prod labels: environment: production >四、数据加密与合规PCI-DSS和等保三级不是贴在墙上的金融行业有两条红线绝对不能碰PCI-DSS支付卡数据安全标准和等保三级。每年审计时审计员不会问你你用了什么加密算法他们假设你会用AES-256而是会问——“过去180天所有访问过生产数据库的操作记录给我拉出来。”一句话问倒一半团队。4.1 数据全链路加密TCE的三层防护# TCE KMS etcd加密 apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets - configmaps # ConfigMap也可能存敏感配置一并加密 providers: - kms: name: tce-kms-provider endpoint: unix:///var/run/kmsplugin/socket.sock cachesize: 1000 timeout: 3s - identity: {} # ⚠️ 仅过渡期保留生产必须移除 --- # 应用层统一的敏感数据脱敏规则 apiVersion: v1 kind: ConfigMap metadata: name:>4.2 等保三级 PCI-DSS 在云原生里的对照表合规要求云原生落地方案TCE对应能力卡号脱敏PCI 3.4ConfigMap统一脱敏规则WAF 安全组Web应用防护PCI 6.6WAF RASPTCE WAFblock模式最小权限PCI 7.1RBAC PodSecurityContextTKE RBAC CAM双因素认证PCI 8.3运维VPN 堡垒机MFATCE堡垒机审计日志PCI 10.2CloudAudit全量操作记录日志保留180天入侵检测PCI 11.4Falco运行时检测SOC安全运营中心数据加密等保三KMS TDE mTLS国密SM4/AES-256审计小抄每次等保三级复审前先把这三个命令跑通基本能过一半的检查项kubectl get events --all-namespaces --sort-by.lastTimestamp | tail -100集群事件cloudaudit lookup-events --lookup-attributes AttributeKeyEventName,AttributeValueDeleteDBInstance高危操作回溯kubectl auth can-i create pods --assystem:serviceaccount:tce-risk-dev:default -n tce-risk-prod权限校验期望结果是no五、南北向东西向流量管控金融网络安全的双刃剑K8s网络流量分两路南北向North-South外面请求进来 → Ingress → Service → Pod东西向East-WestPod A 调 Pod B服务间内部调用互联网公司通常只关注南北向配个Ingress就完事了但在金融行业东西向才是真正的盲区。大多数内部安全事件不是外部攻击而是——一个已经被入侵的Pod在集群内部做横向移动。5.1 南北向层层安检的Ingress# 南北向IngressWAF 限流 SSL策略 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: risk-api-ingress namespace: tce-risk-prod annotations: # TCE WAF 接入 qcloud-waf.enable: true qcloud-waf.domain: risk-api.bank.com qcloud-waf.mode: block # ⚠️ observe改block才生效 # 七层限流基于CLB qcloud-clb.rate-limit: | {default:{qps:10000,burst:20000},source-ip:{qps:100,burst:200}} # TLS最低版本策略禁止TLS 1.0/1.1 qcloud-clb.ssl-policy: TLSv1.2-TLSv1.3 qcloud-clb.cipher-suite: ECDHE-RSA-AES256-GCM-SHA384 # 请求体大小限制防大包攻击 nginx.ingress.kubernetes.io/proxy-body-size: 8m nginx.ingress.kubernetes.io/proxy-read-timeout: 30 nginx.ingress.kubernetes.io/proxy-send-timeout: 30 spec: ingressClassName: nginx tls: - hosts: - risk-api.bank.com secretName: risk-api-tls-cert rules: - host: risk-api.bank.com http: paths: - path: /api/v1/risk/check pathType: Prefix backend: service: name: risk-engine-svc port: number: 80805.2 东西向mTLS AuthorizationPolicy 双重防护# 东西向Istio STRICT mTLS apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: strict-mtls namespace: tce-risk-prod spec: mtls: mode: STRICT # 拒绝一切明文连接连kubelet探针都走TLS --- # 东西向细粒度调用白名单 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: risk-engine-access-control namespace: tce-risk-prod spec: selector: matchLabels: app: risk-engine action: ALLOW rules: # 只有API Gateway能调风控接口 - from: - source: principals: [cluster.local/ns/tce-risk-prod/sa/api-gateway] to: - operation: methods: [POST] paths: [/api/v1/risk/check] # 只有模型服务能读取特征数据 - from: - source: principals: [cluster.local/ns/tce-risk-prod/sa/model-serving] to: - operation: methods: [GET] paths: [/api/v1/features/*] # 审计服务只读访问日志 - from: - source: principals: [cluster.local/ns/tce-risk-prod/sa/audit-collector] to: - operation: methods: [GET] paths: [/api/v1/logs/*]⚠️现实暴击PeerAuthentication STRICT模式下你Prometheus的健康检查会直接挂。因为Prometheus默认发的是HTTP明文不是HTTPS。两个解决方案(1)给Prometheus ServiceAccount加例外(2)开启Istio的PERMISSIVE模式作为过渡最终切STRICT。我们的做法是先PERMISSIVE跑一个月统计所有明文连接逐一整改最后切STRICT——零事故。核心认知南北向解决外面的人能不能进来东西向解决进来之后能摸哪些东西。大多数安全事件的真实路径是外部漏洞入侵 → 获取低权限Pod → 东西向横向移动 → 摸到数据库。横向移动才是攻击链条中最致命的那一步。六、高可用多AZ部署全年停机不能超过26分钟银行核心系统的高可用要求是99.995%。简单算一下365天 × 24小时 × 60分钟 × (1 - 0.99995) 26.28分钟。一年只能停26分钟。这包括计划内停机和计划外故障。6.1 反亲和 拓扑分布约束# 多AZ高可用Deployment apiVersion: apps/v1 kind: Deployment metadata: name: risk-engine namespace: tce-risk-prod labels: app: risk-engine tier: critical spec: replicas: 6 # 3个AZ × 2副本 strategy: type: RollingUpdate rollingUpdate: maxSurge: 2 # 滚动时多2个Pod maxUnavailable: 1 # ⚠️ 金融场景这个值必须是1 selector: matchLabels: app: risk-engine template: metadata: labels: app: risk-engine tier: critical spec: # 反亲和Pod必须分散在不同主机 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: [risk-engine] topologyKey: kubernetes.io/hostname preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: [risk-engine] topologyKey: topology.kubernetes.io/zone # 拓扑分布约束K8s 1.27 # 确保Pod均匀分布在3个AZ topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: risk-engine # 固定调度到金融专区节点 nodeSelector: node-type: financial-computing containers: - name: risk-engine image: tce-registry.tencentcloudcr.com/risk/engine:v3.2.1 ports: - containerPort: 8080 name: http - containerPort: 9090 name: metrics # ⚠️ 金融级健康检查参数比一般应用严3倍 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 # Java应用给足启动时间 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 5 # 5次连续失败才重启防误杀 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 15 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 3 # /ready 接口内部做了什么 # 1. 检查TDSQL连接池是否正常 # 2. 检查Redis连接是否正常 # 3. 检查模型服务gRPC调用是否可达 # 4. 返回200 → 加入到Service Endpoints # 优雅终止给进行中的请求画句号 lifecycle: preStop: exec: command: [/bin/sh, -c, sleep 15] env: - name: JAVA_OPTS value: - -Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis50 # GC暂停不超过50ms -XX:HeapDumpOnOutOfMemoryError resources: requests: cpu: 4 memory: 8Gi limits: cpu: 8 memory: 12Gi6.2 故障转移时序sequenceDiagram participant Client as 客户端 participant DNS as DNS/GSLB participant CLB as ⚖️ 跨AZ CLB participant AZ_A as AZ-A Pod participant AZ_B as AZ-B Pod participant Monitor as Prometheus Note over AZ_A,AZ_B: 三个AZ各2个Pod正常工作 Client-DNS: 解析 risk-api.bank.com DNS--Client: 返回CLB VIP Client-CLB: POST /api/v1/risk/check CLB-AZ_A: 健康检查通过轮询转发 AZ_A--CLB: 200 OK (38ms) CLB--Client: 返回风控结果 rect rgb(255,235,238) Note over AZ_A: AZ-A 电力故障交换机宕机 AZ_A--xCLB: 健康检查连续3次失败 Monitor-Monitor: 告警AZ-A全部Pod NotReady CLB-CLB: 自动摘除AZ-A全部后端 CLB-AZ_B: 100%流量切换至AZ-B Note over AZ_B: AZ-B承接全部流量br/HPA触发扩容 end rect rgb(232,245,233) Note over AZ_A: ✅ AZ-A电力恢复 AZ_A-CLB: 健康检查恢复 CLB-CLB: 自动加回AZ-A后端 Note over AZ_A,AZ_B: 流量重新均衡各33.3% end Client-CLB: POST /api/v1/risk/check CLB-AZ_A: 恢复正常转发 AZ_A--CLB: 200 OK (42ms) CLB--Client: 返回风控结果 Note over Client: 全程用户无感知⚠️反亲和的大坑requiredDuringScheduling要求Pod不在同一个hostname上但如果你只有2个节点第3个Pod会永远Pending。而且maxSkew: 1whenUnsatisfiable: DoNotSchedule意味着如果某个AZ只有一个节点、其他AZ有两个调度器会认为就算调度了也会违反均匀分布干脆不调度。所以反亲和规则不是写了就完事一定要检查节点数量能不能满足分布要求。七、HPA弹性扩缩双11级别的流量洪峰怎么扛金融交易有明显的峰谷效应工作日上午9-11点是流量高峰工资到账、理财申购凌晨2-5点是低谷。双11期间峰值可能是平时的15倍。HPA怎么配7.1 多指标组合 快扩慢缩# HPA四维指标驱动弹性 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: risk-engine-hpa namespace: tce-risk-prod spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: risk-engine minReplicas: 6 maxReplicas: 30 metrics: # 指标1: CPU使用率 - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 # 指标2: 内存使用率 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 70 # 指标3: P99延迟自定义Prometheus指标 - type: Pods pods: metric: name: http_request_duration_p99_ms target: type: AverageValue averageValue: 80 # P99超过80ms触发扩容 # 指标4: 单Pod TPS自定义业务指标 - type: Pods pods: metric: name: risk_check_tps target: type: AverageValue averageValue: 3000 # 单Pod超过3000TPS扩容 # ⚠️ 关键配置扩容要快缩容要慢 behavior: scaleUp: stabilizationWindowSeconds: 60 # 60秒稳定窗口 policies: - type: Percent value: 100 periodSeconds: 60 - type: Pods value: 10 periodSeconds: 60 selectPolicy: Max # 取扩容最多的策略 scaleDown: stabilizationWindowSeconds: 600 # 10分钟稳定窗口 policies: - type: Percent value: 10 periodSeconds: 120 - type: Pods value: 2 periodSeconds: 120 selectPolicy: Min # 取缩容最少的策略 --- # KEDA ScaledObjectKafka消息积压驱动 apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: risk-engine-kafka-scaler namespace: tce-risk-prod spec: scaleTargetRef: name: risk-engine minReplicaCount: 6 maxReplicaCount: 30 triggers: - type: kafka metadata: bootstrapServers: ckafka-broker.tce-risk-prod:9092 consumerGroup: risk-engine-consumer topic: risk-check-requests lagThreshold: 5000 # 积压超过5000条就扩容 activationLagThreshold: 1000 # 低于1000条不动金融HPA第一定律扩容要快缩容要龟速。扩容慢了→用户排队→投诉→银监会缩容快了→频繁震荡→Pod冷启动→GC预热→P99延迟抖动→继续扩容→死循环。所以看到那个scaleDown.stabilizationWindowSeconds: 600了吗它意味着HPA会等10分钟才决定缩不缩——这不是保守是血泪教训。⚠️指标选型陷阱千万别只挂CPU指标。金融应用是典型的IO密集型等数据库返回、等模型推理、等RedisCPU可能只有35%但用户已经在骂了。一定要挂业务指标——P99延迟、TPS、Kafka积压量。这些比CPU更能反映用户体验。八、金丝雀发布模型更新零事故的五个阶段AI模型的发布和传统软件不一样。传统软件回滚kubectl rollout undo→ 等30秒 → 恢复。AI模型回滚模型v2给1000个客户发了错误的风控评分 → 有人被误拒了贷款 →真金白银的损失已经发生了。所以金融AI的发布必须走金丝雀而且每个阶段的观察周期比普通应用长得多。8.1 五阶段金丝雀流程# 阶段1部署金丝雀Deployment apiVersion: apps/v1 kind: Deployment metadata: name: risk-engine-canary namespace: tce-risk-gray spec: replicas: 1 selector: matchLabels: app: risk-engine version: canary template: metadata: labels: app: risk-engine version: canary spec: containers: - name: risk-engine image: tce-registry.tencentcloudcr.com/risk/engine:v3.3.0-canary # ... 其他配置同生产 --- # 阶段2Header分流内部测试人员 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: risk-api-canary-header namespace: tce-risk-prod annotations: nginx.ingress.kubernetes.io/canary: true nginx.ingress.kubernetes.io/canary-by-header: x-risk-canary nginx.ingress.kubernetes.io/canary-by-header-value: v3.3.0 spec: rules: - host: risk-api.bank.com http: paths: - path: /api/v1/risk/check pathType: Prefix backend: service: name: risk-engine-canary-svc port: number: 8080 --- # 阶段3-5权重逐步放量 5%→20%→50%→100% # 只需改一行配置 # nginx.ingress.kubernetes.io/canary-weight: 5 → 20 → 50 → 1008.2 金丝雀发布各阶段一览阶段流量持续关键观察指标回滚条件1.Header分流内部人员4h功能正确性任何异常立即停2.权重5%真实流量5%24hP99延迟、错误率、风控通过率通过率偏离3%回滚3.权重20%真实流量20%48h模型AUC/KS、误杀率模型指标低于基线5%4.权重50%真实流量50%24h客诉量、交易成功率误杀率上升1%回滚5.权重100%全量-全量观察7天旧版本保留待命-# 金丝雀自动监控告警规则 apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: canary-alerts namespace: tce-risk-prod spec: groups: - name: canary-release rules: # 规则1金丝雀错误率超过1% → 告警 - alert: CanaryErrorRateSpike expr: | sum(rate(http_requests_total{versioncanary,status~5..}[5m])) / sum(rate(http_requests_total{versioncanary}[5m])) 0.01 for: 2m labels: severity: critical action: auto-rollback annotations: summary: 金丝雀错误率异常: {{ $value | humanizePercentage }} # 规则2风控通过率偏离基线3% → 人工介入 - alert: CanaryPassRateDeviation expr: | abs( sum(rate(risk_check_total{versioncanary,decisionpass}[15m])) / sum(rate(risk_check_total{versioncanary}[15m])) - sum(rate(risk_check_total{versionstable,decisionpass}[15m])) / sum(rate(risk_check_total{versionstable}[15m])) ) 0.03 for: 15m labels: severity: critical action: manual-review annotations: summary: ⚠️ 通过率偏差: {{ $value | humanizePercentage }} # 规则3P99延迟劣化1.5倍 → 人工介入 - alert: CanaryLatencyDegradation expr: | histogram_quantile(0.99, rate(http_request_duration_ms_bucket{versioncanary}[5m])) / histogram_quantile(0.99, rate(http_request_duration_ms_bucket{versionstable}[5m])) 1.5 for: 5m labels: severity: warning action: manual-review金丝雀第一定律宁可慢72小时不能快1小时酿事故。金融行业没有hotfix直接上生产这种操作——审批流程 金丝雀观察 至少3天。这不是官僚主义是风险管理。九、完整落地清单把前面八章串起来一个银行智能风控平台在腾讯云TCE上的完整落地清单序号领域关键技术点优先级说明1多环境隔离Namespace NetworkPolicy ResourceQuota RBAC P0四层全上缺一不可2数据加密KMS TDSQL TDE mTLS 应用层脱敏 P0存储/传输/使用三不原则3流量管控Ingress(WAF限流) Istio STRICT mTLS AuthZ P0南北向东西向都要管4高可用多AZ Pod反亲和 TopologySpread PDB P099.995%全年≤26分钟5弹性扩缩HPA(多指标) KEDA(Kafka积压) ClusterAutoscaler P1扩容快缩容慢6金丝雀发布五阶段渐进 Prometheus自动监控 自动回滚 P1最少3天观察期7合规审计CloudAudit Falco 等保三级 PCI-DSS P0日志保留≥180天8可观测性Prometheus Grafana ELK OpenTelemetry P1业务指标 基础设施指标十、写在最后金融AI的慢哲学做了这么多年金融AI我最大的感受是四个字克制比快重要。互联网的节奏是先上线不行再改——灰度5分钟出问题回滚。金融的节奏是想清楚测充分看三天再放量——你看到那些繁琐的审批流程、冗余的安全配置、看似影响效率的隔离策略都是无数金融事故换来的。K8s的NetworkPolicy因为有人用dev集群摸到了生产数据库。stabilizationWindowSeconds: 600因为有人HPA缩容太快导致服务雪崩。五阶段金丝雀发布因为有人模型v2上线后有0.3%的误杀率损失了几十万。所以下次有人跟你聊金融AI云原生不要只聊我们用了K8s多厉害要聊——你们的流量管控能做到多细数据加密用的是国密还是AES金丝雀发布最短观察多久审计日志保留多长时间这些问题的答案才决定了你的系统能不能真正扛在银行核心业务上。下篇预告医疗行业AI云原生实战——阿里云ACK智能诊疗平台。我们将走进三甲医院看看如何在ACK上用Kata Containers安全沙箱搭建CT影像AI辅助诊断系统解决患者数据的隐私保护HIPAA/个人信息保护法、医疗AI的GPU混部调度、以及PACS系统的高并发阅片体验。340万用户、日均20万访问的智能审方系统是怎么扛住的下一篇揭晓。 本文为《AI云原生实战调研》系列第五篇。 往期回顾[01-AI云原生全景为什么75%的企业都在用混合云部署AI][02-Docker容器化AI模型从PyTorch到TensorFlow的最佳实践][03-Kubernetes管理AI工作负载Job/Deployment/StatefulSet怎么选][04-GPU资源调度深度实战NVIDIA MIG与Time Slicing与HAMi] 本文场景金融行业 · 腾讯云TCE · 银行智能风控平台 交流欢迎评论区说说你们团队做金融AI云原生踩过的坑。你遇到过最离谱的生产事故是什么⭐ 关注点赞收藏不迷路下一期医疗AI云原生Kata Containers安全沙箱 340万用户智能审方系统我们不见不散。️ 标签#金融AI #腾讯云TCE #智能风控 #Kubernetes #银行AI #云原生安全 #金丝雀发布
