1. 这不是画PPT，而是给AI系统搭骨架

“图解AI应用架构设计”这六个字，最近在技术社区里出现频率高得有点反常——不是因为某家大厂发布了新模型，而是越来越多一线团队发现：光有算法跑得快没用，模型一上线就卡在数据管道里；API接口明明写好了，前端调用却总超时；本地测试稳如老狗，部署到生产环境第二天就OOM。我去年帮某高校实验室重构一个智能阅卷系统时，第一周花在画架构图上的时间，比写代码还多。不是为了应付汇报，而是真得靠这张图，把算法、数据、服务、监控、权限五条线理清楚，否则后面每加一个功能，都在给系统埋雷。

这个标题里的“图解”，不是指用Visio拉几个方框配点箭头，而是用图形语言把抽象的依赖关系、数据流向、容错边界、扩展瓶颈全摊开来看。它解决的核心问题很实在：当一个AI项目从单机脚本走向多人协作、从Demo验证走向真实业务支撑时，怎么让所有人——算法工程师、后端开发、运维同学、甚至产品经理——在同一张图上看到同一个系统？关键词“AI应用架构”也划清了边界：它不讨论Transformer结构怎么优化，也不深挖CUDA核函数怎么写，而是聚焦在“模型如何被安全、稳定、可维护地用起来”这个落地层。适合三类人重点看：刚带AI项目的技术负责人，需要快速建立系统级认知；准备面试架构岗的中高级工程师，这类题现在几乎是必考；还有正在从纯算法岗转向工程化落地的算法同学，你写的模型再准，如果没人敢把它放进生产环境，价值就归零。

我见过太多团队踩的坑，都源于一张没画明白的架构图。比如某电商推荐模块，算法团队交付的是一个PyTorch模型文件和一份特征说明文档，后端同学直接封装成Flask接口，结果上线后发现特征计算耗时占整个请求的70%，而特征工程本该在离线层完成；又比如某医疗影像辅助诊断系统，架构图里没标出GPU显存隔离策略，结果多个科室并发调用时，一个科室的推理任务把显存占满，其他科室直接失败。这些都不是技术难题，而是架构沟通断层导致的。所以这篇内容，我会带你从一张白纸开始，用真实项目中的决策逻辑，拆解每一块组件为什么放在这里、为什么不放那里、数据流经这里会发生什么、故障发生时这张图能帮你快速定位到哪一层。没有虚概念，全是能抄、能改、能立刻用上的东西。

2. 架构设计不是选工具，而是定约束与画边界

2.1 为什么必须先画图，而不是先写代码？

很多人觉得架构设计是“高阶动作”，得等代码写到一半卡住了才回头补图。这是个危险误区。AI应用的特殊性在于它的不确定性远高于传统Web服务：模型输出可能漂移、数据质量会波动、推理延迟受硬件影响极大、用户行为反馈会倒逼模型迭代。这些不确定性如果不在架构层面设好缓冲区和熔断点，后期改起来成本极高。我参与过一个智能客服对话系统的重构，最初版本所有模块耦合在同一个Docker容器里——NLU模型、对话管理、知识库检索、日志上报全挤在一起。后来业务要求支持多轮对话状态持久化，团队花了三周时间把状态管理从内存硬改成Redis，结果发现日志上报模块因为强依赖本地磁盘路径，一迁就全挂。如果最开始的架构图里就用虚线框明确标出“状态存储层”和“可观测性层”，并注明它们与核心推理模块的通信协议（比如通过gRPC而非共享内存），这个改动根本不用动主流程。

画图的本质，是把隐性的技术债务显性化。当你在纸上画出“用户请求 → API网关 → 认证鉴权 → 特征服务 → 模型服务 → 结果后处理 → 响应返回”这条主线时，每个箭头背后都藏着一堆问题：认证鉴权是走JWT还是OAuth2？特征服务的数据源是实时Kafka还是离线Hive？模型服务的负载均衡策略是轮询还是按GPU显存分配？这些问题不提前定义，代码里就会出现各种if-else硬编码，最后变成谁都不敢动的祖传代码。所以我的经验是：架构图不是设计的终点，而是协作的起点。每次评审，我们不问“这个图美不美”，而是逐个节点问：“如果这个模块响应超时，上游怎么降级？”“如果这个数据源中断，下游用什么兜底？”“这个接口的QPS峰值是多少，当前设计能否扛住？”——答案写不出来的部分，就是架构图里要加粗标红的高风险区。

