AegisCloud 技术选型思考：自治系统需要什么样的中间件？
在完成了架构设计之后，一个无法回避的问题摆在我面前：
AegisCloud 这套微服务自治系统，到底该由哪些技术来承载？
一、为什么技术选型在自治系统中尤为重要？
在传统的微服务项目里，技术选型往往是“能用就行”。
比如“数据库选哪种，消息中间件用啥，监控工具随便选一个就行”。
但在 AegisCloud 中，这种想法不成立。原因很简单：
AegisCloud 不是普通业务系统，它是一个“管理系统的系统”——必须能被观测、能被分析、能被控制。
也就是说，每个技术选型都不是随意的，它必须在 MAPE-K 自治闭环中找到自己的角色：
- 能帮 Observer 采集到稳定、可靠的数据
- 能让 Analyzer 做到准确、可解释的异常分析
- 能让 Planner 生成受控、可回滚的策略
- 能让 Executor 安全、可观测地执行动作
- 能让 Knowledge Base 记录历史、提供复用价值
如果技术选型不到位，这个闭环就会断裂：
系统可能能监控、能分析，但执行没法落地；
或者执行能跑，但缺少知识积累，系统永远停留在“第一次遇到问题”的状态。
所以在自治系统里，技术选型不是为了“方便开发”或“跟风流行”，
而是为了 确保闭环完整、可控、可演进。
二、AegisCloud 全局技术地图（核心骨架）
在动手搭建 AegisCloud 之前，我先画了一张全局技术地图，用来回答一个问题：
在自治系统里，每个技术为什么选它，它在闭环里扮演什么角色？
这张地图也是后续每篇博客的锚点，你可以把它想象成系统的骨架：
| 能力 | 技术选型 | MAPE-K 阶段 | 备注 / AegisCloud 角色 |
|---|---|---|---|
| 服务治理 | Sentinel | Plan / Execute | 自治闭环的执行器：系统可以动态控制策略下发和流量治理 |
| 配置 & 规则 | Nacos | Execute / Knowledge | 系统指令的下发通道，同时存储策略和规则，支持回滚 |
| 服务发现 | Nacos | Monitor | 提供系统拓扑和服务状态感知，是闭环的感官输入 |
| 事件通信 | MQ（Kafka / RocketMQ 抽象） | Monitor / Knowledge | 稳定性事件流的承载者，同时供 AI 分析和知识沉淀使用 |
| AI 接入 | Spring AI / Spring AI Alibaba | Analyze | 异常分析与根因诊断，辅助 Planner 生成策略 |
| 观测 | Micrometer / Sleuth | Monitor | 指标、日志、链路采集，提供闭环最基础的数据输入 |
可以看到，每一项技术都不是“随便选的”，
它们在 MAPE-K 自治闭环里都有明确的定位和作用。
后续文章中，我会逐层拆解这些能力，
让你看到 每个技术如何在工程系统中真正落地，
而不是停留在理论模型上。
三、逐个技术选型分析
1. Nacos：系统的“神经网络”
在 AegisCloud 中，Nacos 不只是一个普通配置中心，它是整个自治系统的神经网络：
| 功能 | 作用 |
|---|---|
| 注册发现 | 实时拓扑感知（Monitor） |
| 配置中心 | 自治策略载体（Execute） |
| 动态推送 | 系统指令下发通道（Knowledge） |
Nacos 让系统“能看见自己、能记住自己、能告诉自己该怎么办”。
为什么不用 Apollo 或 Consul？
- Apollo：偏向静态配置，不强调动态治理，闭环响应能力不足
- Consul：生态和 Spring Cloud Alibaba 整合度不够高
- Nacos + Sentinel：天生适合治理级自治系统，可以顺畅支撑 MAPE-K 闭环
也就是说，选择 Nacos 并非随意，而是从“系统自治能力”出发的工程决策。
2. Sentinel：自治系统的执行器
在 AegisCloud 中，Sentinel 扮演的是闭环中的执行器角色（Plan / Execute）：
- 核心作用：限流、熔断、降级、热点参数控制
- 特点：规则结构化、支持动态调整、集中管理
- 价值：AI 或 Planner 可以直接指挥 Sentinel 动态调整系统行为，而不依赖人工操作
Sentinel 让系统能够“自己动手”，把策略真正落实到生产环境。
为什么不用 Hystrix 或 Resilience4j？
- Hystrix：已停止维护，长期不适合生产
- Resilience4j：偏向开发库，缺少平台级策略管理能力
- Sentinel：天然为自治闭环设计，规则可动态下发、执行可观测、闭环可控
也就是说，选择 Sentinel 不是因为它流行，而是它完全符合自治系统对执行器的要求。
3. MQ：自治系统的事件流与记忆
在 AegisCloud 中，MQ 并不是单纯的消息队列，它是自治系统的“血液和记忆”：
- 核心作用：
- 传递稳定性事件，让系统知道发生了什么
- 为 AI 分析提供输入数据
- 记录自愈策略执行情况，为 Knowledge Base 提供历史信息
- 本质价值：不是简单的解耦工具，而是系统的长期记忆
所有后续的自愈评估、策略优化和经验积累，都依赖这些事件流
用一句话总结：
没有事件，就没有自治闭环的可追溯性，也谈不上“会自己学习”的系统
也正因为如此，MQ 在 AegisCloud 中是闭环必不可少的基础设施，不仅支撑分析，也承载执行与知识沉淀。
4. 其他技术
除了 Nacos、Sentinel、MQ 之外，AegisCloud 还依赖几项关键技术，支撑自治闭环的感知与分析能力：
| 技术 | MAPE-K 阶段 | 作用 |
|---|---|---|
| Spring AI / Spring AI Alibaba | Analyze | 异常分析与根因诊断，为 Planner 提供决策依据 |
| Micrometer / Sleuth | Monitor | 指标、日志、链路采集，是 Observer 的核心感知手段 |
简单总结：
- Micrometer / Sleuth 是系统的“眼睛和耳朵”，让 AegisCloud 能实时感知运行状态
- Spring AI / Spring AI Alibaba 是系统的“分析大脑”，帮 Planner 理解异常原因并提供智能建议
没有这些技术，闭环就不完整：系统可能能看见问题，但分析和判断永远靠人；或者分析了问题，却无法安全生成策略。
整体来看，这些技术和前面提到的 Nacos、Sentinel、MQ 一起，形成了 AegisCloud 的自治骨架：
观测 → 分析 → 决策 → 执行 → 知识沉淀，缺一不可。
四、技术选型原则总结
在 AegisCloud 里，技术选型从来不是“能用就行”，每一项选择都必须服务于 自治闭环。总结下来，有四条核心原则：
- 服务自治闭环优先于单点功能
每个技术的价值，不在于它能单独做多少功能，而在于它能否在闭环中被观测、分析、执行和沉淀。 - 可动态控制优先于静态配置
自治系统不是写死规则的“展示板”，它需要动态调整策略，实时响应异常。 - 平台级能力优先于开发库
开发库只服务于代码级功能，而 AegisCloud 需要平台级、可统一管理的能力，支撑全局自治。 - 可演进性优先于一步到位
自治能力不是一次性就能完成的，技术选型要支持系统逐步成长，从规则驱动到 AI 辅助，最终形成人机协同闭环。
这些原则确保每项技术都不是“好用就行”，而是真正服务于系统自治，让闭环落地。
五、下一步：工程模块拆分
有了技术选型，我们已经知道 闭环中每个能力的“靠谁实现”。
但更现实的问题来了：
- 如何把这些能力拆解成具体的工程模块？
- 自治系统的边界到底在哪里？
- 哪些模块属于业务系统，哪些是治理系统？
这些问题，决定了 AegisCloud 能不能真正落地成为一个可观测、可分析、可执行、可回滚的自治平台。
在下一篇文章里，我会详细讲解 模块划分与边界设计，并给出每个模块的职责说明、上下游依赖和通信方式，让闭环不仅是概念，而是能在工程里真正跑起来。