一种预付费卡系统的总体设计架构

1、一种预付费卡系统的总体设计架构    摘要：该文提出了一种预付费卡系统的总体设计架构，包括总体逻辑模型、预付费卡的生命周期、子系统逻辑结构、数据同步、系统设计的高可用性和高可靠性考虑。 关键词：预付费卡；逻辑模型；可用性；可靠性 中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）05-1054-02 1 系统总体逻辑模型 上图中，基础设施层构成了交换系统的 IT 基础架构，包括网络、主机和操作系统，操作系统采用开放的 Linux 系统。 数据处理层由 Oracle 企业级数据库为应用层提供数据处理服务。 为获得最有效的负载均

2、衡能力、更好的系统可用性和可扩展性、成熟高效的进程间通信机制，并提供更有效的运行管理和监控手段，在应用层和基础设施层引入了中间件层。对于典型的 OLTP 处理，如支付子系统、代授权子系统采用公司的自有中间件支撑，考虑到管理的一致性， 将文件收发子系统、安全子系统的联机处理部分、批处理子系统以及差错处理中的批量差错通知发送等需要高性能的处理也架构在此之上。所有通过网上进行操作的业务均架构在 J2EE 上。 由于架构于 J2EE 平台的业务处理基于同样的技术架构，为方便叙述，在下面的章节中将其统称 为管理子系统和服务子系统，包含公共组件包、差错处理业务、管理业务、查询报表业务、风险信息共享业务和业

3、务门户。 2 预付费卡的生命周期 3 子系统逻辑结构 子系统分为表示层、业务处理层和服务集成层。 表示层以网页的形式提供各种业务数据的展现，同时为各业务包的业务处理提供网上渠道。 业务处理层完成主要的业务处理逻辑，是表示层的后台服务端。包括差错处理业务包、管 理业务包、风险信息共享业务包和查询报表等业务包的核心业务处理逻辑都集中在业务处理层。 服务集成层完成和外部系统/资源的调用和访问服务，包括和其他子系统的接口、调用安全 子系统的安全服务、存取表中的用户权限信息以及对数据仓库、历史数据库的访问。 4 数据同步 在本系统中，为提高处理性能，各子系统大量使用了配置参数表内存管理的技术。数据同 步

4、用于当配置参数表数据发生改变时，同步内存与数据库中的数据。 针对需同步的数据量的大小，采用二种方式实现对不同数据的同步。对于数据量大但变化不频繁的数据，如卡路由表，采用“事件引发数据同步模式”；对于数据量小但变化频繁的数据，如联网机构状态表，采用“事件实现数据同步模式”。为确保同步成功，在数据同步机制中，设 计了事件的应答机制，即当接收到事件的子系统完成数据同步处理后，须向发送事件的子系统 返回应答信息。 5 事件引发数据同步模式 在事件引发数据同步模式中，这种方式使得目标子系统只需访问其“本机数据库”即可透 明地获得对远程数据库的访问，且性能不会有明显下降，由于管理数据通常较小，且数据更新

5、对性能的敏感度较低，较小的性能下降幅度是可以容忍的。下图描述了事件引发数据同步的执 行过程。 事件引发数据同步模式的处理流程如下： 1）由子系统管理业务包修改安全与管理数据库中的数据； 2）管理业务包以事件方式通过中间件通知目标子系统； 3）若被同步的数据存放在内存，则目标子系统读目标数据库数据更新内存。 6 事件实现数据同步模式 <d：2013年学术和海外飞翔导入图片目录889一种预付费卡系统的总体设计架构_张晓宇2.3-EEimage3.png> 图3 事件实现数据同步模式 用事件方式实现数据同步可解决数据量小的数据同步问题。这种同步方式为每种通知事件 定义了合法的接口，一旦源

6、数据发生变化，可以利用中间件调用直接将变化后的数据传到其他 子系统中，使目标子系统直接更新内存。 7 系统设计的高可用性和高可靠性考虑 支付子系统也必须是一个高可用的系统，需要达到99.99%的高可用性指标和7×24 小时的 不间断运行。 系统的高可用性必须在可靠的硬件设备和通过严格测试的软件模块的基础上，采用系统设 计上的高可用性机制。在尽量保证各模块可靠的基础之上，通过一个健壮的体系结构来确保系 统能够在硬件和软件出错的情况下依然平稳地运行。 在支付子系统的设计中对系统所有的服务都进行了备份设计，确保系统不会有任何关键的单点故障（critical single point fai

7、lure）；任何一个进程故障都不会引起系统的瘫痪， 同时也允许系统对部分服务做升级和维护而不影响系统继续提供交易处理服务。 错误的隔离、报警、容错和恢复在实现系统的高可用性方面是最基本的手段，在支付子系 统中通过下面的设计体现： 错误隔离：在支付子系统中所有的服务都是分隔独立的，而且绝大多数的 Tuxedo 服务 调用都是异步执行的，从而避免某个模块的出错导致的整个系统的瘫痪。另外还提供 一种安全机制保证每个服务的执行时间不会过长。任何一个服务的出错，最多导致一 个报文数据的丢失，这种出错由超时处理机制来发现并进行必要的冲正处理。 错误包容：即容错，是实现中心交换系统高可用性最为关键的部分。由

