SpringCloud多用户认证体系设计方案

一、背景

在大型分布式项目中，存在多系统、多平台、多用户体系的场景，例如典型的门户端、后台管理端这两种用户认证体系，门户端认证通过会员服务或者用户服务完成，后台管理通过内部员工账号体系完成认证。在基于SpringCloud构建的项目中，如何解决一系列鉴权、认证、白名单过滤的问题。

二、项目场景

假设目前有一个电商系统，
会员服务business-customer负责平台用户的管理，包括注册登录、VIP等功能。
管理服务business-system负责后台管理端员工账号管理、登录认证、机构、角色、权限等。
订单服务business-order负责系统中与订单相关的功能，例如用户订单、订单管理、订单分析统计等等。

门户端会调用订单服务，管理端也会调用订单服务，那么调用之前如何进行用户鉴权，如何判断当前用户是管理端用户还是平台端的用户？

三、设计方案

对于分布式项目的架构设计，常见的有以下两种模式。

3.1 方案一

服务通信方式：
基于RPC方式内部服务调用，例如Dubbo、Grpc、Thrift，这些RPC组件是通过TCP协议进行服务远程调用的，所以business-order 订单服务只负责暴露RPC接口，在MVC模式中相当于service层，RPC服务不直接处理HTTP请求。所以这种模式订单服务并不负责处理鉴权认证，由调用方controller层处理。
架构设计：
门户端一个web服务，管理端一个web服务，所有与门户端相关的请求接口都在门户端的web服务内定义，与管理端相关的请求都在管理端的web模块进行定义，接口内部通过RPC组件远程调用相关的服务。

这种方案由于门户端和管理端是独立的web服务，所以鉴权认证可以单独处理， 在各自的接口层进行权限拦截即可。

用户认证
门户端web服务和管理端web服务，可以通过SpringSecurity进行url拦截以及token处理。各自的controller通过@Permission注解进行权限校验即可。

本方案如下图所示：

3.2 方案二

服务通信方式
基于HTTP方式进行调用，例如SpringCloud OpenFeign。这种通信方式导致每个微服务会直接提供HTTP接口，浏览器发起的请求经过网关转发，直接打到各个服务模块，没有单独的门户端web服务或者管理端web服务，此时各个服务并不知道这个请求是门户端还是管理端的请求，因此无法直接进行权限拦截。

架构设计
核心的网关层、服务层。
服务层提供HTTP接口。
例如business-order会提供门户端的订单接口，也会提供管理端的订单接口。

用户认证
核心是网关层的设计，网关分为Nginx与SpringCloudGateway两种方式。
nginx在上层，直接处理http请求，可以抗高并发，也支持lua脚本鉴权认证。
Gateway在下层，属于业务网关，主要做服务转发。也支持GlobalFilter方式的鉴权认证路由过滤。

（1）方式一：

• 一个网关多个Nginx：

门户端和管理端的请求由各自独立的nginx处理，nginx内部做白名单过滤与token验证。经过nginx处理之后统一代理到gateway网关层。

gateway进行header名称判断，例如，如果是portal-token，则将token解析后放到Header中，名称为customerId， 如果是manage-token，则把token解析后放到header， 名成为userId。

business-order中的接口通过@RequestHeader注解获取对用的用户ID，通过@Permission注解实现不同用户ID的权限认证。

独立的nginx解决了请求路由认证的问题。
gateway层解决了用户认证是否成功的问题，通过token判断用户是否已成功登录。

关于接口层面的权限则交由每个接口上的@Permission注解处理。

（2）一个Nginx，多个网关
一个nginx负责路由转发，多个gateway负责处理各自业务的认证。
例如门户端的请求前缀都是/portal， 则将带有此前缀的请求都代理到门户端对应的网关地址。
将带有/manage 前缀的请求都代理到管理端的网关地址。

各网关独立解析header中的token，将token解析后放入header中，需要保证header名称不能相同，否则business-order无法区分该header的用户ID是门户端还是管理端。

（3）多Nginx多网关
这种方式就是结合上面两种方式进行部署，对于复杂大型系统，可以针对不同的业务服务部署独立的nginx服务和独立的业务网关。

如下图所示：