基于SpringAI的智能OPS平台项目背景介绍

在企业数字化转型提速的当下，公司业务运营平台运维复杂度陡增。传统模式高度依赖人工，面对海量监控指标与重复性故障，运维人员疲于被动响应，易因处置延迟扩大故障影响，难以匹配业务高效运转需求。

为破解此痛点，公司提出为运营平台注入AI赋能的需求，目标实现重复性问题智能识别与自动处置，减少人工干预，提升运维智能化水平。

作为项目负责人，我牵头启动本AIOps平台开发项目，依托SpringAI与DDD设计，构建“采集-检测-定位-处置-复检”全流程运维体系。项目要求三个月内完成核心功能开发与上线，助力运维人员聚焦高价值工作。

工程目录结构

本项目是一款聚焦智能运维的 AIOps 平台，以微服务架构为部署形态，以DDD（领域驱动设计） 为模块拆分核心逻辑，将 “采集 - 检测 - 定位 - 处置 - 复检” 的运维闭环拆解为高内聚、低耦合的服务单元与领域模块，既满足微服务 “独立部署、弹性扩展” 的需求，又通过 DDD 保证业务逻辑的清晰性与可维护性。

一、微服务与 DDD 多模块的融合设计思路

项目的核心是 “微服务承载业务域，DDD 定义模块边界”：

• 从微服务角度：将平台拆分为 “数据采集服务、异常检测服务、根因定位服务、自动处置服务、通用支撑服务”，各服务可独立部署、单独扩容（如数据采集服务需应对高并发指标传输，可单独增加实例）；

• 从 DDD 角度：每个微服务内部按 “领域核心（核心域）、通用支撑（通用域）、基础设施（支撑域）” 拆分模块，确保业务逻辑不与技术实现耦合（如根因定位服务内，“AI 大模型根源推理” 是核心域模块，“日志 / 指标存储适配” 是支撑域模块）；

• 技术底座：基于 SpringAI 实现大模型能力集成，Spring Boot 提供微服务基础支撑，整体遵循 “领域驱动设计定边界，微服务架构提效率” 的原则。

二、DDD 多模块的领域定位与微服务映射

结合项目工程目录（aiops-platform）与微服务拆分逻辑，各模块的 DDD 领域定位及对应微服务如下，同时明确模块间的依赖关系：

（一）DDD 领域模块划分与微服务映射

工程目录模块	DDD 领域定位	对应微服务	核心职责
aiops-core	核心域（业务核心层）	根因定位服务、自动处置服务	承载 AIOps 核心业务逻辑：根因定位的 “指标 - 日志关联分析”“AI 大模型推理”，自动处置的 “策略执行”“复检触发”，是平台的业务核心
aiops-model	核心域（AI 能力层）	异常检测服务、根因定位服务	封装 SpringAI 大模型能力：异常检测的 “数据特征分析”、根因定位的 “故障根源推理”，为核心业务提供 AI 技术支撑
aiops-prometheus-mock	支撑域（基础设施层）	数据采集服务	模拟普罗米修斯监控数据采集能力（测试 / 联调场景），提供 “指标采集”“日志暂存” 的基础设施，生产环境可替换为真实 Prometheus 采集服务
aiops-api	应用层（接口网关层）	API 网关服务	作为微服务的统一入口，承接外部请求（如运维平台前端、第三方系统调用），将请求路由至对应微服务，同时处理参数校验、权限控制
aiops-common	通用域（通用支撑层）	通用支撑服务	提供全平台复用的通用能力：大模型 Token 计算工具、监控数据格式转换、日志打印、数据库连接池等，为所有微服务提供基础支撑

（二）模块 / 服务间的依赖关系（遵循 DDD 依赖原则）

1. 依赖方向：核心域模块依赖通用域、支撑域模块，通用域 / 支撑域不依赖核心域；微服务间通过 “API 接口调用” 交互，不直接依赖代码模块；

2. 具体依赖逻辑：

• 核心域依赖：aiops-core（核心域）依赖aiops-model（核心域，调用 AI 大模型能力）、aiops-prometheus-mock（支撑域，获取监控数据）、aiops-common（通用域，复用工具类）；

• 应用层依赖：aiops-api（应用层）依赖所有核心域模块的 “接口定义”（通过 OpenFeign/GRPC 调用微服务，不依赖具体实现）；

• 微服务间依赖：数据采集服务→异常检测服务（推送指标 / 日志数据）、异常检测服务→根因定位服务 / 自动处置服务（分流异常请求）、根因定位服务→自动处置服务（传递根源分析结果）、所有服务→通用支撑服务（调用通用工具）；

1. 依赖解耦：通过 “接口抽象” 实现解耦，如aiops-core调用aiops-prometheus-mock的 “数据查询能力” 时，依赖的是 “监控数据查询接口”，而非具体 Mock 实现，后续替换为真实 Prometheus 服务时，无需修改aiops-core代码。