8、于系统设计中 所有的服务都是备份运行的，没有关键性的单点故障，所以在某个服务出现故障的时 候，系统的其它部分仍然能够正确的处理交易。在多数情况下，只有当前处理的请求 报文会丢失，接下来的请求报文将由系统通过路由调度，转发到其他正常的服务上继 续处理。这个丢失的报文将会由申请方重新发送，或者由冲正处理服务根据交易的处 理状态向发卡方发送冲正请求。 错误恢复：在支付子系统中应用进程的错误恢复大多是通过配置（RESTART=Y）自动完 成的。当应用进程瘫痪或者由于服务超时而被终止时，则应用进程终止前正在处理的 交易报文将会丢失。重新启动的服务进程将连接同一条消息队列，继续处理消息队列 中其余的交易请

9、求。Tuxedo运行支持系统（runtime support）提供瘫痪服务和正常 服务的 failover 及恢复正常服务的 failback。 作为一个高可用性的应用平台，交易中间件提供了对上述设计的有力支持。在支付子系统 的设计中，充分利用了下面的 Tuxedo 功能特征： 模块化和面向服务的体系结构：模块化有利于将系统复杂度分解而易于控制。支付子 系统中的服务相对独立，各服务可以分别升级而相互影响最小。异步的调用方式也使 得服务之间的错误容易分离。 平行备份设计：支付子系统的主要功能模块都以服务的方式互为备份并且可以在本机 及多机上复制（replication），由交易中间件实现负载均衡

10、。同时将入网机构的多条 连接分配到尽可能多的机器和不同的通信网关服务进程上；保证部分通信网关服务的 失效不会影响整个系统的运行。 多机互连的应用配置：支付子系统的设计从一开始就基于多机互为备份的要求，任何 一台机器的故障都不会引起中心的瘫痪。在系统运行正常时，多机都参加处理交易， 并且通过交易中间件来支持多台主机之间的负载均衡。 多个进程单条队列（MSSQ）的配置：在交易中间件中多个服务进程可以共享一条消息 队列而实现另一个层面上的负载均衡。 重新启动服务进程：通过配置成自动重起任何死亡的（crashed）进程，在 MSSQL的配 置下，重起的服务进程将重新连到同样的消息队列上。如果这条请求队

11、列上的服务不 能重启动的时候，其中的服务将被挂起或者关闭（unadvertised）；系统将尝试把队列中的交易请求转发给其他提供相同服务的进程；如果尝试失败，系统将会向请求方返回出错信息。 服务超时的监控：通过设置每个服务的执行时间，一旦一个服务调用的运行时间（具体时间可做参数设置）过长，Tuxedo将强制性地终止其服务进程并重起该服务进程。 这个重起的服务进程也会重新连到先前的消息队列上。从而有效地防止服务处理过程 中的死循环或者其他原因导致的服务自身被挂起。 动态的开放/关闭服务入口：通过运行支持监控各服务进程的消息队列。当服务进程的 请求队列过长（长度可配置），系统将暂时关闭自己的服务入

12、口。 这样不仅达到了服 务进程的流量控制目的，而且能够防止因为某个组件的失败导致系统阻塞的蔓延。 其他的流量控制手段：在支付子系统的设计中将在每 n（可设置参数）个异步调用后 使用一个同步调用，减少执行路径上的局部阻塞。 应用配置的灵活性：基于交易中间件的设计使得支付子系统内的各服务可灵活地配置 在同一机器或不同的机器上。并提供动态改变服务配置的功能，从而允许系统管理员 在系统运行期间根据需要动态地重新配置支付子系统的服务。 数据库服务器的可用性是支付子系统的设计上也需考虑的一个问题。一般说来，应用不能对数据库服务器的状况做出有效的判断。对像磁盘实效这样的错误，也只能由数据库服务器切换磁盘，或

13、将数据库服务器failover到备份的服务器上。应用程序一般可以在数据库操作失败时重新连接到数据库服务器，但无法在闲置时自动更新到数据库的连接，需要外部的监控程序判定数据库服务器的状态，由其发布数据库服务器需要重新连接的事件，由应用程序重新连接数 据库或重起Tuxedo服务进程的方式做到对数据库服务器的切换。 支付子系统的设计充分考虑了可能发生的各种系统异常，诸如服务失败、数据破坏、网络失败、机器失败以及整个处理中心失败，并通过相应处理手段保障整个系统可以继续提供有效的服务。 参考文献： 1 帅青红.电子支付结算系统M.成都：西南财经大学出版社，2006：102-107，305-310. 2 Jame