论文部分内容阅读
中国电子检验检疫主干系统（以下简称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产品为了实现自身更多的独有特性，牺牲了不少兼容性，并对配置提出了更高的要求，值得大家在项目管理工作中更加注意。
（作者单位：江西出入境检验检疫局）
通过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的格式为：
三、解决方案
明确问题故障节点后，笔者和技术人员就开始着手排除故障，主要是针对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产品为了实现自身更多的独有特性，牺牲了不少兼容性，并对配置提出了更高的要求，值得大家在项目管理工作中更加注意。
（作者单位：江西出入境检验检疫局）