4. 端到端项目架构
保险智能理赔端到端项目的架构设计，不是把五个架构图拼在一起，而是围绕“一次理赔从报案到结案”的完整链路，逐层回答五个问题：业务上要完成什么、应用上由谁协作、数据上如何流转、技术上用什么支撑、部署上如何落地。五层架构之间必须保持可追溯的映射关系，否则项目会在集成阶段出现“业务要的能力没人实现、应用调用的数据不存在、部署环境跑不起模型”等典型断裂。
核心原理：五层架构的职责边界与映射关系
业务架构定义理赔价值链上的业务能力、参与角色和关键规则，例如报案受理、影像采集、OCR识别、责任判定、理算核赔、支付结案。应用架构把业务能力拆解为可独立开发部署的应用服务，明确服务边界、调用关系和集成方式。数据架构描述理赔主数据、影像数据、结构化案件数据、模型特征与结果数据的存储、流转和治理。技术架构确定AI模型、规则引擎、工作流引擎、消息中间件等技术组件的选型与组合。部署架构则把上述组件映射到具体的云资源、网络分区、容器集群和灾备策略上。
五层架构的核心约束是“双向可追溯”：从业务能力可以向下找到支撑它的应用、数据、技术和部署单元；从任一部署单元也能向上回溯到它服务的业务能力。缺少这种映射，架构图就只是装饰。
方法流程：从业务能力到部署单元的推导步骤
- 梳理业务能力地图。以理赔案件生命周期为主线，列出每个阶段的业务能力、参与角色、输入输出和业务规则。例如“责任判定”能力需要输入保单条款、事故描述、影像证据，输出责任比例和拒赔理由。
- 划分应用服务边界。按业务能力聚合应用服务，遵循高内聚低耦合原则。OCR识别与影像采集可合并为影像处理域，责任判定与理算核赔可合并为核赔域，避免服务粒度过细导致分布式事务复杂化。
- 设计数据流转模型。明确每个应用服务读写哪些数据实体，定义数据所有权。案件主数据由案件中心独占写入，其他服务只读；模型结果数据由AI服务写入，核赔服务消费。
- 选型技术组件。根据数据特征和性能要求选择技术栈。影像文件用对象存储，结构化案件用关系库，特征向量用向量库，异步解耦用Kafka，实时缓存用Redis。
- 映射部署单元。把应用服务和技术组件映射到K8s命名空间、节点池和网络分区。GPU推理服务部署在GPU节点池，Web服务部署在通用节点池，数据库部署在独立数据子网。
案例场景：车险理赔端到端架构落地
以车险小额理赔为例，客户报案后，报案服务创建案件并写入案件中心；影像服务接收客户上传的事故照片，调用OCR服务识别车牌、VIN码和损伤部位；规则引擎根据保单条款和事故类型判定是否属于保险责任；理算服务计算赔付金额；支付网关完成打款；案件中心更新结案状态。整个链路中，Kafka承载各服务间的异步事件，Redis缓存保单和条款数据，GPU节点池支撑损伤识别模型推理。
| 架构层 | 核心交付物 | 关键干系人 | 常见风险 |
|---|---|---|---|
| 业务架构 | 业务能力地图、价值链、规则清单 | 业务负责人、产品经理 | 能力遗漏、规则冲突 |
| 应用架构 | 服务清单、接口契约、调用关系图 | 架构师、开发负责人 | 服务粒度过细、循环依赖 |
| 数据架构 | 数据模型、数据流图、数据字典 | 数据架构师、DBA | 数据所有权不清、口径不一致 |
| 技术架构 | 技术选型报告、组件部署图 | 技术架构师、运维 | 组件版本冲突、性能瓶颈 |
| 部署架构 | 网络拓扑、资源清单、灾备方案 | 运维负责人、安全合规 | 网络隔离不足、GPU资源浪费 |
误区与复盘：架构设计中的典型陷阱
误区一：先画部署图再补业务架构。很多团队习惯先确定用哪些云服务，再倒推业务能力，结果导致业务需求被技术选型绑架。正确顺序是先业务后技术，部署架构是最后一层映射。
误区二：五层架构各自独立评审。业务、应用、数据、技术、部署五层如果分开评审，很容易出现“业务要实时核赔、应用设计成批量处理、数据层没有实时特征、技术层没有流计算组件、部署层没有对应资源”的连锁断裂。建议采用联合评审，逐层验证映射关系。
复盘要点：架构设计完成后，用一条真实理赔案件做端到端走查，从客户报案开始，逐层确认每个业务能力有对应应用服务、每个应用服务有明确数据读写、每个数据实体有存储方案、每个技术组件有部署位置。走查中发现的断点，就是架构需要补齐的地方。
# 架构走查检查清单示例
业务能力: 责任判定
→ 应用服务: rule-engine-service (已定义)
→ 数据实体: policy_terms, accident_report (已定义)
→ 技术组件: Drools规则引擎 (已选型)
→ 部署单元: k8s-namespace-core / node-pool-general (已映射)
→ 状态: 通过
业务能力: 损伤识别
→ 应用服务: damage-detect-service (已定义)
→ 数据实体: image_object, damage_result (已定义)
→ 技术组件: PyTorch模型 + Triton推理 (已选型)
→ 部署单元: k8s-namespace-ai / node-pool-gpu (已映射)
→ 状态: 通过端到端架构设计的最终检验标准，不是架构图是否漂亮，而是当业务提出一个新理赔场景时，团队能否在五层架构中快速定位需要改动的应用、数据、技术和部署单元，并评估改动的影响范围。能做到这一点，架构才真正具备可演进性。