三、核心业务流程：微服务与 DDD 模块的协同工作

以 “异常指标触发智能处置” 为例，梳理微服务与 DDD 模块的协同流程，展现 “微服务调用 + DDD 模块执行逻辑” 的完整链路：

1. 流程触发：数据采集服务（aiops-prometheus-mock）采集指标

• 领域模块执行：aiops-prometheus-mock（支撑域）的 “普罗米修斯指标采集器” 定时拉取服务器 CPU、内存等指标，通过 “指标可视化组件” 格式化数据；

• 微服务动作：数据采集服务将格式化后的指标数据，通过 HTTP/GRPC 接口推送给异常检测服务。

2. 异常判断：异常检测服务（aiops-model+aiops-core）分析数据

• 领域模块执行：

• aiops-model（核心域）的 “AI 大模型数据特征分析器” 接收指标数据，对比正常基线，输出 “CPU 使用率超限（异常等级：中）” 的分析结果；

• aiops-core（核心域）的 “异常结果判断逻辑” 根据异常等级，判定为 “简单问题”，触发自动处置路径；

• 微服务动作：异常检测服务调用自动处置服务的 “策略执行接口”，传递异常信息（如 “服务器 IP：192.168.1.100，CPU 使用率：95%”）。

3. 自动处置：自动处置服务（aiops-core）执行策略

• 领域模块执行：

• aiops-core（核心域）的 “自动执行策略引擎” 根据异常类型（CPU 超限）匹配预设策略（如 “重启目标服务器的非核心进程”）；

• 执行策略后，触发 “复检触发组件”，生成复检任务（如 “1 分钟后重新采集该服务器 CPU 指标”）；

• 微服务动作：自动处置服务调用数据采集服务的 “复检数据采集接口”，指定复检指标与时间；同时将处置结果同步给根因定位服务（备用，若复检异常则需深度分析）。

4. 复检闭环：数据采集服务 + 异常检测服务完成闭环

• 领域模块执行：

• 数据采集服务的aiops-prometheus-mock（支撑域）按时采集复检指标（CPU 使用率降至 60%）；

• 异常检测服务的aiops-model（核心域）再次分析，判定 “无异常”，闭环完成；

• 微服务动作：异常检测服务将 “处置成功 + 复检正常” 的结果推送至 API 网关服务，由网关反馈给前端运维界面。

四、融合设计的核心优势

1. 业务逻辑清晰：DDD 明确模块边界，避免 “数据采集混着处置逻辑” 的混乱代码，新开发人员可快速定位核心业务（如找根因分析逻辑，直接看aiops-core）；

2. 微服务弹性扩展：高负载模块（如数据采集、异常检测）可单独扩容，不影响其他服务（如双 11 期间指标采集量激增，仅需增加数据采集服务实例）；

3. 可维护性强：修改某一业务逻辑（如更换根因定位的大模型），仅需调整aiops-model模块，其他模块不受影响；

4. 可测试性高：支撑域模块（如aiops-prometheus-mock）提供 Mock 能力，可独立测试核心域逻辑（如测试aiops-core的处置策略，无需依赖真实监控环境）。

五、AIops运维平台·总模块图

逻辑描述：该图展示智能运维平台的四大核心模块及其交互关系。数据采集模块作为基础，为异常检测模块提供输入；异常检测模块根据问题复杂度分流至自动处置或根因定位模块；根因定位模块将分析结果传递给自动处置模块；自动处置模块执行后触发复检，形成闭环。

六、智能运维平台·总时序图（全流程）

逻辑描述：该时序图展示跨模块的完整工作流。数据采集模块主动或定时发送数据至异常检测模块；异常检测模块根据分析结果决定路径；自动处置模块执行后必触发复检，形成反馈循环。

七、各模块内部时序图与核心逻辑

1. 数据采集模块内部时序图

逻辑描述：展示数据采集的两种路径（指标 vs 日志）。指标数据经可视化后直接推送至异常检测模块；日志数据则先暂存，供根因定位模块按需取用。

2. 异常检测模块内部时序图

逻辑描述：展示AI模型如何分析数据并生成处置建议。用户通过界面按钮干预流程方向，体现了人机协同的设计。

3. 根因定位模块内部时序图

逻辑描述：强调指标与日志的关联分析是根因定位的核心。AI大模型进行推理后，将证据化的结果输出给自动处置模块。

4. 自动处置模块内部时序图

逻辑描述：展示自动与人工处置路径的融合。复检机制确保处置有效性，异常反馈形成闭环优化。

核心逻辑：所有图表共同体现了智能运维平台 “采集-检测-定位-处置-复检” 的闭环核心思想。

帮助您清晰地呈现智能运维平台的设计。