2.2 四层核心分层：为什么是这四层，而不是三层或五层？

市面上常见AI架构图有“数据层-模型层-服务层-应用层”的四分法，也有“基础设施-平台-算法-业务”的四分法。我坚持用“数据接入层-特征工程层-模型服务层-应用编排层”这个分层，是因为它严格对应AI应用的生命周期和职责分离原则。我们来拆解每一层不可替代的作用：

• 数据接入层：它的唯一使命是“把脏数据变干净，把异构数据变同构”。这里不碰任何业务逻辑，只做格式转换（JSON/CSV/Protobuf）、协议适配（HTTP/Kafka/MySQL Binlog）、基础清洗（空值填充、类型校验）。我见过最典型的错误，是把用户画像标签计算逻辑塞进这一层，结果导致数据管道延迟飙升。记住：这一层的SLA指标只有两个——数据到达延迟（<5秒）和数据准确率（>99.99%），其他都是越界。

• 特征工程层：这是AI架构里最容易被低估的一层。它负责把原始数据加工成模型能吃的“饲料”，包括统计特征（过去7天点击率）、时序特征（滑动窗口均值）、Embedding特征（用预训练模型生成）。关键约束是：所有特征必须可复现、可版本化、可回填。我们用Airflow调度特征计算任务，每个任务的输入数据源、SQL脚本、参数配置都存Git，版本号打在特征表名后缀上（如user_click_feat_v2_202405）。这样模型迭代时，能精确指定用哪个版本的特征，避免“训练用v1，线上用v2”的灾难。

• 模型服务层：它的核心挑战是平衡“性能”和“灵活性”。我们不用TensorFlow Serving那种重型框架，而是基于Triton Inference Server自建轻量服务，原因很实际：Triton原生支持多框架（PyTorch/TensorFlow/ONNX），能自动做TensorRT加速，更重要的是它的模型热更新机制——上传新模型文件，服务自动加载，旧请求走旧模型，新请求走新模型，完全无感。这一层的架构图里，必须标出GPU资源池的隔离策略（比如用Kubernetes Device Plugin按显存切分），否则多模型混部时必然互相干扰。

• 应用编排层：这是离用户最近、变化最频繁的一层。它不包含模型，只负责把多个模型服务、规则引擎、外部API像乐高一样组合起来。比如一个风控场景，可能需要先调用设备指纹模型，再查黑名单库，再跑一个LSTM时序模型，最后用决策树做终审。我们用Tempo（CNCF孵化项目）做编排，它的优势是YAML定义流程、支持条件分支、能自动追踪每个子任务的耗时和成功率。这一层的图示里，所有外部依赖（如Redis、MySQL）必须用不同颜色虚线框标出，并注明超时时间和重试策略——因为90%的线上故障，都源于这一层对下游的错误假设。

这四层不是静态的，而是有明确的数据契约。比如特征工程层输出的Parquet文件，必须包含schema.json描述字段类型和业务含义；模型服务层的gRPC接口，必须提供proto文件定义request/response结构。这些契约文件，就是架构图里那些箭头的法律依据。没有契约的连接，就是技术债的温床。

2.3 边界划定：哪些必须独立部署，哪些可以合并？

架构图里最考验功力的，是决定哪些组件必须物理隔离，哪些可以进程内共存。我的判断标准就一条：故障域是否重叠。举几个真实案例：

• 特征服务与模型服务必须分离：某次线上事故，特征服务因Kafka消费者位点异常，疯狂重拉历史数据，把整个集群CPU打满。如果它和模型服务部署在同一台机器，推理请求必然超时。现在我们强制特征服务独占节点，模型服务用GPU节点，网络层面用VPC子网隔离，故障影响面直接缩小80%。

• 在线推理与离线训练可以同集群，但必须资源配额隔离：我们用Kubernetes的ResourceQuota和LimitRange，给训练任务分配最高80% CPU，但禁止使用GPU；推理服务则固定分配2块V100，CPU限制在4核。这样即使训练任务突发占用大量CPU，也不会抢走推理服务的GPU显存。

