為什么統(tǒng)一身份認(rèn)證系統(tǒng)需要考慮高可用?

通過(guò)建設(shè)一套統(tǒng)一認(rèn)證的系統(tǒng)，將用戶的登錄入口進(jìn)行統(tǒng)一。用戶只需要知道一個(gè)地址，一套用戶名口令，進(jìn)行一次認(rèn)證，即可實(shí)現(xiàn)所有應(yīng)用訪問(wèn)，可大大的提升用戶的使用體驗(yàn)。

那么我們回過(guò)頭來(lái)想一想

既然用戶的訪問(wèn)入口進(jìn)行了統(tǒng)一，那么從架構(gòu)上來(lái)看，要是這個(gè)統(tǒng)一的入口白旗高高掛起，歇菜了，那豈不是所有的用戶都訪問(wèn)不了？ 

統(tǒng)一身份認(rèn)證系統(tǒng)高可用的實(shí)現(xiàn)方式

基本部署架構(gòu)

我們先看一下統(tǒng)一身份認(rèn)證系統(tǒng)作為一個(gè)典型的B/S應(yīng)用系統(tǒng)，所需要的組件：

1、中間件：把統(tǒng)一身份認(rèn)證的應(yīng)用運(yùn)行起來(lái)

2、數(shù)據(jù)庫(kù)：進(jìn)行數(shù)據(jù)的存儲(chǔ)

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

而的部署、應(yīng)用程序、數(shù)據(jù)庫(kù)都部署在一臺(tái)服務(wù)器上，即可運(yùn)行起來(lái)：

應(yīng)用、數(shù)據(jù)分離架構(gòu)

隨著業(yè)務(wù)的擴(kuò)展，一臺(tái)服務(wù)器已經(jīng)不能滿足性能需求，同時(shí)，考慮數(shù)據(jù)的安全性，所以將應(yīng)用程序、數(shù)據(jù)庫(kù)各自部署在獨(dú)立的服務(wù)器上，顯得很有必要。

并且根據(jù)服務(wù)器的用途配置不同的硬件，可以達(dá)到較好的性能效果。

 應(yīng)用服務(wù)集群部署架構(gòu)

統(tǒng)一身份認(rèn)證系統(tǒng)作為用戶的統(tǒng)一且的認(rèn)證入口，同時(shí)還會(huì)承擔(dān)所有用戶的大量請(qǐng)求。

為解決應(yīng)用服務(wù)器的單點(diǎn)故障問(wèn)題，我們可以通過(guò)增加應(yīng)用服務(wù)器，進(jìn)行集群部署。

同時(shí)，多臺(tái)服務(wù)器同時(shí)提供服務(wù)，可以降低單臺(tái)應(yīng)用服務(wù)器所承受的服務(wù)壓力，提高系統(tǒng)的服務(wù)性能，提升用戶的訪問(wèn)速度。

應(yīng)用服務(wù)器前面部署負(fù)載均衡服務(wù)器調(diào)度用戶請(qǐng)求，根據(jù)分發(fā)策略將請(qǐng)求分發(fā)到多個(gè)應(yīng)用服務(wù)器節(jié)點(diǎn)。

當(dāng)系統(tǒng)的性能達(dá)到瓶頸時(shí)，也可以采用橫向擴(kuò)展應(yīng)用服務(wù)器的方式進(jìn)行性能擴(kuò)容。

常用的負(fù)載均衡的選擇上，通常有硬件及軟件兩種方案：

硬件方案：價(jià)格比較昂貴，通常有F5、Redware等硬件產(chǎn)品；

軟件方案：通常使用LVS（Linux Virtual Server）、HAProxy、Nginx等方式，其中LVS工作于四層網(wǎng)絡(luò)，HAProxy可工作于四層及七層網(wǎng)絡(luò)，Nginx工作于七層網(wǎng)絡(luò)，版的Nginx（1.9版本后）加入了四層網(wǎng)絡(luò)的支持；

另外，最近Nginx被F5重金收購(gòu)，在IT界也算鬧了個(gè)大新聞。

