在微服务逐渐成熟之后，真正的挑战已经不再是“如何拆服务”，
而是：当系统出问题时，谁来第一时间发现、判断、止损和修复？

一、为什么我要设计 AegisCloud？

在实际的微服务系统里，我们早就对一些现象习以为常了：

  • 服务越来越多，但真正清楚系统整体状态的人却越来越少
  • 监控面板铺了一屏又一屏，异常发生时，还是得靠人盯
  • 限流、熔断、降级一个不落，但规则大多来自经验和拍脑袋
  • 每次事故复盘写得都很认真，可系统本身却什么都没“学会”

这些问题单看好像都不致命，但一放在一起，就会让人很难受。

于是我开始反问自己一个问题：

为什么系统不能自己感知状态、自己分析问题、自己给出应对方案？

如果一个系统每天都在重复遇到相似的问题，
却每次都要等人来判断、来操作、来总结，
那它真的算是一个“成熟的系统”吗？

AegisCloud，正是在这样的背景下诞生的。

它不是为了替代人，而是希望把那些
重复、可总结、可演进的运维决策，
慢慢交还给系统本身。

二、AegisCloud 是一个什么样的系统？

2.1 它不是一个业务系统

在我们开始讨论 AegisCloud 的架构设计之前，我们要明确一件事情：
AegisCloud 从一开始就不是为了做业务而存在的。

它不承载任何业务能力，
不关心“下单”“支付”“库存”，
也不会参与任何用户请求的正常业务流程。

这些事情，交给真正的业务系统去做就好。

我们的 AegisCloud 只关心三件事：

  • 系统现在是不是健康的
    当前的运行状态是否已经偏离了正常区间。
  • 异常到底为什么会发生
    是流量问题、依赖问题，还是系统自身的配置和策略出了问题。
  • 在可控风险下，能不能自己修复
    不靠人拍脑袋，不制造二次事故。

换句话说，
如果业务系统负责“把事情做成”，
那 AegisCloud 负责的是：在事情变糟之前，把系统拉回来。

2.2 它是一个「能力系统」

你可以把 AegisCloud 理解为：

部署在微服务系统之上的一层「自治能力平台」

它不替业务做决定，
而是为业务系统补上一层原本缺失的能力。

更具体一点说，AegisCloud 为已有系统提供的是：

  • 可观测能力的统一抽象
    把监控指标、日志、事件等信息，统一成“系统当前状态”的表达，而不是零散的数据点。
  • 异常分析与解释能力
    不只是告诉你“出问题了”，而是尝试回答：
    这个异常为什么会发生，以及它可能意味着什么。
  • 受控的自治决策与执行能力
    系统可以在规则和边界之内自动做出调整，但每一步都可追溯、可回滚，而不是一黑到底。

换个角度理解：
如果微服务体系解决的是业务拆分和协作的问题，
那 AegisCloud 解决的，是系统如何自己照顾自己的问题。

三、架构设计的核心思想

在真正动手画架构图之前，我先给 AegisCloud 定下了几条
不可妥协的设计原则。

这些原则不是为了“设计得好看”，
而是为了保证：当系统真的开始自己动手时，它依然是可控的。

3.1 职责必须清晰

在自治系统里，最危险的事情之一，就是职责混乱。

所以在 AegisCloud 中，我刻意做了非常严格的拆分：

  • 负责采集数据的模块，不参与任何分析
  • 负责分析问题的模块，不做任何执行
  • 负责执行动作的模块，不参与决策

每一个模块只做一件事，而且只把这件事做到极致。

这样做的目的只有一个：
当系统行为出现问题时，你能清楚地知道是哪一层出了问题。

边界清晰，是自治系统可控的前提。

如果采集、分析、决策、执行全部揉在一起，
那系统一旦“自作主张”，你连回滚都不知道该从哪下手。

3.2 AI 必须被约束

我并不否认 AI 的能力，恰恰相反——
正是因为 AI 很强，所以它必须被约束。

在工程系统里，AI 有两个天然的短板：

  • 它不具备对生产系统的风险敬畏
  • 它不适合直接承担“最后一公里”的操作责任

一句话说就是：
它可以帮你想，但不该替你动手。

所以在 AegisCloud 中，我给 AI 的定位非常明确：

AI 只参与分析和建议，不直接操作任何生产系统。

最终是否执行、如何执行，
必须经过规则、策略和执行模块的约束与校验。

这样，AI 才是“增强人类决策能力的工具”，
而不是一个不受控制的黑箱。

3.3 架构必须允许演进

AegisCloud 从一开始就不假设系统会“天生聪明”。

相反，它被设计成可以慢慢长大：

  • 可以先从规则驱动开始
  • 再逐步引入 AI 辅助分析
  • 最终形成 人机协同、长期共存 的状态

这意味着：
你不需要一步到位，
也不会因为“现在还不够智能”，就推倒重来。

自治不是一次性的能力，而是一个持续演进的过程。

四、自治系统理论基础：MAPE-K

