Spring Cloud微服务下的权限架构调研

　　随着微服务架构的流行，系统架构调整，项目权限系统模块开发提上日程，需要对权限架构进行设计以及技术选型。所以这段时间看了下相关的资料，做了几个对比选择。

一、架构图

　　初步设想的架构如下，结构很简单：eureka为服务注册中心，config是服务配置中心，redis做为缓存服务，gateway是后端网关。目前只设计了一套节点，考虑系统高并发高可用性后续可部署多套节点，Nginx做负载均衡以及增加熔断、失败重试等。系统流程为：客户端请求经Nginx转发到后端网关，网关直接转发到权限系统进行认证授权，统一在网关做鉴权，鉴权通过则转发到对应微服务。

二、技术选型

　　① 用户权限

　　在传统的单体应用中，很多项目用的是shiro，毕竟shiro功能强大又灵活。而在Spring Cloud微服务架构中，好像大家更喜欢用Spring Security，所以了解了一下这两个框架的区别，大致如下：

1. Shiro比Spring更容易使用、实现和理解。
2. Spring Security更加知名是因为品牌名称。
3. 很多人发现Spring Security使用比较麻烦。
4. Spring Security有更好的社区支持。
5. Apache Shiro在Spring Security处理密码学方面有一个额外的模块。
6. Spring Security 对Spring 结合较好，并且不能脱离Spring，如果项目用的SpringMVC ，使用起来很方便。
7. Shiro 功能强大、且 简单、灵活。是Apache 下的项目比较可靠，且不跟任何的框架或者容器绑定，可以独立运行。
8. Spring Security支持Oauth、OpenID
9. Spring Security的权限细粒度更高（关于这点，从我翻阅到的博客来看，大家一致表示还未发现高在哪里）

　　从以上几点来看，各有优劣，根据具体项目需求进行选择。综合多种原因，我们选用了Spring Security。

　　② 用户认证

　　传统的单体应用都是通过session来做用户认证，在前后端分离后偏向基于token认证。在微服务流行后，Spring Security 结合 OAuth 被推行。关于OAuth可以看看这篇文字 - 理解OAuth 2.0

　　OAuth2分为认证服务器和资源服务器：在这个架构中，Auth Server作为认证服务器，负责对客户端进行认证授权，为客户端颁发令牌。Gateway作为资源服务器，负责对token进行验证来判断是否允许客户端的访问操作。

　　OAuth2包含4种授权模式：

• 授权码（认证码）模式 （Authorization code)
• 简化（隐形）模式 (Impilict
• 密码模式 (Resource Owner Password Credential)
• 客户端模式 (Client Credential)

　　根据项目业务情况，我们这里目前采用密码模式，随着项目运作模式的改变、版本的大更新，后面不排除会使用其他授权模式。

　　③ JWT认证协议

　　JWT（JSON Web Token）是一种认证协议，是目前最流行的跨域身份验证解决方案。它将用户信息加密到token里并由客户端存储，服务器不保存任何用户信息。服务器通过使用保存的密钥验证token的正确性，只要正确即通过验证。

　　JWT优点是可以解决Session共享问题，提高后端服务的可用性和扩展性；缺点是无法作废已颁发的令牌，虽然可以通过其他途径实现，但是不免有些麻烦，而且违背了JWT的初衷。结合我们的项目来看，我认为使用JWT的弊是大于利的，所以这里我不打算使用JWT，延续以往的实现方式，在Redis中维护token。

三、系统工作流

　　简单画了下访问系统时系统的工作流：

　　系统架构的设计相对简单，后续可能还要经过讨论进行调整。架构需要达到业务需求并且具备高并发、高可用、可扩展性，不能因为项目的变更或者用户体量上升等等原因出现不可扩展、重构、大调整等问题。