CICS 交易服务器 (Customer Information Control System Transaction Server, 下文简称 CICS TS) 是 IBM 在 z/OS 平台上开发的的联机事务处理软件。CICS 交易网关 (CICS Transaction Gateway，下文简称 CICS TG) 是 IBM 为客户端应用提供的专门连接 CICS TS 的接入方式。这种接入方式能够支持包括 z/OS 和开发环境的多种平台，具有高效、安全、高可用和可扩展等特性。
高可用性是现代企业信息系统很重要的特性，具有单点故障容错能力能使系统在故障发生时迅速恢复，保证了业务系统的连续性和可靠性，从而降低损失。CICS TG 具有高可用性，因此“主 - 备”模式的配置能够使单一 CICS TG 的故障不会影响系统的正常运行。CICS TG 的高可用性的实现利用了 z/OS 平台自身的功能和组件，比如 TCP/IP，SysPlex 分发器和工作负载管理器等。CICS TG 的高可用组并不一定需要支持 XA，但支持 XA，可以使 CICS 交易网关参与到全局事务中，并且支持两阶段提交事务。
本文主要介绍了 CICS TG 的高可用性设计，并通过实例的方式，详细地向您展示了如何一步步配置 CICS TG 高可用组。
CICS 交易网关的概要介绍
CICS 交易网关
CICS TS 是 IBM 开发的联机事务处理应用服务器。CICS TS 主要运行在 z/OS 上，为联机交易提供一个有效，安全，事务性和多用户的运行环境。
CICS TG 是 IBM 为客户端应用在运行环境中提供的连接 CICS TS 的连接器。这种接入方式能够支持包括 z/OS 和开放环境的多种平台，具有高效、安全、高可用和可扩展等特性。
CICS TG 作为 CICS TS 的主要入站连接器，能支持标准的 TCP/IP 网络协议，能访问统计和监控信息，能用于在 JEE 应用服务器中两阶段提交 XA 事务。通过 CICS TG 的应用编程接口（API）能访问 CICS COMMAREA 程序，CICS 通道 / 容器 (channel/container) 程序，以及 3270 程序。
CICS TG 能够通过 EXCI (External CICS Interface) 和 IPIC（IP Interconnectivity）两种方式接入 CICS TS。EXCI 协议只支持访问 CICS COMMAREA 程序，只支持同一 LPAR 上的通信。IPIC 协议支持访问 COMMAREA 和通道 / 容器程序，能够跨 LPAR 通信。IPIC 协议是从 CICS TS v3.2 开始支持。
CICS 交易网关的高可用性设计
现代企业信息系统是由许多硬件和软件组建而成，每一组件都具有特殊的功能，对系统的日常运作起着重要作用。如果任一硬件或软件系统失灵，轻则导致系统运行慢，重则导致整个系统崩溃。具有高可用性的系统，能够从庞大的系统中移除单点失灵，能够使其它系统有效地接管失灵系统的工作负荷，从而有效地减少 宕机时间，增强性能，提高用户体验。在非高可用环境中，如果系统需要维护，整个系统都必须关闭，维护结束后，再重启。而在高可用环境中，需要维护的系统可以脱机维护，不影响整个系统的正常运行。
高可用性是 CICS TG 的非常重要的功能。当系统只有单个 CICS TG 与多个 CICS TS 连接时，当这个 CICS TG 不可用时，整个系统就将变得不可用。具有高可用性的系统解决方案，就能避免这种情况的发生。在同一个逻辑分区 (LPAR) 上运行多个 CICS TG 的实例，这些 CICS TG 组成一个高可用组与所有 CICS TS 通信，单一点的失灵将不会导致整个解决方案的失灵。
具有高可用性的 CICS TG 扩展性更好。由于 CICS TG 高可用组对外提供统一的接入地址和端口，增加 CICS TG 的数量并不会影响前端应用，从而使系统易于扩容。同时，由于同一高可用组中的所有 CICS TG 共享同一份配置文件，新增加 CICS TG 实例的配置变得简单，从而更加利于系统扩容。
高可用性的实现方式
z/OS 上的 TCP/IP 配置功能，能管理客户端应用与 CICS TG 之间的连接分配。因此，使用端口共享 (port sharing) 的方式，就能够简单地实现高可用性，从而使客户端应用通过任意 CICS TG 连接 CICS TS，而无需知道 CICS TG 或者 CICS TS 具体实例的信息。当然客户端应用也无法选择连接某个特定的 CICS TG 的实例。所有 CICS TG 的实例监听同一个端口，来自客户端应用都通过该端口发起连接请求。当客户端应用与某个 CICS TG 的实例建立连接后，接下来的所有请求都使用相同的连接，直至出现问题导致连接丢失。网络故障，CICS TG 的意外关闭等都可能导致连接丢失。连接丢失后，客户端应用发起新的请求，会与 CICS TG 高可用组里的任一 CICS TG 的实例建立新的连接。端口共享只能在单一 LPAR 上实现 TCP/IP 负载均衡。
Sysplex 分发器 (Sysplex Distributor，详见参考文献 4) 是 IBM 推荐的在一个 z/OS Sysplex 上的连接负载均衡的解决方案。与共享端口方式不同的是，通过这种方式，能实现多个 LPAR 上的 TCP/IP 负载均衡，并且在重建连接时会使用连接丢失前的相同连接。
另一种方式是使用 z/OS 上的工作负载管理器（Workload Manager，简称 WLM）提供更智能的路由算法来分配请求。算法通常考虑两方面因素，一是不同 CICS TG 的的响应时间。也就是说，处理任务最快的 CICS TG 的实例会收到最多的连接请求。另一因素是健康指数。网关守护程序会向 WLM 报告健康指数，也就是一定时间内（默认值是 60 秒）成功处理请求的比例。不能百分之百处理请求的 CICS TG 将会比能够百分之百处理请求的 CICS TG 收到更少的连接请求。如果 CICS TG 实例的健康指数是 0，即所有的请求都未被处理，WLM 将不会向该实例发送新的连接请求。干预程序会自动处理导致健康指数降至 0 的 CICS TS 的连接问题。处理完毕后，该 CICS TG 实例的健康指数会被重置为 100%。CICS TG 实例的当前健康指数能够从 GD_CHEALTH 的统计信息中查询到。
如果要最大限度地考虑冗余，就需要基于系统里的实时数据来决定路由。与 WLM 的路由算法相比，该方式需要增加另一组 CICS 域（组成 AOR）来处理交易。网关守护程序与 TOR（Terminal Owning Regions）相连，TOR 发送请求给 AOR(Application Owning Regions) 处理。TOR 根据 CPSM(CICSPlex System Manager) 上的信息来决定路由，路由基于哪个 CICS 域最少被利用，或者使用最少的 CPU 时间。采用这种拓扑结构的系统，一个交易的所有部分都必须在同一个 AOR 上面运行，否则可能发生死锁。
