网关技术对比
| cloud-netflix-zuul(zuul 1.x) | Spring Cloud Gateway | Zuul 2.x | |
|---|---|---|---|
| cloud-netflix-zuul(zuul 1.x) | Spring Cloud Gateway | Zuul 2.x | |
| 维护&社区 | 停止更新，维护状态，Spring 社区活， 官方文档偏少 | 持续，社区活跃，中英文文档都有 | 资料有限，基本都在 Netflix 官方，英文文档 |
| 生态 | Cloud 生态，新版本不再支持（只剩 Eureka） | Cloud 生态，不仅限于 Netflix。组件集成支持更方便 | 不支持 Cloud 生态，Netflix 原生组件支持 |
| 可用性 | 集群部署 + 注册中心 | 集群部署 + 注册中心 | |
| 支持功能 | 限流、熔断、重试、负载均衡（需要集成相关组件）Groovy 动态加载 Filter 监控（actuator） | 内置：路由重写、限流、熔断、更灵活的动态路由（断言 Request 的任何内容、filter 可全局可局部路由）灰度更灵活监控（actuator） | Core FeaturesNetty 连接池管理 自适应重试、请求尝试等Groovy 动态加载 Filter |
| 不支持功能 | 长连接、websocket路由重写动态路由需要监听 Apollo 配置刷新灰度（eureka metedata 打标 + 过滤器） | 动态路由需要监听 Apollo 配置刷新 | 令牌桶限流路由重写 |
| 易用性 | 易上手 | 易上手（官方内置过滤器、断言多，开箱即用性高）已有银行内部网关 mbs-broker，目前只支持银行资源的简单转发 | 存在 Spring 集成难度，使用不够灵活 |
| 扩展性 | Filter：pre、post、route、error应用需要通过代码方式 | predicate、filter（global）＝ 自定义配置自定义predicate、filter 可以通过名称前缀在配置文件或配置中心中应用 | Filter（sync & asnyc）：incoming、endpoint、outgoing |
| 管理界面 | Spring Boot Admin 仅能查看(接入 actuator 端口） | Spring Boot Admin(接入 actuator 端口）支持有限的查和改，详情见下文 | |
| 公司基础架构支持 | 兼容 | 基于Spring Framework 5.0 & Boot 2.x。 公司基础架构是基于 Boot 1.5，Framework 4.x，就不能直接用。 简单使用，没有任何改造成分，可以不考虑相关组件的兼容性。否则基础架构前提下，需要调研成本。 | 不兼容 Spring Cloud 体系，需要开发成本。 |
Spring Boot Admin 动态路由
对路由查询及修改的支持本身是基于 Spring Cloud Gateway 提供出来的 actuator 接口（Spring Cloud Gateway）。
可以进行简单的使用，但是缺点也很明细：
-
严重性低：使用语法是 Json，不像配置的使用那么简单明了
-
严重性低：仅使用网关相关功能，仅需开放网关服务的路由相关 actuator 接口
-
严重性中：使用体验上，比较支持简单使用。查看和操作体验一般
-
严重性中：无版本控制，无法回滚或查看历史路由。
-
严重性中：配置、注册中心的路由不可修改、不可删除，只有在 Admin 界面新增的路由可以删除（不能修改，先删后增）。
-
严重性高：在 Admin 新增的路由通常存在内存中，重启就会丢失。
-
严重性高：无法一键发布路由改动到所有实例，单次操作只能更改一个实例
扩展性：
- 可改数据源：扩展路由数据源获取类
RouteDefinitionRepository，从可靠数据源中获取 - 修改原 actutor 更新接口，将新路由写入数据源。（待验证是否可行，备案：新增一个接口，但是 admin 前端就要改）
- 路由刷新消息扩散到所有实例：
- 相关消息组件支持
- 实例监听数据源变动（短期可用数据库做定时查询，长期用类似 Redis 带监听功能的数据源，数据库兜底）
- 前端通知所有实例（不大行）
附录一：Gateway 版本
支持版本：Spring Framework 5.x，SpringBoot 2.x 及以上