• 日志采集与业务服务可以同进程，但必须异步非阻塞：早期我们用Log4j同步写磁盘，一次磁盘IO抖动导致整个API响应延迟从50ms飙到2秒。现在改用Loki+Promtail方案，业务代码只往本地ring buffer写日志，Promtail异步采集推送，完全不影响主流程。

• 配置中心必须独立，且跨环境强隔离：我们用Apollo，但严格规定：开发环境配置存dev namespace，测试环境存fat namespace，生产环境存prod namespace，三个namespace的管理员账号完全不重叠。曾经有次测试同学误操作，把prod的数据库密码覆盖成test的，结果因为namespace隔离，连test环境都没影响到。

这些边界决策，最终都会体现在架构图的物理部署框里。比如“特征工程层”下面会标注“独立K8s命名空间：feature-prod”，“模型服务层”旁边会写“GPU节点池：gpu-inference-v100”。图上每一个部署框，都对应着真实的运维SOP和权限矩阵。没有这些细节的架构图，就是一张漂亮的废纸。

3. 核心组件选型与实操细节：从原理到落地

3.1 数据接入层：Kafka + Flink的黄金组合为什么不可替代？

数据接入层看似简单，实则是整个AI流水线的“心脏起搏器”。我们放弃过纯HTTP API接收数据的方案，也试过用RabbitMQ做消息队列，最后坚定选择Kafka+Flink，原因非常具体：

• 吞吐与顺序的刚性需求：智能客服系统每秒要处理2万条用户消息，且同一会话ID的消息必须严格保序（否则NLU模型看到乱序的对话，理解必然出错）。Kafka的Partition机制天然支持按key（会话ID）分区，Flink的KeyedStream能保证单个key的所有事件在同一个TaskManager处理，彻底解决顺序问题。我们实测过，200个Partition的Kafka集群，配合8个TaskManager的Flink作业，稳定支撑3.5万QPS，端到端延迟中位数120ms。

• Exactly-Once语义的落地成本：AI场景最怕数据重复或丢失。Kafka的事务机制+Flink的Checkpoint机制，能实现端到端的Exactly-Once。配置要点很关键：Kafka Producer必须开启enable.idempotence=true，Flink作业的checkpoint间隔设为30秒（太短增加ZooKeeper压力，太长恢复慢），State Backend用RocksDB（内存+磁盘混合，比纯内存更稳）。我们曾因忘记在Flink SQL里加'execution.checkpointing.mode' = 'EXACTLY_ONCE'，导致一次网络抖动后，特征表里出现重复记录，花了两天才定位。

• Schema演进的平滑性：原始数据格式经常变（比如新增一个用户设备型号字段）。我们用Confluent Schema Registry管理Avro Schema，Kafka Producer发送前自动注册新Schema，Consumer端用GenericRecord读取，字段缺失时返回null而非报错。这样上游加字段，下游代码完全不用改，架构图里只需在Kafka Topic旁标注“Schema Registry v3.2”。

实操中最大的坑是序列化性能。我们最初用JSON序列化，CPU占用率常年60%以上。换成Avro后，序列化耗时从8ms降到0.3ms，CPU降到25%。Avro的二进制紧凑性和Schema预编译是关键。现在所有Topic强制要求用Avro，JSON只用于调试。架构图里，Kafka图标旁一定会加个小标签：“Avro Schema, Compression: snappy”。

3.2 特征工程层：为什么放弃Spark，选择Flink SQL + Iceberg？

特征工程曾是我们最头疼的一环。早期用Spark SQL跑离线特征，每天凌晨跑一次，T+1延迟。业务方抱怨：“昨天用户买了手机，今天推荐还推充电宝？”后来上了实时特征，又用Spark Streaming，结果发现小文件问题严重——每分钟生成上千个Parquet小文件，HDFS NameNode直接卡死。最终切换到Flink SQL + Iceberg，效果立竿见影：

• 流批一体的真正落地：Flink SQL用同一套语法写实时和离线逻辑。比如“用户过去1小时点击次数”这个特征，实时模式下用TUMBLING_ROW_TIME窗口，离线模式下用TUMBLING窗口+PROCTIME，SQL主体几乎一样。我们把所有特征SQL存Git，用Jenkins触发构建，自动部署到Flink集群。架构图里，Flink作业框会标注“SQL Mode: Blink Planner, State TTL: 7d”。

