前言

在分布式开发中，我们需要了解一下什么是分布式系统以及它的特性。只有了解了这些知识点，才方便我们后面学习分布式系统的认证授权。

什么是分布式系统

随着软件环境和需求的变化，软件的架构由单体结果演变为分布式架构，具有分布式架构的系统叫分布式系统，分布式系统的运行通常依赖网络，它将单体结果的系统分为若干服务，服务之间通过网络交互来完成用户的业务处理，当前流行的微服务结构就是分布式系统，如下图：

特点

分布式系统具体由如下基本特点：

• 1、分布性：每个部分都可以独立部署，服务之间交互通过网络进行通信，比如：订单服务、商品服务。
• 2、伸缩性：每个部分都可以集群方式部署，并可针对部分结点进行硬件及软件扩容，具有一定的伸缩能力。
• 3、共享性：每个部分都可以作为共享资源对外提供服务，多个部分可能有操作共享资源的情况。
• 4、开发性：每个部分根据需求都可以对外发布共享资源的访问接口，并可允许第三方系统访问。

分布式认证需求

分布式系统的每个服务都会有认证、授权的需求，如果每个服务都实现一套认证授权逻辑会非常冗余，考虑分布式系统共享性的特点，需要由独立的认证服务处理系统认证授权的请求；考虑分布式系统开发的特点，不仅对系统内部的服务提供认证，对第三方系统也要提供认证。

分布式认证的需求总结如下：

统一认证授权

• 1、提供独立的认证服务，统一处理认证授权。
• 2、无论是不同类型的用户，还是不同种类的客户端（web端、H5、APP），均采用一致的认证、权限、会话机制，实现统一认证授权。
• 3、要实现统一则认证方式必须可拓展，支持各种认证需求，比如：用户密码认证、短信验证码、二维码、人脸识别等方式，并可以非常灵活的切换。

应用接入授权

应提供拓展和开放能力，听安全的系统对接机制，并可开放部分API给接入第三方使用，一方应用（内部系统服务）和三方引用（第三方引用）均采用统一机制接入。

分布式认证方案

选型分析

1、基于session的认证方式

在分布式的环境下，基于seesion的认证会出现一个问题，每个应用服务都需要在session中存储用户身份信息，通过负债均衡将本地的请求分配到另一个应用服务需要将session信息带过去，否则会重新认证。

这个时候，通常的做法有下面几种：

**Seesion复制：**多台应用服务器之间同步session，使session保持一致，对外透明。

**Session黏贴：**当用户访问集群中某台服务器后，强制指定后续所有请求均落到此机器上。

**Session集中存储：**将session存储分布式缓存（redis）中，所有服务器应用实例统一从分布式缓存中存取Session。（谷粒商城的视频就是这么做的）

总体来讲，基于session认证的认证方式，可以更好的在服务端对会话进行控制，且安全性较高。但是，session机制方式基于cookie，在复杂多样的移动客户端上不能有效的使用，并且无法跨域，另外随着系统的拓展需要提高session的复制、黏贴及存储的容错性。

所以在分布式系统中，在前后端分离和移动应用中，基于session的认证方式就显得不太适合了，虽然可以实现，但没必要。

2、基于token的认证方式

由于token的认证方式，服务端不用存储认证数据，易维护拓展强，客户端可以把token存在任意地方，并且可以实现web和app统一认证机制。其缺点也很明显，token由于自包含信息，因此一般数据量较大，而且每次请求都需要传递，因此比较占带宽。另外，token的签名签操作也会给cpu带来额外的处理负担。

技术方案

根据选定分析，决定采用基于token的认证，它的优点是：

• 1、适合统一认证的机制，客户端、一方应用、三方应用都遵循一致的认证机制。
• 2、token认证方式对第三方应用接入更合适，因为它更开放，可使用当前流行的开发协议Oauth2.0、JWT等。
• 3、一般情况服务端无需存储会话信息，减轻了服务端的压力。

分布式系统认证技术方案见下图：

1、接入方请求授权服务认证

2、认证服务验证登陆用户及接入客户端

3、返回access_token到接入方

4、接入方携带token访问资源，需要发送到网关

5、网关校验token，验证接入端权限

6、附加解析后明文token，转发请求到微服务

7、微服务解析并验证用户权限，若通过则执行业务逻辑，返回结果到接入方

后话

通过上面的流程，就算是知道了微服务的真实地址，微服务自身也会校验一次，防止没有权限的请求直接越过网关访问到资源。

后面会详细讲解实现方法。