单体架构系统迁移到微服务架构的用户认证方法

摘要

本发明公开了一种单体架构系统迁移到微服务架构的用户认证方法，包括步骤：1)将原有单体架构系统根据业务拆分成多个独立的微服务；2)利用Spring Cloud官方提供的开源组件搭建微服务运行支撑环境；3)基于OAuth2.0协议搭建独立的身份认证服务；4)浏览器、客户端以及第三方应用通过身份认证服务进行用户认证，获取访问令牌；5)浏览器、客户端以及第三方应用携带访问令牌访问受保护的微服务资源。本发明解决单体架构迁移微服务架构过程中用户账号密码不可直接迁移到微服务用户认证服务中的问题，避免明文密码的传输，保证用户信息安全，并且能够根据不同的请求来源授予不同的访问权限，保护微服务资源的API安全。

说明书

技术领域

本发明涉及微服务架构和互联网安全的技术领域，尤其是指一种单体架构系统迁移到微服务架构的用户认证方法。

背景技术

近年来，包括Netflix，Amazon在内的许多互联网公司将应用架构调整为微服务架构。微服务架构由SOA发展而来，是指将原有的单体架构应用拆分成一套独立的小规模服务，每个服务拥有自己的进程，服务之间通过HTTP等轻量级协议进行通信。根据已有研究可以知道，使用微服务架构后每个微服务独立开发部署，减少了依赖地狱的可能，同时可以根据服务提供的功能选择最优的编程语言，数据库等不同的技术栈，提高系统的可扩展性和可维护性，更好的支持持续集成和持续交付。

由于微服务具有以上优势，而且能更加适应云环境的特点，越来越多的公司开始尝试原有单体架构系统重构。用户认证方式的切换是架构迁移过程中的一个难点，任何有安全保障的系统的数据库中存放的用户信息都是加密过的，无法直接获取用户账号和明文密码，而且大多数的系统都是拥有自己独特的不可逆加密算法加密，无法解密出明文密码。微服务架构中通常需要一个独立的认证服务来提供认证功能，保护原有的单体架构拆分出的所有微服务资源，并且可以认证请求来源的不同授予不同的资源访问权限，更好的保护微服务资源。认证服务要访问自己独立的数据库，无法获取原有系统的用户账号以及明文密码是实施独立的认证服务中的一个关键问题。

发明内容

本发明的目的在于克服现有技术的由缺点与不足，提出了一种单体架构系统迁移到微服务架构的用户认证方法，解决单体架构迁移微服务架构过程中原有系统用户账号密码不可直接迁移到微服务用户认证服务中的问题，同时避免明文密码的传输，保证了系统的用户信息安全，并且能够根据不同的请求来源授予不同的访问权限，保护了微服务资源的API安全，使得原有单体架构系统能够更加安全方便的迁移到微服务架构。

为实现上述目的，本发明所提供的技术方案为：单体架构系统迁移到微服务架构的用户认证方法，包括以下步骤：

1)将原有单体架构系统根据业务拆分成多个独立的微服务；

2)利用Spring Cloud官方提供的开源组件搭建微服务运行支撑环境；

3)基于OAuth2.0协议搭建独立的身份认证服务，为微服务提供访问保护；

4)浏览器、客户端以及第三方应用通过身份认证服务提供的新接口进行用户认证，获取访问令牌；

5)浏览器、客户端以及第三方应用携带访问令牌访问受保护的微服务资源。

在步骤1)中，根据业务模块将原有的单体架构系统拆分成不同的微服务，每一个微服务都访问自己独立私有的数据库，能够独立开发测试部署运维，提供完整的功能，提供给其它微服务或者浏览器、客户端以及第三方应用调用。

在步骤2)中，利用Spring Cloud官方提供的开源组件搭建微服务运行支撑环境，具体包括以下三部分：

利用Zuul组件搭建服务网关，是访问所有微服务接口的统一入口；

利用Eureka组件搭建服务注册中心，为所有微服务提供服务注册和发现；

利用SpringBoot Admin组件搭建微服务监控中心，监控各个微服务的运行状态。

在步骤3)中，基于OAuth2.0协议搭建身份认证服务是微服务架构下用户统一认证的关键，具体包括以下步骤：

3.1)当浏览器、客户端或者第三方应用提交用户认证时，认证服务查看自身数据库中是否拥有账号密码信息，当账号密码信息存在时，直接认证后转步骤3.3)，否则转步骤3.2)；

3.2)新的用户认证服务向原有系统登陆接口验证账号密码，如果正确，则使用Bcrypt加密算法加密密码后将加密密码和用户账号写入认证服务自身数据库；

3.3)将认证结果返回给发起认证请求的浏览器、客户端或者第三方应用；

所有的微服务接口的访问入口都是微服务网关Zuul组件，所以通过认证服务对网关服务提供认证保护即可保护所有的微服务资源，只有通过认证服务认证过的请求才会被网关服务处理，转发到相应的微服务；认证未通过的请求或者认证失败的请求不会被网关服务处理。

在步骤4)中，浏览器、客户端以及第三方应用通过身份认证服务提供的新接口进行用户认证，获取访问令牌；不同的客户端获取访问令牌的方式不同，系统原生客户端能够直接获取账号密码，所以通过用户账号密码以及客户端唯一标识client_id即可在认证服务认证后获取访问令牌access_token；但是第三方应用或者第三方客户端，无法获得用户的账号密码信息，需要用户在系统中授权后获取访问令牌，具体步骤如下：

4.1)用户在第三方应用选择通过统一认证服务器登陆；

4.2)第三方应用服务器将请求重定向到认证服务器，并且带上认证服务提供的唯一标识应用的client_id和回调地址redirect_url；

4.3)用户看见登陆授权请求页面并且同意应用的请求；

