统一网关服务

码匠君2024/12/25大约 8 分钟开发服务OAuth2.1认证登录授权模式Spring Authorization Server

概述

微服务架构中，后端的各个服务都是可以独立运行的小型应用。在对外提供接口服务时，如果还是按照各个应用独立的方式提供，就好比是多个独立运行的单体系统，不仅失去了微服务架构的意义，而且还提升了管理和使用的复杂度。

微服务网关的作用，就是为后端服务提供一个统一的出入口。后端所有所服务的接口通过网关对外提供服务，就像单体系统中的 核心控制器 一样，拦截所有的请求。并集合服务发现机制，最终将请求分发至指定的服务。

注意

虽说网关是重要的安全防护措施，但是仅靠网关无法达到生产级的防护的。部署至生产环境时，还需要很多其它的安全防护措施，常见的措施例如：

服务网关拦截到请求之后，将请求转发至对应的服务，就叫做网关路由。网关路由是需要配合服务发现机制才能正常运行的，即通过请求中的指定映射，找到对应的服务。

通常网关路由有两种管理方式：静态路由和动态路由。

静态路由：手动在网关服务的配置文件中，配置好具体的映射以及相关配置。这种方式灵活性比较高，可以针对不同的服务进行个性化的定制。但是问题也比较突出，一旦需要修改就需要重启网关服务，对整体的运行产生影响。
动态路由：无需在配置文件中进行配置，利用 Spring Cloud 以及生态组件提供的动态能力，动态生成路由。这种方式可能对于服务的个性化定制不够方便，但是对于整体的运行维护来说性价比更高。

Dante Cloud 默认采用的就是动态路由方式，只要服务正常启动并且成功注册到服务注册中心，通过服务名就可以实现请求的转发，无需其它的额外配置。当然，如果你有特殊的

不管是微服务系统还是单体系统，API 接口的鉴权都是必不可少的安全保障措施。这里，我们不妨先对单体架构和微服务架构中，接口鉴权的相同点与不同点，做一个简单的分析。

虽然，还没有详细介绍微服务架构的的鉴权逻辑，但是凭借我们个人的经验，完全可以做这个分析。

相同点：不管哪种架构，都会存在自己的接口（REST API），然后通过某种权限框架或者自研的权限体系进行鉴权。
不同点：单体架构就自身一个应用，自己的接口（REST API）自己来鉴权即可。微服务架构是由多个服务组合而成，也一定存在一个地方或者组件对接口（REST API）进行鉴权，但是具体放在哪里、怎么实现会有很大的不同。

继续分析一下，即使没有微服务应用设计和开发经验，也可以想到，要么就是在一个服务中统一进行接口的鉴权，要么就是每个服务自己负责自身接口的接口的鉴权。

而实际的微服务架构鉴权设计中，常见的模式也就是两种：

方案一，资源提供服务各自鉴权：这种模式下，对外提供接口的服务（OAuth 2 中的资源服务器），自己对自己的接口进行保护。
方案二，服务网关统一认证鉴权：微服务架构中一般都会有微服务网关，比如 Spring Cloud Gateway，作为请求的统一入口，来实现对接口的统一保护。因为是统一入口，那么在网管进行接口的鉴权，就是一个不二的选择。

方案二，就是很多产品宣传的 网关统一鉴权

Dante Cloud 的鉴权方案选择的是前面所说的 方案一，即由各个服务负责自身 REST 接口的鉴权。之所以选择这个方案，主要由以下几个原因：

因为系统使用的是 Spring Security 生态，而 Spring Security 自身的机制和推荐方式，就是由各个服务自身负责自己接口的鉴权
个人观点认为：网关统一鉴权 并不是一个合理的方式
- 因为如果要实现网关统一鉴权，势必需要在网关服务中增加更多的管理功能，管理功能的增加就意味着关键数据在“网关”层面的暴露。这不仅弱化了网关保护措施的定位，反而需要更多保护措施来保护网关服务自身。
- 从架构角度考虑，网关统一鉴权 就像是将一个传统单体应用作为网关，网关之后又带了诸多无法保护自身接口安全的 Spring Boot 应用。
- 网关统一鉴权 ，网关服务不仅要肩负请求拦截、请求路由职责，还要肩负接口鉴权甚至数据鉴权以及权限管理职责，会增大网关服务的压力。

注意