一 分布式系统
1.1 分布式系统概念
软件的架构由单体结构演变为分布式架构,具有分布式架构的系统叫分布式系统。
分 布式系统的运行
通常依赖网络,它将单体结构的系统分为若干服务,服务之间通过网络交互来完成用户的业务处 理
,当
前流行的微服务架构就是分布式系统架构:
![](https://img-blog.csdnimg.cn/2021081723192560.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEwNjY0NzA=,size_16,color_FFFFFF,t_70)
1.2 分布式系统的特点
分布式系统具体如下基本特点:
1
、
分布性
:
每个部分都可以独立部署,服务之间交互通过网络进行通信
,比如:订单服务、商品服务。
2
、
伸缩性
:每
个部分都可以集群方式部署,并可针对部分结点进行硬件及软件扩容
,具有一定的伸缩能力。
3
、共享性:每个部分都可以作为共享资源对外提供服务,多个部分可能有操作共享资源的情况。
4
、开放性:每个部分根据需求都可以对外发
布共享资源的访问接口
,并可允许第三方系统访问。
1.3 分布式认证要求
1.统一认证授权
2.应用接入认证
二 认证方案
2.1 基于session认证
在分布式的环境下,基于
session
的认证会出现一个问题,每个应用服务都需要在
session
中存储用户身份信息,通 过负载均衡将本地的请求分配到另一个应用服务需要将session
信息带过去,否则会重新认证。
![](https://img-blog.csdnimg.cn/20210817232415941.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEwNjY0NzA=,size_16,color_FFFFFF,t_70)
这个时候,通常的做法有下面几种:
1.将通过ningx制定ip哈希轮询策略,将一台机器制定一直访问某台机器,session信息在这台机器进行存储。
2.在其中一台机器产生session信息后,通过复制操作,复制到其他节点上去。(如果节点过多,此方案不靠谱,有些节点还没有轮到复制,就被点到进行访问,结果上面没有session信息)
3. 将session信息集中到一台机器上进行存储,常用的有redis服务器。
总体来讲,基于
session
认证的认证方式,可以更好的在服务端对会话进行控制,且安全性较高。但是,
session
机 制方式基于cookie
,在复杂多样的移动客户端上不能有效的使用,并且无法跨域,另外随着系统的扩展需提高 session的复制、黏贴及存储的容错性。
2.2 基于token认证
基
于token的认证方式,服务端不用存储认证数据,易维护扩展性强, 客户端可以把token 存在任意地方,并且可以实现web和app统一认证机制
。其缺点也很明显,
token由于自包含信息
,因此一般数据量较大,而且每次请求都需要传递,因此比较占带宽。另外,
token的签名验签操作也会给cpu带来额外的处理负担。
![](https://img-blog.csdnimg.cn/20210821125051662.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEwNjY0NzA=,size_16,color_FFFFFF,t_70)
2.3 基于session认证与token认证
基于
session的认证方式
由
Servlet
规范定制,
服务端要存储session信息需要占用内存资源,客户端需要支持 cookie
;
基于
token的方式
则一般
不需要服务端存储token,并且不限制客户端的存储方式
。如今移动互联网时代更多类型的客户端需要接入系统,系统多是
采用前后端分离的架构进行实现,所以基token的方式更适合。
2.4 技术方案认证
2.4.1 分布式认证流程图
采用基于
token
的认证方式,它的优点是:
1
、适合统一认证的机制,客户端、一方应用、三方应用都遵循一致的认证机制。
2
、
token认证方式对第三方应用接入更适合,因为它更开放
,可使用当前有流行的开放协议
Oauth2.0
、
JWT
等。
3
、
一般情况服务端无需存储会话信息,减轻了服务端的压力
。
流程描述:
(
1
)用户通过接入方(应用)登录,接入方采取
OAuth2.0
方式在统一认证服务
(UAA)
中认证。
(
2
)
认证服务(UAA)调用验证该用户的身份是否合法,并获取用户权限信息。
(
3
)
认证服务(UAA)获取接入方权限信息,并验证接入方是否合法
。
(
4
)若登录用户以及接入方都合法,
认证服务生成jwt令牌返回给接入方
,其中
jwt
中包含了用户权限及接入方权限。
(
5
)后续,
接入方携带jwt令牌对API网关内的微服务资
源进行访问。
(
6
)
API
网关对令牌解析、并验证接入方的权限是否能够访问本次请求的微服务。
(
7
)如果接入方的权限没问题,
API
网关将原请求
header
中附加解析后的明文
Token
,并将请求转发至微服务。
(
8
)
微服务收到请求,明文token中包含登录用户的身份和权限信息
。因此后续微服务自己可以干两件事:
1
用 户授权拦截(看当前用户是否有权访问该资源)
2
将用户信息存储进当前线程上下文(有利于后续业务逻辑随时 获取当前用户信息)
1
)统一认证服务
(UAA)
它承载了
OAuth2.0
接入方认证、
登入用户的认证、授权以及生成令牌的职责
,完成实际的用户认证、授权功能。
2
)
API
网关
作为系统的唯一入口
,
API
网关为接入方提供定制的
API
集合,它可能还具有其它职责,如
身份验证、监控、负载均 衡、缓存等
。API
网关方式的核心要点是,
所有的接入方和消费端都通过统一的网关接入微服务
,在网关层处理所 有的非业务功能。