AegisCloud 的整体设计，来源于经典的自治计算模型 MAPE-K。

阶段 含义 AegisCloud 中的体现
Monitor 监测 Observer
Analyze 分析 Analyzer
Plan 决策 Planner
Execute 执行 Executor
Knowledge 知识 Knowledge Base

MAPE-K 不是实现方案，而是系统思考方式， 在上一篇文章中我们已经提及这个部分，这里简略展示一下。

五、AegisCloud 总体架构概览

从结构上看，AegisCloud 并不是一个单体系统，而是一组围绕微服务运行的自治能力层。
整体可以划分为以下五个层次：

  1. 入口与治理前置层
    以 Gateway 为核心，作为系统的第一道防线，负责统一入口控制、前置限流与基础治理。
  2. 可观测层（Monitor）
    由 Observer 负责，承担系统的“感官系统”角色，持续采集指标、日志和链路数据，感知系统状态变化。
  3. 分析与决策层（Analyze / Plan）
    由 Analyzer 与 Planner 组成，是系统的“大脑”，负责异常分析、原因解释以及治理策略的生成。
  4. 执行控制层（Execute）
    以 Executor 为核心，将策略转化为可控的系统动作，通过配置或规则下发真正影响系统行为。
  5. 知识沉淀层（Knowledge）
    由 Knowledge Base 承担，负责记录历史决策、执行效果与环境上下文，为后续分析与决策提供经验支持。

这些层次共同构成了一个完整的 MAPE-K 自治闭环，
让系统不仅能“反应”，还能“记住并进化”。

六、核心模块划分与边界说明

这一部分，是整个 AegisCloud 架构设计中最重要的一章。

前面讲的自治、MAPE-K、分层，如果不能在模块边界上落地，
最终都会变成“看起来很美”的概念设计。

AegisCloud 的所有核心模块，都遵循一个共同原则：

每个模块只解决一个阶段的问题，不越权、不兜底。

6.1 Gateway：统一入口与基础治理

Gateway 是系统的统一入口，也是稳定性治理的第一道防线。

它负责的事情很明确：

  • 接收外部请求，并将流量路由到后端微服务
  • 承担入口级的基础治理能力，比如限流、鉴权前置
  • 提供统一的路由控制和入口层监控能力

但同样重要的是，Gateway 明确知道自己不该做什么。

它不处理业务逻辑，
不分析异常原因，
也不参与任何自治决策。

在 AegisCloud 中，Gateway 只负责一件事：
把系统挡在一个“还算安全的起点”上。

至于“出了什么问题”“该怎么应对”，
那是后面模块的职责。

6.2 Observer：系统的感官中枢

如果说 Gateway 是防线，
那 Observer 就是系统的感官系统。

它是整个自治系统能够成立的基础。

Observer 负责持续采集并整理系统运行时的信息，包括：

  • 指标数据
  • 日志的结构化结果
  • 链路追踪信息
  • 运行过程中的关键事件

它做的不是“监控展示”，
而是把零散的运行数据，抽象成系统可理解的状态输入。

Observer 不判断异常是否严重，
不生成任何策略，
更不影响业务执行流程。

没有 Observer，就不可能有自治。

因为系统连“发生了什么”都不知道，就谈不上后续的一切。

6.3 Analyzer：异常识别与解释

Analyzer 的职责，常常被误解成“发现指标异常”。

但在 AegisCloud 中，它关注的是另一件事：

这些异常，到底意味着什么？

Analyzer 会基于 Observer 提供的数据：

  • 识别异常模式
  • 判断异常是否具有系统性风险
  • 给出结构化、可被理解的分析结论

它的输出不是“红了一个指标”，
而是类似于：

当前异常更可能是流量突增，而不是服务故障

在后续演进中，Analyzer 会逐步引入 AI 参与分析，
但无论规则还是 AI，
Analyzer 都只负责“解释”，不负责“行动”。

6.4 Planner：策略生成与风险控制

Planner 是整个系统中非常关键、但经常被忽略的模块。

它的存在意义只有一个：

把“分析结论”变成“可控的系统行为”。

Planner 会将 Analyzer 的输出：

  • 转换为明确的策略定义
  • 校验策略是否安全、是否越界
  • 确保策略本身是可追溯、可回滚的

你可以把 Planner 理解为：
AI 与真实系统之间的一道防火墙。

Analyzer 可以提出“建议”，
但只有通过 Planner 的策略，才允许进入执行阶段。

6.5 Executor：受控执行与反馈

Executor 是 AegisCloud 中唯一允许“动系统”的模块。

它不做分析，
不参与决策，
只做一件事：

安全、受控地执行已经被批准的策略。

Executor 的所有动作，都必须满足几个前提：

  • 可回滚
  • 可灰度
  • 可观测

无论是下发限流规则，
还是调整系统配置，
Executor 都必须确保：
系统随时可以停下来，甚至退回到执行前状态。

6.6 Knowledge Base：系统的长期记忆

如果说前面的模块解决的是“这一次怎么办”，
那 Knowledge Base 解决的是“下一次能不能更聪明”。

