Spring Cloud微服务下的权限架构调研
随着微服务架构的流行，系统架构调整，项目权限系统模块开发提上日程，需要对权限架构进行设计以及技术选型。所以这段时间看了下相关的资料，做了几个对比选择。
一、架构图
初步设想的架构如下，结构很简单：eureka为服务注册中心，config是服务配置中心，redis做为缓存服务，gateway是后端网关。目前只设计了一套节点，考虑系统高并发高可用性后续可部署多套节点，Nginx做负载均衡以及增加熔断、失败重试等。系统流程为：客户端请求经Nginx转发到后端网关，网关直接转发到权限系统进行认证授权，统一在网关做鉴权，鉴权通过则转发到对应微服务。
二、技术选型
① 用户权限
在传统的单体应用中，很多项目用的是shiro，毕竟shiro功能强大又灵活。而在Spring Cloud微服务架构中，好像大家更喜欢用Spring Security，所以了解了一下这两个框架的区别，大致如下：
- Shiro比Spring更容易使用、实现和理解。
- Spring Security更加知名是因为品牌名称。
- 很多人发现Spring Security使用比较麻烦。
- Spring Security有更好的社区支持。
- Apache Shiro在Spring Security处理密码学方面有一个额外的模块。
- Spring Security 对Spring 结合较好，并且不能脱离Spring，如果项目用的SpringMVC ，使用起来很方便。
- Shiro 功能强大、且 简单、灵活。是Apache 下的项目比较可靠，且不跟任何的框架或者容器绑定，可以独立运行。
- Spring Security支持Oauth、OpenID
- 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。
三、系统工作流
简单画了下访问系统时系统的工作流：
系统架构的设计相对简单，后续可能还要经过讨论进行调整。架构需要达到业务需求并且具备高并发、高可用、可扩展性，不能因为项目的变更或者用户体量上升等等原因出现不可扩展、重构、大调整等问题。