• Iceberg解决小文件和ACID难题：Iceberg的隐藏分区（Hidden Partitioning）自动按日期/小时建目录，避免手动管理路径；它的Manifest List机制让小文件合并变成后台异步任务，不再阻塞查询。最关键的是ACID支持：特征计算任务失败重跑时，Iceberg能保证旧数据不被污染，新数据原子写入。我们配置write.target-file-size-bytes=134217728（128MB），确保文件大小合理。

• 特征版本化的实操技巧：我们在Iceberg表名后加版本号（如user_behavior_v2），每次特征逻辑变更，就新建表并写入新数据。应用层通过配置中心动态切换表名。这样模型训练时指定user_behavior_v2，线上服务用user_behavior_v1，完全解耦。架构图里，Iceberg图标旁会画个循环箭头，标注“Versioned Table: v1/v2/v3”。

有个血泪教训：Flink的State Backend必须用RocksDB，不能用Memory或FsStateBackend。我们曾用FsStateBackend，一次JobManager重启，所有窗口状态丢失，特征值全归零。RocksDB把状态存在本地磁盘，即使TaskManager挂掉，从CheckPoint恢复也能保证状态一致。

3.3 模型服务层：Triton Inference Server的深度定制实践

模型服务层是性能瓶颈的集中营。我们对比过Triton、TensorFlow Serving、TorchServe，最终选Triton，核心原因是它对GPU资源的精细化控制能力。但开箱即用的Triton不够用，必须深度定制：

• 动态批处理（Dynamic Batching）的阈值调优：Triton默认batch_delay_microseconds=1000（1ms），但我们实测发现，对于BERT类模型，1ms太短，batch size平均只有2；调到5000（5ms）后，平均batch size升到8，QPS提升3.2倍。但再调高到10ms，延迟就超标。这个值必须按模型类型实测，架构图里每个模型服务框都要标注“Batch Delay: 5000μs”。

• 模型实例数（Instance Group）的GPU显存精算：一个V100有32GB显存，模型A加载后占18GB，那最多只能启1个实例；模型B只占8GB，就能启3个实例。我们写Python脚本自动计算：max_instances = floor((gpu_memory - system_overhead) / model_memory)。脚本输出直接生成config.pbtxt文件。这样既不浪费显存，又避免OOM。架构图里GPU节点框会标注“Model A: 1 instance, Model B: 3 instances”。

• 健康检查与自动扩缩容的联动：Triton自带/v2/health/ready接口，但我们发现它只检查服务进程，不检查GPU状态。于是用nvidia-smi命令写了个Shell脚本，每10秒检查GPU利用率和显存占用，超过阈值就触发告警。K8s的HPA根据这个指标扩缩容。架构图里，Triton服务框和K8s HPA框之间会画一条带箭头的虚线，标注“GPU Util > 85% → Scale Up”。

最坑的一个细节：Triton的模型仓库路径必须是绝对路径，且所有模型配置文件（config.pbtxt）里的platform字段必须严格匹配模型文件格式（如pytorch_libtorch），少个下划线就加载失败。我们用Ansible自动化部署，所有路径和配置都模板化，杜绝手误。

3.4 应用编排层：Tempo工作流的防错设计

应用编排层是业务逻辑的“指挥中心”，也是故障高发区。我们选Tempo而非Airflow，是因为Tempo专为低延迟、高并发的在线服务设计。但Tempo的YAML工作流容易写错，我们总结了几条铁律：

• 每个Step必须定义timeout和retry策略：Tempo默认不设超时，一个卡死的Step会让整个工作流挂住。我们强制所有Step加timeout: "30s"，retry: { max_attempts: 3, backoff: "1s" }。比如调用外部风控API，超时设为2s（业务要求），重试3次，指数退避。架构图里，每个Step框右上角会标“T:2s, R:3”。

• 状态传递必须用JSON Schema校验：Tempo的input/output是自由JSON，但不同Step间数据结构不一致会导致运行时报错。我们在每个Step的YAML里加input_schema和output_schema字段，用JSON Schema定义字段类型、必填项、枚举值。CI阶段用ajv库校验，不通过直接拒绝部署。这样把错误拦截在上线前。

