AegisCloud 工程模块化设计与多模块骨架详解

1. 为什么要做多模块化

在微服务自治系统里，系统模块的职责本身就很复杂。
如果把所有功能都堆在一个工程里，会出现几个明显问题：

模块耦合严重，改一个功能可能影响整个系统
业务逻辑与自治闭环混杂，难以分清责任
扩展和演示困难，新功能上线或调试不方便

因此，AegisCloud 采用 Maven 父子工程 + 多模块化设计。
每个模块都有单一职责、可以独立启动，也方便演示、测试和逐步迭代。

模块化让系统更清晰，也让自治闭环落地更可靠。

2. 父工程设计理念

在多模块化项目中，父工程的 pom.xml 就像系统的“大脑”，负责统一管理整个项目的基础配置：

依赖版本统一管理：所有模块共用相同版本，避免版本冲突
插件配置统一化：包括 Spring Boot、Docker、Maven Compiler 等插件
工程构建统一控制：整个项目的打包、测试、部署配置集中管理

优点一目了然：

模块之间版本保持一致，不会因为单独升级而出问题
依赖集中管理，减少重复配置，让维护更轻松
后续新增模块，只需在父工程里声明即可，轻松接入整体构建

父工程让多模块化项目更规范、更易维护，也让扩展变得简单自然。

3. 模块划分与职责

在 AegisCloud 中，我们把整个系统拆成了若干职责清晰的模块，既保证自治闭环清晰可见，又让业务服务与治理逻辑完全解耦。

项目目录结构大致如下：

aegiscloud
│
├── pom.xml                 # 父工程 POM
├── aegis-common            # 公共模块，放公共依赖和工具类
├── aegis-gateway           # API 网关
├── aegis-service-business  # 示例业务服务
├── aegis-observer          # 可观测性模块
├── aegis-analyzer          # 异常分析 / AI 模块
├── aegis-planner           # 策略生成模块
├── aegis-executor          # 自愈执行模块
├── aegis-knowledge         # 决策历史 / 事件记录
└── aegis-demo              # 演示用微服务 / 集成测试模块

模块职责一览

模块	职责	MAPE-K 对应
aegis-common	公共工具、DTO、事件类	支撑各模块
aegis-gateway	API 统一入口、限流、路由	Monitor / Execute
aegis-service-business	示例业务逻辑	被治理对象
aegis-observer	指标、日志、链路采集	Monitor
aegis-analyzer	异常分析、AI 推理	Analyze
aegis-planner	自愈策略生成	Plan
aegis-executor	执行策略、动态调整	Execute
aegis-knowledge	决策历史、事件沉淀	Knowledge
aegis-demo	演示闭环功能	综合测试

通过这种模块化拆分，每个模块都只做一件事

这样，AegisCloud 的自治闭环不仅概念清晰，更能在工程上落地。

4. 模块依赖关系（Mermaid 图）

下面这张图展示了 AegisCloud 各模块之间的依赖关系和数据流向：

  flowchart LR
    %% 用户请求入口
    U[用户请求] --> G[Gateway]

    %% 业务服务
    G --> S1[业务服务 A]
    G --> S2[业务服务 B]

    %% 可观测层
    subgraph Observability
        O[Observer模块<br/>采集指标 / 日志 / Trace]
    end

    %% 自治闭环
    subgraph AutonomicLoop[自治闭环]
        A1[Analyzer模块<br/>AI / 规则分析]
        P1[Planner模块<br/>策略生成]
        E1[Executor模块<br/>执行自愈策略]
        K1[Knowledge模块<br/>记录决策历史]
    end

    %% 模块间流向
    S1 --> O
    S2 --> O

    O --> A1
    A1 --> P1
    P1 --> E1
    E1 --> K1
    K1 --> A1

    %% 配置中心
    E1 -->|策略下发| C[Nacos]
    C --> G
    C --> S1
    C --> S2

依赖关系说明

业务服务模块只提供可观测接口，不参与自治闭环的逻辑
AutonomicLoop（Analyzer / Planner / Executor / Knowledge）完全独立，实现闭环自治
Gateway + Nacos作为系统入口和策略下发通道，保证请求可控和执行可追溯
Knowledge 模块形成闭环“记忆”，为 Analyzer 和 Planner 提供经验数据，使系统能逐步优化策略

这张图直观展示了 AegisCloud 的工程落地思路：
业务系统专注业务，自治闭环独立运行，规则和决策可追溯、可回滚。

5. 小结

通过父子工程 + 多模块化设计，AegisCloud 的工程骨架达到了几个目标：

系统可扩展、低耦合
新增模块无需改动既有模块，整个系统可以平滑扩展。
模块职责单一、边界清晰
每个模块只做一件事，不越权，方便开发、测试和运维。
MAPE-K 闭环映射明确
每个自治阶段都有对应模块支撑，后续功能落地更顺畅。
可视化和展示清晰
博客中配图、模块表和 Mermaid 图，让读者一眼就能理解系统架构与闭环流程。

这个多模块化骨架为 AegisCloud 后续逐步落地自治能力打下了坚实基础，同时也让技术分享变得直观易懂。