摘要：前言很久都沒(méi)有寫博客了，這次為大家簡(jiǎn)單介紹兩個(gè)在開發(fā)中經(jīng)常使用的概念單點(diǎn)登錄和消息隊(duì)列以及具體到中的一些實(shí)現(xiàn)方案。單點(diǎn)登錄的實(shí)質(zhì)就是安全上下文或憑證在多個(gè)應(yīng)用系統(tǒng)之間的傳遞或共享。

很久都沒(méi)有寫博客了，這次為大家簡(jiǎn)單介紹兩個(gè)在WEB開發(fā)中經(jīng)常使用的概念——單點(diǎn)登錄和消息隊(duì)列以及具體到J2EE中的一些實(shí)現(xiàn)方案。本文原創(chuàng)性的工作比較少，主要是一些總結(jié)概括和自己的理解。

所謂單點(diǎn)登錄就是在一個(gè)站點(diǎn)登錄之后可以授信給其他站點(diǎn)，這樣就可以做到一次登錄，到處操作。單點(diǎn)登錄的實(shí)質(zhì)就是安全上下文（Security Context）或憑證（Credential）在多個(gè)應(yīng)用系統(tǒng)之間的傳遞或共享。

大部分的網(wǎng)站采用Cookie作為登錄的一種簡(jiǎn)單實(shí)現(xiàn)方案，在同一個(gè)一級(jí)域名下面，這樣做并無(wú)問(wèn)題，不需要對(duì)各個(gè)子系統(tǒng)分別驗(yàn)證。但是Cookie無(wú)法跨域傳遞。將用戶的登錄、憑證取得等解耦處理多帶帶作為一個(gè)子系統(tǒng)是合理的選擇。

共享同一個(gè)身份認(rèn)證系統(tǒng)，也就是說(shuō)所有站點(diǎn)的身份驗(yàn)證操作在同一個(gè)系統(tǒng)下完成

每個(gè)子系統(tǒng)從共同的身份認(rèn)證系統(tǒng)中取得用戶憑證，包含用戶的身份、權(quán)限信息等

示意圖如下：

下面以采用Cookie的一種方案為例來(lái)解釋：

我們首先定義授信服務(wù)器A，受信服務(wù)器B，客戶C；當(dāng)前的業(yè)務(wù)是B需要驗(yàn)證C的身份。需要注意的是B和C都會(huì)保有session來(lái)記錄C的登錄狀態(tài)，均會(huì)向C 的Header中寫入對(duì)應(yīng)自己域名的Cookie以存儲(chǔ)憑證信息。Cookie中含有tokenId來(lái)標(biāo)示C，也就是說(shuō)對(duì)于A和B他們的Cookie中對(duì)應(yīng)于同一個(gè)C，其tokenId應(yīng)該一致。

C向B發(fā)起請(qǐng)求后，會(huì)有以下幾種情形：

B含有session，C含有Cookie，且session和Cookie中的token一致，那么不需要向A求助

C中對(duì)于B無(wú)Cookie或Cookie過(guò)期或session與Cookie不一致，將向A發(fā)起請(qǐng)求。之后根據(jù)A的情形，有以下情況：

A中session與C中Cookie的token一致，重新生成憑證信息返回給B，B重新寫入Cookie與session

A中Cookie過(guò)期或信息不一致，將重定向到登錄頁(yè)面

對(duì)于登錄情形，A將更新Cookie與session，然后C再向B發(fā)起請(qǐng)求，這時(shí)就會(huì)變成2中第一種情況，導(dǎo)致A和B的信息完成同步。

消息隊(duì)列本身是簡(jiǎn)單的，可以直接看做一個(gè)隊(duì)列，重點(diǎn)是如何定義存儲(chǔ)在隊(duì)列中的數(shù)據(jù)格式，以滿足我們對(duì)應(yīng)的操作需求。MQ常常應(yīng)用于那些并發(fā)量大而對(duì)于實(shí)時(shí)性要求不高的情況。舉個(gè)例子，比如一個(gè)用戶量較大的社交網(wǎng)站的評(píng)論發(fā)布，為什么這么說(shuō)呢？對(duì)于這個(gè)任務(wù)，隊(duì)列中只用存儲(chǔ)評(píng)論相關(guān)信息，對(duì)于從隊(duì)列中取的一方，只需要進(jìn)行插入操作，符合前面所說(shuō)的并發(fā)量大且可以有延時(shí)，同時(shí)并不難實(shí)現(xiàn)。

消息隊(duì)列在WEB開發(fā)中主要有兩種模式：

生產(chǎn)者/消費(fèi)者模式：對(duì)于一則消息，只有一個(gè)消費(fèi)者線程會(huì)去處理它，適用于我們上面所說(shuō)的評(píng)論系統(tǒng)

發(fā)布者/訂閱者模式：對(duì)于所有訂閱者，它可以讀取所有在它加入之后發(fā)布的消息

在J2EE中加入消息隊(duì)列，我個(gè)人認(rèn)為應(yīng)該是這樣的：對(duì)于特定的HTTP請(qǐng)求，調(diào)用生產(chǎn)者/發(fā)布者的接口，入隊(duì)必要消息，這個(gè)并不困難。大有蹊蹺的我覺(jué)得在于處理消息的一方，可以實(shí)現(xiàn)listener將其交由容器管理，也可以自己開辟池來(lái)調(diào)度。舉例來(lái)說(shuō)明，對(duì)于前者Spring-redis實(shí)現(xiàn)的pub/sub模式隊(duì)列就是直接在配置文件中設(shè)定RedisListener的實(shí)現(xiàn)類，對(duì)于后者，你可以直接獨(dú)立出來(lái)寫離線腳本來(lái)監(jiān)聽(tīng)隊(duì)列。

目前業(yè)界有比較成熟的MQ解決產(chǎn)品，如下：

RabbitMQ

ActiveMQ

kafka

Redis

在Pom.xml中加入以下依賴

    
        org.springframework.data
        spring-data-redis
        1.4.2.RELEASE
    
    
        org.apache.commons
        commons-pool2
        2.3
    
    
        redis.clients
        jedis
        2.6.2
     

在ApplicationContext.xml的頭部插入schema

xmlns:redis="http://www.springframework.org/schema/redis"

在ApplicationContext中加入Redis的配置

上文在定義Listener的時(shí)候采用了注解對(duì)象作為實(shí)現(xiàn)類，也可以手動(dòng)在配置文件中再寫一個(gè)bean，如下

最后我們給出一個(gè)接收方的實(shí)現(xiàn)

import java.io.Serializable;

import org.springframework.stereotype.Component;

@Component(value="messageDelegateListener")
public class ListenMessage {
    public void handleMessage(Serializable message){
        System.out.println(message);
    }
}