它会持续记录：

  • 异常发生时的系统背景
  • Analyzer 给出的分析结论
  • Planner 生成的策略内容
  • Executor 实际执行后的效果

这些信息不会直接参与实时决策，
但会在后续分析中不断被引用。

Knowledge Base 的存在，让自治系统具备了“经验积累”的能力，
而不是每次都从零开始判断。

6.7 模块总览

模块 职责 对应 MAPE-K
Gateway 统一入口、限流前置 M
Business Services 模拟业务服务 被治理对象
Observer 可观测性采集 M
Analyzer 异常分析 / AI 诊断 A
Planner 策略生成 P
Executor 自愈执行 E
Knowledge Base 决策与效果记录 K
Config Center 配置 / 规则下发 支撑

七、模块之间是如何协作的？

前面的章节中，我们把 AegisCloud 拆成了多个职责清晰的模块。
但一个系统是否“自治”，并不取决于模块划分得有多漂亮，而在于：

当系统出问题时，这些模块能不能自然地协同起来。

在 AegisCloud 中，一次完整的自治过程，并不是一条直线，而是一个持续运行的闭环。

7.1 异常，从“被感知”开始

一切自治行为的起点，都来自 Observer。

当系统运行过程中出现异常时——
无论是指标突增、错误率升高，还是链路异常——
Observer 都会将这些变化抽象为结构化的运行状态。

这一步不做判断，只做事实记录：

  • 发生了什么
  • 发生在什么时间
  • 影响了哪些组件

系统首先要“看见问题”，而不是急着解决问题。

7.2 Analyzer：理解异常意味着什么

Observer 输出的只是“现象”，
真正理解问题含义的，是 Analyzer。

Analyzer 会结合当前数据与历史信息：

  • 判断异常是否具有持续性
  • 分析可能的诱因
  • 给出结构化的诊断结论

这一阶段的核心目标是回答一个问题：

“现在的异常，究竟是不是系统需要介入的风险？”

Analyzer 不下结论该怎么做，
它只负责把问题解释清楚。

7.3 Planner：把“判断”变成“可控行为”

有了分析结论，并不意味着系统就可以马上采取行动。

Analyzer 输出的是“判断”，
而系统真正需要的是可执行、可约束的策略。

这正是 Planner 存在的意义。

Planner 会基于分析结果：

  • 生成候选策略
  • 校验策略是否符合安全边界
  • 确保策略本身可回滚、可追溯

在这一阶段，所有“可能带来风险的动作”，都会被过滤掉。

Planner 负责的不是“更聪明”，而是“不出大错”。

7.4 Executor：系统唯一允许“动手”的地方

当策略被确认可执行后，
它才会被交给 Executor。

Executor 是系统中唯一拥有执行权限的模块。

它会：

  • 将策略下发至目标系统
  • 控制执行范围和生效方式
  • 采集执行后的运行反馈

无论策略是否成功，
Executor 都会把结果完整记录下来。

在 AegisCloud 中，
“能不能执行”远不如“能不能停下来”重要。

7.5 Knowledge Base：闭环的最后一步，也是下一次的起点

每一次自治流程的结果，都会被写入 Knowledge Base：

  • 当时发生了什么异常
  • 系统是如何分析的
  • 采取了什么策略
  • 最终效果如何

这些信息不会立刻改变系统行为，
但会在未来的分析阶段被反复使用。

正是因为有了 Knowledge Base，
系统才不会永远停留在“第一次面对问题”的状态。

7.6 为什么这是一个“闭环”

这五个步骤，并不是一次性流程。

执行结果会反过来影响：

  • 后续的异常判断
  • 策略生成的倾向
  • 系统对风险的认知

也正因为如此，AegisCloud 的自治能力是可以逐步演进的：

  • 一开始依赖规则
  • 逐步引入 AI
  • 长期实现人机协同

自治不是自动化，而是“可学习、可修正的系统行为”。

八、写在最后

AegisCloud 并不是一个“炫技项目”。

它的出发点也不是：

  • 为了证明架构有多复杂
  • 为了展示 AI 有多聪明

而是一个在真实系统中反复出现的问题：

当系统越来越复杂，人是否必须永远站在最前线？

在微服务规模尚可控的时候，
靠经验、靠值班、靠人盯，系统还能勉强运转。

但当系统变得足够复杂时，
问题往往不是“人不努力”，
而是人的认知已经跟不上系统的复杂度。

AegisCloud 想做的，并不是替代人，
而是让系统具备一部分自我感知、自我修正的能力，
把人从“重复判断与应急操作”中解放出来。

这并不是一蹴而就的事情。

自治能力，不是某个框架、某个模型、某个组件就能解决的，
它需要在工程系统中，一点一点长出来。

接下来的文章中，我会从最基础的微服务能力开始，
逐步搭建 AegisCloud 的每一个模块，
让这个自治系统在真实的工程约束下慢慢成型。

这不是一个答案，
而是一条正在探索的路径。