負(fù)載HA部署架構(gòu)

從以上應(yīng)用服務(wù)集群部署架構(gòu)上來(lái)看，雖然統(tǒng)一認(rèn)證應(yīng)用服務(wù)已實(shí)現(xiàn)了集群部署，多臺(tái)服務(wù)器提供服務(wù)避免了單點(diǎn)故障的問(wèn)題。但是負(fù)載均衡服務(wù)同樣面臨著單點(diǎn)故障的問(wèn)題，如負(fù)載均衡服務(wù)出現(xiàn)問(wèn)題，所有用戶依然無(wú)法正常訪問(wèn)。

所以，對(duì)負(fù)載均衡設(shè)備進(jìn)行HA高可用部署，同樣顯得很有必要：

通過(guò)將負(fù)載均衡服務(wù)進(jìn)行HA高可用部署，當(dāng)當(dāng)前提供服務(wù)的負(fù)載均衡服務(wù)出現(xiàn)故障時(shí)，可自動(dòng)將服務(wù)切換到熱備的均衡負(fù)載設(shè)備上，保障系統(tǒng)不間斷的提供服務(wù)。

在這里，所涉及到的HA高可用部署方案實(shí)現(xiàn)主備服務(wù)間的自動(dòng)切換，根據(jù)負(fù)載設(shè)備的硬件、軟件方案的不同，同時(shí)也會(huì)有不同的HA高可用部署方案：

負(fù)載設(shè)備采用硬件方案（F5、Redware等）時(shí)，可使用硬件廠商自身提供的HA方案；

 負(fù)載設(shè)備采用軟件方案（LVS、HAproxy、Nginx等）時(shí)，通?？晒┻x擇的方案有Heartbeat、Keepalived等選擇。

數(shù)據(jù)服務(wù)集群部署架構(gòu)

最后來(lái)到部署架構(gòu)中最關(guān)鍵的一環(huán)，我們的數(shù)據(jù)庫(kù)依然是單點(diǎn)提供服務(wù)，這也是必須需要解決的一環(huán)：

對(duì)數(shù)據(jù)庫(kù)服務(wù)進(jìn)行集群部署，即可解決數(shù)據(jù)服務(wù)單點(diǎn)故障的問(wèn)題。

在數(shù)據(jù)庫(kù)的集群部署上，根據(jù)不同的數(shù)據(jù)庫(kù)產(chǎn)品，同樣有著不同的集群技術(shù)方案，以下列舉以下主流的幾種數(shù)據(jù)庫(kù)的集群方案：

 Oracle，采用共享存儲(chǔ)實(shí)現(xiàn)RAC集群方案，數(shù)據(jù)存放在一個(gè)共享存儲(chǔ)中，多個(gè)數(shù)據(jù)節(jié)點(diǎn)同時(shí)操作數(shù)據(jù)；

 MySQL，可采用主主復(fù)制、主備復(fù)制模式，數(shù)據(jù)放在各自服務(wù)器上，通過(guò)配置的主主復(fù)制、主備復(fù)制模式實(shí)現(xiàn)數(shù)據(jù)文件的同步；

DB2，可提供HADR、pureScale等部署技術(shù)，其中HADR技術(shù)為雙活節(jié)點(diǎn)的部署模式，通過(guò)數(shù)據(jù)庫(kù)日志復(fù)制的方式實(shí)現(xiàn)節(jié)點(diǎn)間的數(shù)據(jù)同步，pureScale技術(shù)則為多服務(wù)節(jié)點(diǎn)+共享存儲(chǔ)的部署模式；

故障會(huì)話保持部署架構(gòu)

通過(guò)將統(tǒng)一認(rèn)證服務(wù)進(jìn)行集群部署、均衡負(fù)載設(shè)備進(jìn)行HA高可用部署、數(shù)據(jù)庫(kù)采用集群架構(gòu)部署后，已經(jīng)可以滿足絕大部分用戶使用的業(yè)務(wù)場(chǎng)景的不間斷服務(wù)了。

