WXS環境下的e—CIQ主干系統跨集群SESSION共享故障排查實例

魏文　鐘毅　馬欣欣　謝成宸

中國電子檢驗檢疫主干系統（以下簡稱e-CIQ主干系統）是基于全國大集中要求設計的全新核心業務系統，它依托在北京建設的亦莊、東壩雙活數據中心，實現了全國大集中條件下應用可用性99.99%的設計要求。而用戶Session會話的跨數據中心集群的安全、快速、可靠共享管理，是確保雙活順利實現的關鍵。為此，e-CIQ主干系統運用跨WAS集群的Session，選用了業界領先的IBM WAS SESSION高速緩存服務中心（WebSphere eXtreme Scale，WXS）方案來實現應用集群的SESSION共享管理工作。

通過IBM、官方文檔及售前工程師的介紹，WXS高速緩存服務中心是將原有多節點的Session會話共享管理工作通過專用的獨立HIS/WAS/WXS服務器（標準最小部署至少18個節點）實現跨集群Session會話內容共享管理，對Session的管理依然遵循JavaEE技術標準，包括客戶端與服務器端Session的保存機制，均采用JSessionID來保持Session的內容，這也是JavaEE標準的實現方式。

在e-CIQ主干系統北京雙活數據中心機房測試環境中，硬件環境集成商已完成WAS集群和Session高速緩存服務中心搭建，同時在雙活中心測試環境也部署了e-CIQ主干系統應用。但是經過第三方測試，e-CIQ項目應用集群Session信息無法共享，在客戶端連接時會出現Session丟失的情況，客戶端會提示“服務器已經重啟，您的登錄信息已經失效，請重新登錄”并報錯。如圖1所示：

一、背景情況

e-CIQ主干系統雙活中心WAS集群的部署結構適合于應用業務雙活類型，具備軟件業務應用層面實現業務雙活、多路徑訪問以及負載均衡，單中心基于VMware vSphere HA和應用集群（中間件集群），雙活數據中心之間采用應用軟件1∶1部署，雙活中心之間采用Session高速緩存服務中心（WXS）集中管理緩存，保證雙活數據中心內的單個中心全站點在宕機極端情況下，作為雙活數據中心整體仍然能夠對外持續提供業務服務，如圖2所示：

基于IBM官方提供的標準測試WAR包在WAS環境下的Session高速緩存服務中心下，可以實現集群Session集中共享。但是經第三方測試反饋，e-CIQ主干系統應用集群Session共享存在問題，出現Session頻繁丟失的情況。

筆者初步分析問題后，發現由e-CIQ主干系統創建的Session會話信息并未成功存放到WAS集群下的WXS Session高速緩存服務器中，導致e-CIQ主干系統Session會話信息無法共享。筆者經過進一步分析，了解到e-CIQ主干系統基于中國電子檢驗檢疫統一開發平臺（以下簡稱UIP平臺）進行開發的，軟件開發商遵循標準的開發平臺規范，對業務邏輯進行編碼實現，底層資源、包括Session的管理，均在UIP平臺中實現，業務應用代碼層面并沒有對Session進行處理。

二、故障排查

根據IBM官方技術支持反饋，WXS作為IBM提供的分布式高速緩存平臺，用于存儲服務器端的會話信息，由容器服務器和目錄服務器組成，目錄服務器主要用于索引，容器服務器才是真正存放會話信息的服務器。多臺服務器把會話信息存放在容器服務器內，用戶讀取信息時，需要從目錄服務器查詢會話信息的容器服務器，查詢完成后再從相應的容器服務器獲取會話信息，就能實現會話信息的共享了。也就是說，為了實現會話信息共享，索引和內容兩個關鍵點缺一不可。

為此，在北京雙活數據中心測試WAS集群中，筆者和開發人員首先在服務端環境中開發了一個JSP頁面，進行抓包分析測試。在使用WXS抓包套件條件下，通過對HTTP請求抓包，發現兩次COOKIE項值與未使用WXS的情況存在差異。具體表現為：使用WXS后JSessionID經過加工處理，增加了標記段，同時多傳回標記為IBMID的COOKIE值。抓包測試結果如圖3、圖4所示。

筆者經排查發現，IBM WAS 在實現Session共享時，會對JSessionID 進行相關處理，包括修改JSessionID的值。JSessionID本身是用來存放SESSION ID的，IBM WAS 會在Session ID 前增加4位字符，在Session ID 結尾處增加一個以“：”（英文冒號）開始、以“；”（英文分號）結束的字符串，如圖5所示：

此外，富客戶端每次發起網絡請求時還需包含IBMID參數，IBMID參數的值是以SESSIONID開頭，然后在結尾處增加一個以“：”（ 英文冒號）開頭的字符串。每次請求時，必須包含這兩個參數，并且要嚴格遵守上述格式，否則就會出現Session丟失故障提示，如圖6所示：

至此，筆者猜測問題在于IBM WAS在實現Session共享時，并未遵循JavaEE Web技術標準對SessionID 進行相關修改。之后，相關的分析也佐證了筆者的猜測。

從操作性、安全性及效率性來考量，e-CIQ主干系統客戶端使用了Java AWT（Abstract Window ToolKit）的Swing封裝套件，基于UIP-RCP（Rich Client Platform）開發的富客戶端。作為對比，IBM官方標準測試WAR包是基于B/S模式實現的Web頁面跨集群Session會話共享管理。瀏覽器和富客戶端對Session的管理機制存在差異，主流瀏覽器回傳的是整個Session字符串，而富客戶端按照Java標準僅回傳JSessionID值。這就解釋了IBM官方測試WAR包緩存共享測試通過的原因。

進一步深入查詢相關技術文檔后，筆者發現IBMID由WXS負責跟蹤，其與JSessionID的格式略有不同。JSessionID的格式為：：，IBM WXS IBMID的格式為：：。

三、解決方案

明確問題故障節點后，筆者和技術人員就開始著手排除故障，主要是針對UIP v4.4平臺中rcp-core.jar進行修改。修改工作主要包括三處，分別是：

第一，對ClientSession類進行修改，增加IBMID成員變量，提供getter和setter方法，用于將IBMID存儲以及搜索WXS中的Session會話信息。如圖7所示：

第二，修改HttpClientProxy類，對IBMID進行判斷，針對存儲在Cookie中的IBMID，在每次發送request時候，同時將IBMID也一起發送。如圖8所示：

第三，修改HttpStreamProxy類，生成符合WXS環境下共享緩存所需的IBM JSessionID和IBMID格式SessionID值串。如圖9所示：

四、工作小結

IBM WAS系列產品作為行業龍頭，憑借操作系統（AIX）+中間件（WAS）+數據庫（DB2）的頗具殺傷力的組合，其中間件產品標準基本上與行業標準、技術標準畫等號。

令人信任的產品不能盲從于權威，尤其是在細節方面。WAS產品為了實現自身更多的獨有特性，犧牲了不少兼容性，并對配置提出了更高的要求，值得大家在項目管理工作中更加注意。

（作者單位：江西出入境檢驗檢疫局）