• 降级开关必须物理隔离：所有关键Step都配一个降级开关（如Redis里的feature:fraud:enable），Tempo工作流里用if条件判断。但开关本身不能和业务代码部署在一起——我们用独立的ConfigMap挂载到Tempo Pod，由运维同学单独管理。这样业务发布时，开关不会被意外覆盖。架构图里，降级开关会画成一个独立的云朵图标，用红色虚线连到对应Step。

有一次线上事故，某个Step的Python脚本里写了time.sleep(10)模拟延迟，结果被误提交到生产。因为有超时设置，30秒后自动失败，触发降级流程，用户只感知到“风控稍慢”，没影响下单。如果没有这些防错设计，整个支付链路就瘫痪了。

4. 架构图实战：从草稿到可交付的完整流程

4.1 草稿阶段：用白板画出“最简可行路径”

任何架构图的第一步，不是打开draw.io，而是找块白板，用马克笔画出用户请求从发出到返回的“最简可行路径”。我们管这叫“铅笔线”——只画一条主线，不加任何分支、不标任何技术栈、不考虑容灾。比如智能客服系统，铅笔线就是：用户发消息 → API网关 → NLU模型 → 对话管理 → 知识库检索 → 组装响应 → 返回用户。

这一步的关键是砍掉所有“看起来有用”的组件。比如有人想加“用户意图分类模型”，先问：没有它，核心流程能跑通吗？如果能，就放到第二版再加。我们的原则是：第一版架构图必须能用最少的组件，支撑最小的MVP功能。曾经有个团队在草稿阶段就画了“实时特征服务”、“离线特征服务”、“AB测试分流”、“灰度发布网关”，结果评审时发现，连最基础的NLU模型都还没集成成功。铅笔线的价值，就是暴露真正的优先级。

画完铅笔线，马上做“故障注入”演练：假设NLU模型服务挂了，用户会看到什么？如果是空白页，说明缺少降级逻辑；如果是500错误，说明缺少熔断。把这些故障点用红笔圈出来，就是后续要补的“安全气囊”。我们通常在白板上用红圈标出3-5个最关键的单点故障，它们就是第二版架构图的重点。

4.2 细化阶段：给每个节点注入“血肉”与“神经”

铅笔线确定后，进入细化阶段。这不是简单贴技术名词，而是给每个节点注入三个维度的信息：

• 血肉（技术选型）：明确写死用什么。比如“API网关”不能只写“API网关”，要写“Kong 3.4.0 + JWT插件”，并标注为什么选Kong（Lua插件生态丰富，支持自定义鉴权逻辑）。我们曾对比过Kong、APISIX、Traefik，最终选Kong，因为它的JWT插件能直接解析Token里的用户角色，省去后端二次鉴权。

• 神经（数据契约）：定义节点间的输入输出。比如“NLU模型”节点，必须标注输入是{"text": "string", "session_id": "string"}，输出是{"intent": "string", "slots": {"product": "string"}}，并附上OpenAPI 3.0的YAML片段。契约不明确的连接，就是未来联调的噩梦。

• 脉搏（SLA指标）：每个节点旁必须标出核心指标。比如“知识库检索”节点，标“P95延迟 < 150ms，可用性99.95%”。这些数字不是拍脑袋，而是基于压测数据。我们用k6做全链路压测，每个节点单独压，记录拐点。架构图里，SLA指标用绿色字体标在节点右下角。

细化时有个重要技巧：用不同颜色区分“已验证”和“待验证”组件。比如NLU模型用绿色，表示已在测试环境跑通；而“实时特征服务”用黄色，表示还在POC阶段。这样团队一眼就知道哪些是可靠模块，哪些是风险点。我们用draw.io画图，颜色规范写在团队Wiki里，新人入职第一天就要学。

4.3 评审阶段：用“三问法”驱动架构收敛

架构图不是画完就完事，评审才是关键。我们用“三问法”驱动收敛：

• 问数据流：“这个数据从哪里来？到哪里去？中间经过几次序列化？”——揪出隐式依赖。比如某次评审，发现“用户画像服务”节点没标数据源，追问后才知道它直连MySQL，而MySQL没在图里，立刻补上，并标注“只读从库，延迟<1s”。