為什么說(shuō)是滿足了絕大部分用戶呢？

在這里需要重溫一下http web會(huì)話的知識(shí)，一個(gè)完整的web會(huì)話，由瀏覽器+web服務(wù)組成，以java應(yīng)用部署在tomcat上為例：

從這里可以看出，web會(huì)話其實(shí)是基于cookie-session這樣的機(jī)制來(lái)確認(rèn)用戶是誰(shuí)，否則一萬(wàn)個(gè)用戶同時(shí)訪問(wèn)了web應(yīng)用，服務(wù)端無(wú)法定位哪個(gè)瀏覽器過(guò)來(lái)的請(qǐng)求是哪個(gè)用戶的。

那么，統(tǒng)一認(rèn)證的服務(wù)運(yùn)行在中間件服務(wù)器上，也就是說(shuō)最終還是依賴于cookie-session這樣的會(huì)話機(jī)制。

再回到我們的架構(gòu)上，雖然統(tǒng)一認(rèn)證的服務(wù)（IAM）采用了集群的部署架構(gòu)，同時(shí)也可以通過(guò)前端的負(fù)載均衡的設(shè)備配置會(huì)話保持的訪問(wèn)策略，使每個(gè)用戶的請(qǐng)求通過(guò)均衡負(fù)載的服務(wù)后，固定的分發(fā)到一臺(tái)服務(wù)器上，從而保障用戶最終訪問(wèn)到的統(tǒng)一認(rèn)證的服務(wù)器上存在該用戶的session會(huì)話，從而獲知用戶的身份。

但是，如果用戶訪問(wèn)到的IAM服務(wù)器出現(xiàn)故障，負(fù)載均衡設(shè)備將用戶的會(huì)話通過(guò)故障轉(zhuǎn)移到另外的服務(wù)器上時(shí)，另外的服務(wù)器的內(nèi)存中因?yàn)闆](méi)有該用戶的session記錄，無(wú)法獲知用戶是誰(shuí)，將會(huì)導(dǎo)致用戶需要再次登錄的情況發(fā)生：

為避免這種情況發(fā)生，需要將統(tǒng)一認(rèn)證服務(wù)的session會(huì)話進(jìn)行同步即可得到解決，在這里簡(jiǎn)單的列舉一下常用的處理方案：

通過(guò)中間件自身的會(huì)話復(fù)制（會(huì)話共享）技術(shù)，實(shí)現(xiàn)會(huì)話的復(fù)制；

通過(guò)第三方的緩存服務(wù)器進(jìn)行會(huì)話的共享，如Memcached、Redis等；

微服務(wù)部署架構(gòu)

從架構(gòu)上來(lái)看，以上討論都是基于傳統(tǒng)的部署方案進(jìn)行架構(gòu)設(shè)計(jì)。當(dāng)需要對(duì)統(tǒng)一身份進(jìn)行版本發(fā)布時(shí)，往往是動(dòng)一發(fā)牽全身，每次發(fā)布都需要需要發(fā)布的時(shí)間窗口，并提前對(duì)用戶進(jìn)行通知。

這個(gè)問(wèn)題可通過(guò)的微服務(wù)架構(gòu)得到緩解：

首先，通過(guò)對(duì)統(tǒng)一身份認(rèn)證的服務(wù)模塊分拆為不同的微服務(wù)，包括：

SSO模塊：提供統(tǒng)一認(rèn)證服務(wù)

Self模塊：提供用戶自助服務(wù)

IdM模塊：提供身份管理服務(wù)

Audit模塊：提供安全審計(jì)服務(wù)

Admin Console模塊：提供后臺(tái)管理服務(wù)

同時(shí)，后端的身份認(rèn)證服務(wù)，通過(guò)API網(wǎng)關(guān)對(duì)外發(fā)布，并在API網(wǎng)關(guān)上實(shí)現(xiàn)身份認(rèn)證服務(wù)相關(guān)API的權(quán)限管控，保證系統(tǒng)安全性。