在设计 AegisCloud 之前，我先问了自己一个问题：

一个具备“自治能力”的微服务系统，它的控制点应该在哪里？

这个问题，最终把我引向了一个看似基础、但极其关键的组件：网关（Gateway）。

从一个设计推演开始：如果没有统一入口，会发生什么？

假设在 AegisCloud 中，客户端可以直接访问各个业务服务：

这种架构在系统初期看起来“很简单”，但一旦我们引入以下需求：

  • 统一限流
  • 请求级观测
  • 动态策略生效
  • 自愈执行

问题会立刻出现：

  • 限流逻辑写在哪里？
  • 指标采集是否一致？
  • 自愈策略如何统一下发？
  • 谁是真正的“执行点”？

结论很明确
没有统一入口，系统的执行面一定是碎片化的。

而一个执行面碎片化的系统，是不可能实现自治闭环的。

Gateway 的基础定位：它到底解决什么问题？

在抛开具体项目之前，我们先用最朴素的方式理解 Gateway 的职责。

Gateway 的三大核心能力

能力 说明
统一入口 所有外部请求必经
路由转发 基于服务名转发请求
横切能力 限流、鉴权、观测等

Gateway 不创造业务价值，但它决定系统是否“可控”。

AegisCloud 中的 Gateway：不仅是入口，更是执行点

在 AegisCloud 中，Gateway 的角色被进一步放大了。

在这个结构中：

  • Gateway
    • 所有请求必经
    • 天然的监控与控制点
  • Observer / Monitor
    • 采集流量、RT、异常
  • Analyzer
    • 分析系统是否“异常”
  • Planner
    • 生成治理或自愈策略
  • Executor
    • 将策略动态下发到 Gateway
      Gateway 同时承担了 MAPE-K 中的 Monitor 与 Execute 角色。

技术选型：为什么是 Spring Cloud Gateway？

在 AegisCloud 中选择 Spring Cloud Gateway，原因非常直接：

  • 天生适配微服务架构
  • 与 Nacos Discovery 无缝集成
  • 响应式、性能友好
  • 对限流、熔断、Filter 扩展支持良好

更重要的是：

Gateway 的能力可以被“策略化”，这正是自治系统所需要的。

AegisCloud 中的 Gateway 最小实践

网关模块引入依赖

1
2
3
4
5
6
7
8
9
10
11
12
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>  
    <groupId>org.springframework.cloud</groupId>  
    <artifactId>spring-cloud-starter-loadbalancer</artifactId>  
</dependency>
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

这里我们也同样要导入负载均衡
关于负载均衡的介绍会在下一篇详细说明的

路由配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
server:
  port: 9001

spring:
  application:
    name: aegis-gateway
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
    gateway:  
	  server:  
	    webflux:  
	      discovery:  
	        locator:  
	          lower-case-service-id: true  
	          enabled: true

在早期教程中，Gateway 常通过 spring.cloud.gateway.routes 配置路由。
但在面向自治与动态治理的系统中，这种方式逐渐被弱化，
路由不再是“配置文件的一部分”，而是“系统运行时的一种策略”。
这种配置方法可以让网关从注册中心自动获取其他服务配置的路径。

这里用business-service服务的服务检测接口测试
接口原本的路径为：

1
http://localhost:9002/actuator/health

而我们现在通过网关就可以进行访问了
访问路径：

1
http://localhost:9001/business-service/actuator/health

真实流转路径：

客户端不感知任何真实地址，只知道一个统一入口。

为什么“自治系统”的治理一定从网关开始？

在 AegisCloud 的设计中，我逐渐形成了一个清晰的认知：

治理不是“事后分析”，而是“当下控制”。

而所有“当下控制”的最佳落点，只有一个地方：

  • 请求刚进入系统
  • 策略可以立即生效
  • 不侵入业务代码

这个地方，就是 Gateway。

Gateway × Sentinel × Nacos：AegisCloud 的治理三角

在 AegisCloud 中，Gateway 并不是孤立存在的。
它真正发挥价值，是因为它与 Sentinel 和 Nacos 共同构成了一个清晰的治理三角。

三个组件，各自解决什么问题？

先用一句话拆清职责：

组件 核心角色 解决的问题
Gateway 统一入口 请求从哪里进、怎么进
Sentinel 流量治理 请求能不能进、该不该进
Nacos 控制中心 规则从哪里来、如何变

Gateway 是“执行点”，Sentinel 是“安全阀”，Nacos 是“控制台”。

没有这三者协作，会发生什么？

我们可以做一个简单的架构推演。

❌ 没有 Nacos：规则写死在代码里

问题是：

  • 规则无法动态调整
  • 无法支撑自动化、自愈
  • 每一次策略变更都要发版

这不是自治系统，而是“配置地狱”

❌ 没有 Sentinel：Gateway 只能“转发”

问题是：

  • Gateway 只能路由，无法治理
  • 没有流量保护能力
  • 异常只能“事后发现”

系统没有“安全阀”

AegisCloud 中的完整协作关系

真正的 AegisCloud 结构是这样的：

这里的关键关系是：

  • Gateway
    • 所有请求必经
    • 是策略真正生效的地方
  • Sentinel
    • 挂载在 Gateway 上
    • 决定请求是否被放行、限流、降级
  • Nacos
    • 动态下发规则
    • 不参与请求链路，但掌控系统行为

放到 MAPE-K 中看，会更清晰

对应关系非常明确：

  • Monitor
    • Gateway + Sentinel 产生指标
  • Analyze
    • 后续 AI / 规则分析
  • Plan
    • 策略生成
  • Execute
    • Nacos 下发规则
    • Sentinel + Gateway 立即生效

当 AegisCloud 在“做决定”时，Gateway 是执行结果落地的地方。

小结

入口统一，治理才有落点
Gateway 是微服务系统的必备组件；
在 AegisCloud 中，它是自治系统的执行中枢；
而当 Gateway 与 Sentinel、Nacos 形成协作关系后，
系统才真正具备“被治理、可演进、自我调整”的基础。