基于SpringAI的智能AIOps项目：微服务与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 依赖原则）
-
依赖方向：核心域模块依赖通用域、支撑域模块，通用域 / 支撑域不依赖核心域；微服务间通过 "API 接口调用" 交互，不直接依赖代码模块；
-
具体依赖逻辑：
-
核心域依赖：
aiops-core（核心域）依赖aiops-model（核心域，调用 AI 大模型能力）、aiops-prometheus-mock（支撑域，获取监控数据）、aiops-common（通用域，复用工具类）； -
应用层依赖：
aiops-api（应用层）依赖所有核心域模块的 "接口定义"（通过 OpenFeign/GRPC 调用微服务，不依赖具体实现）； -
微服务间依赖：数据采集服务→异常检测服务（推送指标 / 日志数据）、异常检测服务→根因定位服务 / 自动处置服务（分流异常请求）、根因定位服务→自动处置服务（传递根源分析结果）、所有服务→通用支撑服务（调用通用工具）；
- 依赖解耦 ：通过 "接口抽象" 实现解耦，如
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 网关服务，由网关反馈给前端运维界面。
四、融合设计的核心优势
-
业务逻辑清晰 ：DDD 明确模块边界，避免 "数据采集混着处置逻辑" 的混乱代码，新开发人员可快速定位核心业务（如找根因分析逻辑，直接看
aiops-core）； -
微服务弹性扩展：高负载模块（如数据采集、异常检测）可单独扩容，不影响其他服务（如双 11 期间指标采集量激增，仅需增加数据采集服务实例）；
-
可维护性强 ：修改某一业务逻辑（如更换根因定位的大模型），仅需调整
aiops-model模块，其他模块不受影响； -
可测试性高 ：支撑域模块（如
aiops-prometheus-mock）提供 Mock 能力，可独立测试核心域逻辑（如测试aiops-core的处置策略，无需依赖真实监控环境）。