• 问故障域：“如果这个节点挂了，哪些下游会受影响？有没有熔断？”——暴露单点故障。有次发现“短信通知服务”节点没配熔断，一旦运营商接口抖动，整个订单流程就卡住。当场加了Hystrix熔断器，并在图里用闪电图标标出。

• 问扩展性：“如果QPS翻倍，这个节点怎么扩容？需要改代码吗？”——检验设计弹性。比如“对话管理”节点，我们设计成无状态，水平扩容即可；而“会话状态存储”节点，必须标出Redis Cluster分片策略（16384 slots），并注明“扩容需reshard”。

评审不是投票，而是共识。每个问题必须有明确Owner和解决时间。我们用Jira创建“架构图问题”Epics，每个问题关联到具体图节点。评审结束，图上所有黄色节点必须变成绿色，所有红色闪电图标必须有对应的防护措施。

4.4 发布阶段：架构图必须成为可执行的“活文档”

最终交付的架构图，必须是“活”的，能直接驱动开发和运维。我们做到三点：

• 图即代码：所有draw.io文件存Git，用XML格式，支持diff。CI流水线里加校验步骤：检查所有节点是否标SLA，所有连接线是否标协议（HTTP/gRPC/Kafka），所有黄色节点是否有对应Jira Issue链接。不通过，构建失败。

• 图即配置：Kong网关的路由配置、Triton的模型配置、Tempo的工作流YAML，全部从架构图的元数据自动生成。我们写Python脚本解析draw.io XML，提取节点属性，生成对应配置文件。这样架构图一改，配置自动更新，杜绝“图一套，代码一套”。

• 图即监控：架构图里的每个节点，都对应Grafana看板的一个Panel。比如“NLU模型”节点，看板里就有“请求QPS”、“P95延迟”、“GPU显存使用率”三个指标。节点旁的SLA数字，直接链接到告警规则。运维同学看图，就能知道该盯哪个指标。

有次线上延迟升高，运维同学直接点开架构图里的“特征服务”节点，跳转到Grafana看板，发现Kafka Consumer Lag飙升，5分钟定位到是Flink作业反压。这就是活文档的价值——它不只是画给人看的，更是给机器读的。

5. 避坑指南：那些没写在文档里的血泪教训

5.1 模型版本混乱：一次线上事故的完整复盘

去年双十一大促前夜，智能推荐系统突然出现大量“相关性低”的商品曝光。排查三天，最终定位到：算法同学在测试环境更新了模型v3，但忘了更新生产环境的模型服务配置，导致线上还在用v1模型，而v1的特征工程逻辑和v3不兼容。表面看是操作失误，根子在架构设计缺陷。

我们当时的架构图里，“模型服务”节点只写了“Triton v2.12”，没标模型版本。更致命的是，模型文件、特征代码、配置文件三者没做版本绑定。现在我们的解决方案是“三位一体版本锁”：

• 模型文件：存MinIO，路径为s3://models/recommender/v3/model.onnx
• 特征代码：Git Commit IDa1b2c3d，对应Docker镜像Tagfeature-recommender:v3-a1b2c3d
• Triton配置：config.pbtxt里version_policy: "latest"改为version_policy: "specific { versions: [3] }"

三者通过CI流水线强绑定：每次Git Push，Jenkins自动构建Docker镜像，上传模型文件，生成config.pbtxt，最后更新K8s ConfigMap。架构图里，模型服务节点现在标注“Version Lock: v3 + a1b2c3d”，并用锁形图标强调。

提示：永远不要相信人工同步。模型版本必须由CI/CD流水线自动管理，架构图只是这个流程的可视化呈现。

5.2 特征漂移：为什么监控指标救不了你的模型？

某金融风控模型上线三个月后，坏账率悄然上升2个百分点。监控系统一切正常：API延迟、QPS、GPU利用率全在阈值内。问题出在特征漂移——用户还款习惯变了，但特征工程层还在用三个月前的统计口径计算“历史逾期率”。

我们当时的架构图里，“特征工程层”节点只写了“Flink v1.15”，没标特征计算逻辑的时效性。现在我们强制所有特征加“时效标签”：

• 实时特征：last_1h_click_count，SLA标注“延迟<30s”
• 近实时特征：last_24h_avg_order_amount，SLA标注“延迟<5m”
• 离线特征：user_ltv_score，SLA标注“T+1，每日02:00更新”

