连接安全与变革
股票代码:831194

共享 共赢

新闻

技术干货 | 如何设 计统一身份认证高可用
来源:派拉集团时间:17/4/2019浏览量:

为什么统一身 份认证系统需要考虑高可用?

通过建 设一套统一认证的系统,将用户 的登录入口进行统一。用户只 需要知道一个地址,一套用户名口令,进行一次认证,即可实 现所有应用访问,可大大 的提升用户的使用体验。

那么我 们回过头来想一想

既然用 户的访问入口进行了统一,那么从架构上来看,要是这 个统一的入口白旗高高挂起,歇菜了,那岂不 是所有的用户都访问不了? 

统一身份认证系统高可用的实现方式

基本部署架构

我们先 看一下统一身份认证系统作为一个典型的B/S应用系统,所需要的组件:

1、中间件:把统一 身份认证的应用运行起来

2、数据库:进行数据的存储

以上即 可完成最基本的部署。

而最简单的部署、应用程序、数据库 都部署在一台服务器上,即可运行起来:

应用、数据分离架构

随着业务的扩展,一台服 务器已经不能满足性能需求,同时,考虑数据的安全性,所以将应用程序、数据库 各自部署在独立的服务器上,显得很有必要。

并且根 据服务器的用途配置不同的硬件,可以达 到较好的性能效果。

 应用服 务集群部署架构

统一身 份认证系统作为用户的统一且唯一的认证入口,同时还 会承担所有用户的大量请求。

为解决 应用服务器的单点故障问题,我们可 以通过增加应用服务器,进行集群部署。

同时,多台服 务器同时提供服务,可以降 低单台应用服务器所承受的服务压力,提高系统的服务性能,提升用户的访问速度。

应用服 务器前面部署负载均衡服务器调度用户请求,根据分 发策略将请求分发到多个应用服务器节点。

当系统 的性能达到瓶颈时,也可以 采用横向扩展应用服务器的方式进行性能扩容。

常用的 负载均衡的选择上,通常有 硬件及软件两种方案:

硬件方案:价格比较昂贵,通常有F5、Redware等硬件产品;

软件方案:通常使用LVS(Linux Virtual Server)、HAProxy、Nginx等方式,其中LVS工作于四层网络,HAProxy可工作 于四层及七层网络,Nginx工作于七层网络,最新版的Nginx(1.9版本后)加入了 四层网络的支持;

另外,最近Nginx被F5重金收购,在IT界也算闹了个大新闻。

负载HA部署架构

从以上应用服 务集群部署架构上来看,虽然统 一认证应用服务已实现了集群部署,多台服 务器提供服务避免了单点故障的问题。但是负 载均衡服务同样面临着单点故障的问题,如负载 均衡服务出现问题,所有用 户依然无法正常访问。

所以,对负载均衡设备进行HA高可用部署,同样显得很有必要:

通过将 负载均衡服务进行HA高可用部署,当当前 提供服务的负载均衡服务出现故障时,可自动 将服务切换到热备的均衡负载设备上,保障系 统不间断的提供服务。

在这里,所涉及到的HA高可用 部署方案实现主备服务间的自动切换,根据负载设备的硬件、软件方案的不同,同时也会有不同的HA高可用部署方案:

负载设 备采用硬件方案(F5、Redware等)时,可使用 硬件厂商自身提供的HA方案;

 负载设 备采用软件方案(LVS、HAproxy、Nginx等)时,通常可 供选择的方案有Heartbeat、Keepalived等选择。

数据服 务集群部署架构

最后来 到部署架构中最关键的一环,我们的 数据库依然是单点提供服务,这也是 必须需要解决的一环:

对数据 库服务进行集群部署,即可解 决数据服务单点故障的问题。

在数据 库的集群部署上,根据不 同的数据库产品,同样有 着不同的集群技术方案,以下列 举以下主流的几种数据库的集群方案:

 Oracle,采用共享存储实现RAC集群方案,数据存 放在一个共享存储中,多个数 据节点同时操作数据;

 MySQL,可采用主主复制、主备复制模式,数据放 在各自服务器上,通过配置的主主复制、主备复 制模式实现数据文件的同步;

DB2,可提供HADR、pureScale等部署技术,其中HADR技术为 双活节点的部署模式,通过数 据库日志复制的方式实现节点间的数据同步,pureScale技术则为多服务节点+共享存储的部署模式;

故障会 话保持部署架构

通过将 统一认证服务进行集群部署、均衡负载设备进行HA高可用部署、数据库 采用集群架构部署后,已经可 以满足绝大部分用户使用的业务场景的不间断服务了。

为什么 说是满足了绝大部分用户呢?

在这里需要重温一下http web会话的知识,一个完整的web会话,由浏览器+web服务组成,以java应用部署在tomcat上为例:

从这里可以看出,web会话其实是基于cookie-session这样的 机制来确认用户是谁,否则一 万个用户同时访问了web应用,服务端 无法定位哪个浏览器过来的请求是哪个用户的。

那么,统一认 证的服务运行在中间件服务器上,也就是 说最终还是依赖于cookie-session这样的会话机制。

再回到我们的架构上,虽然统一认证的服务(IAM)采用了 集群的部署架构,同时也 可以通过前端的负载均衡的设备配置会话保持的访问策略,使每个 用户的请求通过均衡负载的服务后,固定的 分发到一台服务器上,从而保 障用户最终访问到的统一认证的服务器上存在该用户的session会话,从而获知用户的身份。

但是,如果用户访问到的IAM服务器出现故障,负载均 衡设备将用户的会话通过故障转移到另外的服务器上时,另外的 服务器的内存中因为没有该用户的session记录,无法获知用户是谁,将会导 致用户需要再次登录的情况发生:

为避免这种情况发生,需要将 统一认证服务的session会话进 行同步即可得到解决,在这里 简单的列举一下常用的处理方案:

通过中 间件自身的会话复制(会话共享)技术,实现会话的复制;

通过第 三方的缓存服务器进行会话的共享,如Memcached、Redis等;

微服务部署架构

从架构上来看,以上讨 论都是基于传统的部署方案进行架构设计。当需要 对统一身份进行版本发布时,往往是动一发牵全身,每次发 布都需要需要发布的时间窗口,并提前 对用户进行通知。

这个问 题可通过最新的微服务架构得到缓解:


首先,通过对 统一身份认证的服务模块分拆为不同的微服务,包括:

SSO模块:提供统一认证服务

Self模块:提供用户自助服务

IdM模块:提供身份管理服务

Audit模块:提供安全审计服务

Admin Console模块:提供后台管理服务

同时,后端的身份认证服务,通过API网关对外发布,并在API网关上 实现身份认证服务相关API的权限管控,保证系统安全性。

返回列表

相关推荐

让我们了解您的需求

© 2018 Paraview Software. All rights reserved.

服务热线:400-6655-745
企业邮箱:para@
友情链接:        鐪熶汉妫嬬墝鍦ㄧ嚎娓告垙骞冲彴-瀹樼綉骞冲彴鎵嬫満app     鎺屽績妫嬬墝-棣栭〉