4.4)认证服务器在接收到授权后，返回一个重定向响应，并生成一个code附在回调地址redirect_url后；

4.5)第三方应用后台服务器在接收到步骤4.4)中的重定向请求后，带上code向认证服务器发出请求交换访问令牌access_token；

4.6)认证服务器验证唯一标识第三方应用的client_id和步骤4.5)中提供的code，验证成功后返回访问令牌access_token。

在步骤5)中，认证后的浏览器、客户端以及第三方应用携带访问令牌访问受保护资源，当获得了访问令牌之后，所有请求在请求头中添加访问令牌access_token的信息，即可访问受认证服务保护的微服务资源。

本发明与现有技术相比，具有如下优点与有益效果：

1、本发明首次实现了单体架构迁移微服务架构的用户认证平滑升级服务，保证了单体架构迁移微服务架构后的系统安全。

2、本发明首次实现了不涉及用户明文密码的用户信息迁移，保证了用户的信息安全，同时支持全新的统一认证服务。

3、本发明通过使用OAuth2.0协议，根据不同的请求来源，授予拥有不同访问权限的令牌，第三方应用不用获取用户的账号密码即可访问部分用户资源，对第三方应用开发以及用户使用都更加方便，同时分级权限的访问令牌也能更加细粒度的保证用户和微服务系统资源的安全。

4、本发明方法在所有的原有单体架构系统迁移微服务架构的系统中具有广泛的使用空间，与编程语言等技术栈无关，普适性强，在传统IT应用微服务化和传统IT应用上云方面有广阔前景。

附图说明

图1为本发明方法流程图。

图2为本发明获取访问令牌并请求受保护资源的时序图。

具体实施方式

下面结合具体实施例对本发明作进一步说明。

如图1和图2所示，本实施例所提供的单体架构系统迁移到微服务架构的用户认证方法，需要先对原有的单体架构应用进行拆分，并且利用Spring Cloud提供的额开源组件搭建微服务运行支撑环境，然后搭建发明中所述保护整个微服务体系的用户认证服务，具体包括以下步骤：

1)根据业务模块将原有的单体架构系统拆分成不同的微服务，每一个微服务都访问自己独立私有的数据库，能够独立开发测试部署运维，提供完整的功能，可以提供给其他微服务或者浏览器，客户端以及第三方应用调用。

2)利用Spring Cloud官方提供的开源组件搭建微服务运行支撑环境，具体包括以下三部分：

利用Zuul组件搭建服务网关，是访问所有微服务接口的统一入口；

利用Eureka组件搭建服务注册中心，为所有微服务提供服务注册和发现；

利用SpringBoot Admin组件搭建微服务监控中心，监控各个微服务的运行状态。

3)基于OAuth2.0协议搭建独立的身份认证服务，为微服务提供访问保护。搭建身份认证服务是微服务架构下用户统一认证的关键，具体包括以下步骤：

3.1)当浏览器、客户端或者第三方应用提交用户认证时，认证服务查看自身数据库中是否拥有账号密码信息，当账号密码信息存在时直接认证后转步骤3.3)，否则转步骤3.2)；

3.2)新的用户认证服务向原有系统登陆接口验证账号密码，如果正确则使用Bcrypt加密算法加密密码后将加密密码和用户账号写入认证服务自身数据库；

3.3)将认证结果返回给发起认证请求的浏览器、客户端或者第三方应用；

所有的微服务接口的访问入口都是微服务网关Zuul组件，所以通过认证服务对网关服务提供认证保护即可保护所有的微服务资源，只有通过认证服务认证过的请求才会被网关服务处理，转发到相应的微服务；认证未通过的请求或者认证失败的请求不会被网关服务处理。

4)浏览器、客户端以及第三方应用通过身份认证服务提供的新接口进行用户认证，获取访问令牌。不同的客户端获取访问令牌的方式不同，系统原生客户端能够直接获取账号密码，所以通过用户账号密码以及客户端唯一标识即可在认证服务认证后获取访问令牌access_token；但是第三方应用或者第三方客户端，无法获得用户的账号密码信息，需要用户在系统中授权后获取访问令牌，具体步骤如下：

4.1)用户在第三方应用选择通过统一认证服务器登陆；

4.2)第三方应用服务器将请求重定向到认证服务器，并且带上认证服务提供的唯一标识应用的client_id和回调地址redirect_url；

4.3)用户看见登陆授权请求页面并且同意应用的请求；

4.4)认证服务器在接收到授权后，返回一个重定向响应，并生成一个code附在回调地址redirect_url后；

4.5)第三方应用后台服务器在接收到步骤4.4)的重定向请求后，带上code向认证服务器发出请求交换访问令牌access_token；

4.6)认证服务器验证唯一标识第三方应用的client_id和步骤4.5)中提供的code，验证成功后返回访问令牌access_token。

5)认证后的浏览器、客户端以及第三方应用携带访问令牌访问受保护资源，当获得了访问令牌之后，所有请求在请求头中添加访问令牌access_token的信息，即可访问受认证服务保护的微服务资源。

综上所述，在采用以上方案后，解决单体架构迁移微服务架构过程中原有系统用户账号密码不可直接迁移到微服务用户认证服务中的问题，同时避免明文密码的传输，保证了系统的用户信息安全，并且能够根据不同的请求来源授予不同的访问权限，保护了微服务资源的API安全。本发明与编程语言等技术栈无关，在所有的原有单体架构系统迁移微服务架构的系统中具有广泛的使用空间，普适性强，在传统IT应用微服务化和传统IT应用上云方面有广阔前景，值得推广。

以上所述实施例只为本发明之较佳实施例，并非以此限制本发明的实施范围，故凡依本发明之形状、原理所作的变化，均应涵盖在本发明的保护范围内。