更重要的是，在特征表上加监控：用Great Expectations跑数据质量检查，每天校验last_24h_avg_order_amount的分布偏移（KS检验），偏移超阈值自动告警。架构图里，特征工程层节点旁加了一个小眼睛图标，链接到数据质量看板。

注意：特征漂移监控必须独立于模型监控。模型准确率下降可能是数据问题，也可能是模型问题，必须分开定位。

5.3 权限爆炸：一张图暴露的200个密钥风险

某次安全审计，发现架构图里有12个节点标注了“访问MySQL”，但实际有200多个服务账号在用这些数据库。根源是：架构图只画了“谁需要访问”，没画“用什么凭证访问”。

我们现在强制所有外部依赖节点，必须标注认证方式：

• 数据库：标“Service Account: recommender-ro@prod-db”，并注明权限范围（SELECT only on recommender.*）
• 对象存储：标“IAM Role: s3-read-only-recommender”，并附最小权限策略JSON
• API服务：标“API Key: recommender-client-key”，并注明轮换周期（90天）

所有凭证不存代码，统一由Vault管理，架构图里Vault节点用盾牌图标，所有依赖它的节点用虚线连接。CI流水线在部署时，自动从Vault拉取凭证，注入Pod环境变量。

实操心得：架构图里的每个连接线，都应该回答“凭什么是你？”——是API Key？是Service Account？是双向TLS证书？答不上来，就是安全隐患。

5.4 监控盲区：为什么90%的告警都是无效的？

我们曾有200多个Prometheus告警规则，但真正有用的不到10%。问题出在架构图里，监控节点只写了“Prometheus + Grafana”，没标“监控什么”和“告警阈值”。

现在我们的架构图，监控层细分为：

• 基础设施监控：节点CPU、内存、磁盘，阈值按K8s Resource Request设（如CPU > 90% of request）
• 服务监控：HTTP状态码、gRPC状态码、P95延迟，阈值按SLA设（如延迟 > 150ms）
• 业务监控：推荐点击率、风控通过率，阈值按基线设（如CTR < 70% of 7-day avg）

每个监控指标在图里用靶心图标标出，并链接到具体的告警规则。我们还加了“告警抑制规则”：比如“GPU显存>95%”告警触发时，自动抑制“模型服务延迟高”告警，避免告警风暴。

关键经验：没有业务语义的监控是噪音。架构图里的监控节点，必须和业务目标对齐，否则就是运维负担。

6. 迭代与演进：架构图不是终点，而是起点

架构图的生命力，在于它必须随业务一起呼吸。我们每季度做一次“架构图健康度扫描”，用四个维度评估：

• 新鲜度：图中所有技术栈版本（Kong 3.4.0、Flink 1.15）是否在官方支持列表内？过期版本标红。
• 一致性：图中所有节点的SLA，是否和线上监控的真实P95/P99匹配？偏差>10%标黄。
• 完整性：图中是否遗漏了新接入的数据源（如新增的小程序埋点）？用数据血缘工具扫描，自动比对。
• 可执行性：图中所有配置（Kong路由、Triton config）是否能在CI中一键生成？生成失败率>0%标红。

扫描结果直接驱动架构演进。比如上季度扫描发现，Flink 1.15已EOL，且新版本支持更好的Watermark机制，我们就启动升级项目，架构图里Flink节点从“v1.15”更新为“v1.18”，并加注“Upgrade Q3 2024”。

我个人在实际操作中的体会是：最好的架构图，是让人看了就想改、改了就想试、试了就有效。它不该是挂在墙上的装饰画，而该是放在IDE里的README.md。我们团队现在有个不成文规定：任何PR，如果涉及架构变更，必须先更新draw.io文件，CI检查通过才能合并。久而久之，架构图就成了团队最准的“系统现状说明书”。

最后再分享一个小技巧：给架构图加“时间戳水印”。我们用draw.io的“插入→文本”功能，在右下角加一行小字：“Last Updated: 2024-05-20 14:30 | Owner: @arch-team”。这样任何人看到图，第一反应不是“这图对吗”，而是“这图是不是最新的”。时间戳比任何技术细节都更能体现架构的活性。