随着微服务架构的流行,系统架构调整,项目权限系统模块开发提上日程,需要对权限架构进行设计以及技术选型。所以这段时间看了下相关的资料,做了几个对比选择。
一、架构图
初步设想的架构如下,结构很简单: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。
三、系统工作流
简单画了下访问系统时系统的工作流:
系统架构的设计相对简单,后续可能还要经过讨论进行调整。架构需要达到业务需求并且具备高并发、高可用、可扩展性,不能因为项目的变更或者用户体量上升等等原因出现不可扩展、重构、大调整等问题。