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

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

那么我们回过头来想一想

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

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

基本部署架构

我们先看一下统一身份认证系统作为一个典型的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的权限管控，保证系统安全性。