技术架构（二）
从最早的“主机－终端”结构，到后来的UNIX系统集群分布式计算，再到大集中时代的“大型机”以及部分中小行的中、小型机集群，直至现代的主机下移“分布式X86服务器”。
大型机
大型机(Mainframe)这个词最早是指装在带框的铁盒子中的大型计算机系统,发展至今己有50多年,其间有过辉煌,也经历低谷。现代商用大型机更多地被形容成操作、应用和系统的集合,而从工作性质和运用方向上来定义:大型机是指在商业活动中,用以管理数据、维护交易服务并能够提供更高级别的安全性和实用性的机器
大型机作为现代商用的大型服务器的主体,其结构早己不是冯.诺依曼式计算机的模式了,为了满足商业客户对于信息系统高可用性、安全性、可扩展性、容错性等要求,大型机的基本架构已逐渐在多个方面演变、强化、改善和提高了。针对不同的业务系统提出的不同的性能指标,大型机在应用架构上也有所区别,这是综合考虑系统性能、经济效益、管理成本的结果。对于本文所要论述的商业银行核心系统而言,大型机的基本架构是以并行藕合技术为基础建立的。
IBM的Z系列大型机的并行耦合(Parallel SyspleX)技术是一种计算机集群技术,所有集群中的服务器都被允许并发的读写所有共享的数据,同时这些对于数据的访问也不会影响系统的性能和数据的完整性。整个集群中的操作系统共享CPU、存储设备、内存等资源,这使得任何交易都能被动态的分配到藕合集群中可用的处理器上并行执行。相较于分布式计算中的UN工X系统集群,并行耦合技术中的最大优势在于其互联设备,从硬件架构上分析,前者依靠网络设备互联,其系统吞吐量受到数据带宽、路由选择等,有较大限制,影响系统性能,而后者则依靠虚拟技术实现通过主机内的各种数据总线连接CPU、I/0、内存、网络设备等,其传输速度远远高于前者,同时也能有效降低管理成本和复杂程度。
另外,作为核心业务的运行环境,并行耦合技术提供了系统所需的可用性指标,集群中任何一个系统的应用故障都不会影响到整个集群的工作,而在这类集群中也没有类似UNIX集群中网络设备的单点,故基本不存在系统瓶颈。
相较于分布式集群中消息传递通信机制,大型机环境集群普遍采用共享地址空间通信机制,不只是内存地址,还包括磁盘、磁带等存储介质,这种体系结构带来了诸多技术优势,首先,它与传统的数据读写和通信机制完全兼容,不存在互相排斥的问题,这对于商业用户信息系统的可用性、连续性、灵活性上有着极为重要的意义,也能够促进以此类架构为基础的信息系统的推广。其次,由于系统所有内存、磁盘地址共享,任何应用程序在编程时不需考虑硬件设备的物理位置,相比分布式集群,剔除了网络层面的数据转换、地址解析等步骤,使得整个程序的开发相对简单,尤其在执行期间要求处理机之间实施复杂或动态可变的通信模式时,优势史为显著。第三,摒弃了网络传输上存在的消耗,进步提升了系统的I/O效率。大型机通过总线完成各类数据的传输,不仅速度较快,且规避了网络通信机制中许多保护数据完整性的系统开销,能够更高效地利用带宽。最后,此类体系架构拥有使用硬件控制的快存(Caching)能力,可有效减少非本地通信的次数与频度;能支持对所有数据的自动快存,不论是共享的或者是私有专用的。快存化提供了减少延迟时间(latency)的优点和减少存取共享数据时的竞争(大量访问在CACHE)。可想而知,即使在相同硬件能力下的两个应用环境,大型机依然能够利用其自身较为合理的体系结构提供更加优秀的性能。
不过,并行耦合技术(大型机环境)也不是完美的,例如,集群中的任何物理设备的故障都可能影响到整个集群的性能。动态分配意味着所有逻辑分区上的系统动态共享所有物理资源,一旦存在物理设备的故障,将导致所有设备受到影响,致使整个集群的性能下降。有鉴于此,各种工作负载管理器对于硬件的故障侦测和隔离技术也在不断发展,致力于及时发现、判断、隔离故障硬件,通过动态分配,确保整个系统的可用性和性能。
银行核心业务系统的一个重要组件就是中间件,而在整个系统架构中,中间件的主要工作就是处理大量的联机交易。由于整个系统是建立在IBM系列大型机上的,出于软件兼容性考虑,系统的中间件选取了IBM的CICS(Customer Information Control System,客户信息控制系统)。CICS作为一个强有力的联机事务管理系统,具有商业级事务管理器要求的数据完整性、可恢复性、安全性和可用性,具有跨平台的广泛的拓展性,提供多平台的API,从而形成可移植的应用和开发技术。CICS可为应用程序的开发、通信、恢复、显示、数据管理、安全性和内部通信等提供多项服务,其结构设计也是面向事务处理的,它构建的是一个三层次结构的应用系统,有效地区分应用系统中的表述逻辑层、业务逻辑层和数据逻辑层,从而使应用系统结构清晰,维护简单易行。
DB2(for Z/OS)主要应用于大型机开发平台,具有较好的拓展性、可伸缩性,能够提供高层次的数据一致性、完整性、安全性、可恢复性,以及覆盖由小到大各种规模的应用程序的执行能力,具有与平台无关的基本功能和SQL命令,无论对数据进行插入、更新、删除还是利用工具修改,DB2都会通过一整套逻辑一致性从各个粒度、层面保护数据。DB2采用数据分级技术,使得客户机/服务器用户和基于局域网的应用程序可以访问大型机环境数据,并使数据库本地化及远程连接透明化。DB2具有很好的网络支持能力,单个系统可以连接十几万个分布式用户,可同时启动上千个线程,对大型分布式应用系统(例如大型机集群)尤为适用。另外,DB2拥有一个非常完备的查询优化器,其外部连接改善了查询性能,并支持多任务并行查询。
UNIX系统集群分布式计算
集群系统是一种并行计算机架构，它将一组计算机以某种方式联结起来并协同完成特定的任务。在这个计算机组合里，每个提供服务的计算机服务器我们称之为一个节点，通常情况下，每个层次的平行节点为用户提供相同的服务，这些
节点以以太网或者专用网络连接。一个在局域网基础上联结在一起的计算机集群在物理上是多个系统，但对于应用软件和用户来说就像一个单一的系统一样。这样的系统为我们在昂贵的大型机和专用共享存储之外，提供了更为便宜的方式来获得商业需求的性能和服务的解决方法。
集群系统主要包括以下几个部分，由外到内分别是：并行编译环境及工具、应用程序、集群中间件、快速通信协议和服务、网络接口硬件、高性能网络、多个高性能计算机。
集群系统有以下几个优点：
- 高性能：多个平行节点为用户提供相同的服务，负载均衡集群允许系统同时接入更多的用户，而避免了因突然的并发数量导致单一服务器超载。
- 高可扩展性：一个高端的商业集群系统具有良好的可扩展性，这样，在面对用户的增加、信息量的累积时，只需要增加节点数量便可以提高系统的性能和服务，而不需要重新构建新的系统。采用集群技术的系统的性能与 CPU 的个数几乎成线性比例。
- 高可用性：当系统在发生故障时可以继续工作，将系统停运的时间降到最低。
- 高性价比：集群系统的节点服务器通常由中型机担任，在达到相同性能的前提下，集群系统要比由大型计算机担任服务器的系统要具有更高的性价比。
根据要实现的功能不同，集群系统分为以下几类：
- 负载均衡集群
负载均衡集群使得所有负载在整个集群中尽可能平均的分摊处理，充分的利用集群内所有节点的处理能力。在这种集群中每个节点都能处理一部分负载，而且节点之间可以动态分配负载以实现均衡。在这种集群中，其总处理能力是所有节点的处理能力的总和。由于集群内多个节点都可以提供统一的服务，当某一节点发生故障时，其他节点仍可以继续工作，从而保持了服务的连续性，所以这种负载均衡集群也展示了一定的高可用性。 - 高可用性集群
这种集群旨在提供不间断服务。通常为了实现不间断服务，有以下两种方式。
一种传统的定义是 HA 结构，及每个节点都由主备服务器组成，备用服务器以 heartbeat(心跳)的方式确认主服务器是否可用，若主服务器因故障宕机，则由备用服务器接管服务，当主服务器恢复时，服务再由主服务器重新接管。这种结构通常用于数据库集群。
另一种是将每个请求的用户信息和请求信息在各个节点之间进行互备（互相备份），当 A 节点宕机导致请求中断时，B 节点从相应存储器中获取请求信息，并继续执行该用户的请求，保证服务的不中断。 - 高性能集群
高性能集群致力于提高集群系统的计算能力，各个节点协同工作，在处理大问题时，每个节点负责一部分，并在处理过程中根据需求进行数据交换，最后的计算结果由各个节点共同提供。高性能集群的性能与该集群的规模成正比，但这种集群缺少了高可用性。
中间件
中间件特点是满足大量应用的需要,运行于多种硬件和OS平台,支持分布式计算,提供跨网络、硬件和OS平台的透明性的应用或服务的交互功能,支持标准协议,支持标准接口。
在分布式事务处理中要处理大量的事务,常常在系统中要求同时进行上万笔事务。事务处理中间件是专门针对联机交易处理系统而设计。联机交易处理系统需要处理大量并发进程,处理并发涉及到操作系统、文件系统、编程语言、数据通讯、数据库系统、系统管理、应用软件,是一个相当艰巨的任务,但是工作的难度可以通过采用交易中间件简化。交易中间件其实就是一组程序模块,用以大大减少开发一个联机交易处理系统所需的编程量。X/OPEN组织专门定义了分布式交易处理的标准及参考模型,把一个联机交易系统划分成资源管理(RM)、交易管理(TM)和应用(AP)三部分,定义了应用程序、交易管理器、多个资源管理器是如何协同工作。资源管理器是指数据库和文件系统,交易管理器可归入交易中间件。交易中间件管理由应用声明和提交的交易,并通过两阶段提交协议等方式保证分布式交易的完整性、控制并发、实现交易路由和均衡负载。交易中间件理论上已经相对成熟,功能和性能界定清晰,适用于联机交易系统。尽管交易信息也是消息,交易中间件也是基于消息的传输,也可支持同步和异步方式,但它与消息中间件的定位差距较大,它是一种较专用的中间件。
TUXEDO 中间件
中间件是一种独立的系统软件或者服务程序，分布式引用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通信。
TUXEDO 就是一款这样的中间件产品，现在已经成为了中间件领域上的标准。如图是 TUXEDO 的软件模型。
TUXEDO 采用的是三层模型。第一层是客户层，作用是实现了用户和数据之间的交互和表示，同时向第二层区调用一些处理逻辑的服务。第二层是服务器组件层，该层是实现核心业务逻辑的服务，处理一些数据，同时接受从其他服务
器发出来的请求服务。第三层是资源管理层，该层是负责对应用数据的管理，类似于数据库的功能。
TUXEDO 中间件具有如下特点
（1）平衡负载。在多台机器作为应用服务器的情况下，系统可以根据每台机器的负载情况来决定哪台机器可以当作服务器
（2）稳定性。如果在分布式系统中的某一个节点出现故障时，中间件系统可以在硬件发生故障的情况下，在其他的节点上去运行程序保证服务的稳定性。
（3）安全性。TUXEDO 可以提供数据的加密服务，在网络上传输的数据都是可以进行加密后传输的。此外用户界面是支持验证和授权的。
中小银行的核心系统的架构建立在第三方的中间件基础之上。因为核心系统主要是要完成大量的联机事务,因此必须选取交易中间件,以选取BEA Tuxedo为例。正确运用交易中间件可以缩短开发周期,节约开发成本,简化应用集成,增加系统的可靠性,在可扩展和性能方面都能得到进一步的增强。将通讯、服务调度、数据访问交由中间件来处理。
在BEA Tuxedo可管理多层(ManagedMulti一Tier 一MMT)C/S模式中,提供以下功能:
- 在客户端和服务端之间进行通讯和传输;
- 提供良好的系统管理;
- 提供交易、配置的分布式管理。
它管理服务端从多个客户端收到的数据流,并不是在C/S间建立一对一的关系,而且客户端可以向多个服务发出请求。这种特点保证了TUXEDO可以提供强大的分布式交易处理框架。
由于不必进行通讯和交易管理,数据库引擎可以专注于其特长:管理数据,在这种情况下,数据库成了一个纯RM(ResoureeManager)。MMTC/S模式给核心业务系统的OLTP应用增加了如下优点:
- 所有C/S模式的优点在MMT模式下都得到了增强。实际上,由于中间件的引入,处理能力得到改善。
- 由于中间件管理了数据流,带来了许多新功能,如:交易路由、服务分布、渠道、数据依赖路由等成为可能。
- 统一的数据流控限制了最大交易数,总的数据库过程少,服务器空闲时间也少,这就增加了数据库和系统效率。
-
应用代码的设计可以不考虑物理地址和内部数据表示配置成了一件单纯的管理工作,进一步可以通过配置轻易的改变系统结构。
服务可以动态的增加、删除和重启动。构成TUXEDO系统的各部分、工具和其特性组成的MMTC/S模式给核心业务系统的开发带来了很大的便利,这些优点及实现方法如表
image.png
基于TUXEDO的多层C/S方案
随着交易中间件技术的发展和网络技术的日益完善,己经能使系统对用户的请求作出快速响应。设计主要采用基于TUXEDO Bea应用服务器的体系结构。
三层C/S架构主要包括表示层、服务接入层、业务逻辑层和数据逻辑层,然而在核心业务系统中表示层多种多样,有银行专用、基于IE、第三方的系统等,各种各样,这些表示层的接口的方式、格式、加密措施等均不相同,如果直接和业务逻辑层相接,则业务逻辑层需要对它们的通信接口分别处理,这将增加业务逻辑层的复杂性,业务逻辑层的扩展性、处理效率就会差,不符合三层C/S架构的思想:业务逻辑层专注于业务逻辑的处理。为此,在表现层和业务逻辑层之间再增加一层,命名为服务接入层,即分为表示层、服务接入层、业务逻辑层和数据逻辑层。其中服务接入层、业务逻辑层和数据逻辑层是典型的三层C/S架构,服务接入层具有表示层的功能,它是将多种表示层整合为一个统一的表示层。
1、表现层
表现层包含了多种渠道,有基于字符终端的高柜、基于Web的低柜、自助终端、电话银行、网上银行、短信、自助设备(ATM、POS、CDM)、和外系统专线连接等。这些渠道在核心系统中是各种服务请求的接口表现和数据传输请求,它们只有简单的数据形式和取值范围的检查,没有业务处理逻辑。如果某种银行服务可以存在于多个渠道上,那么仅只是这些渠道提供的银行服务的表示是个性化的,但服务内容和流程是共享的。
表现层分为三类:
第一类:银行内部本身的柜面系统,功能单一,目前以C语言为基础开发,通讯格式与服务接入层一样,能被业务逻辑层中标准的服务(Server)接受;或银行内部的外挂系统,如信贷管理、国际结算、财务管理等,有标准的统一接口,外挂系统是一些专业性较强的业务处理子系统,作为一个渠道通过外挂的形式和核心系统形成一个整体的业务系统。外挂系统只负责其特有业务处理流程的控制,其帐务处理是通过服务接入层和核心业务层来完成。
第二类:银行外部的系统,有行业标准如ATM、CDM、POS、金卡、人行,但这些系统的接口标准不尽相同。
第三类:也是银行外部的系统,没有行业标准,只是它们系统内部的标准。如公用事业的代收代付、水、电、煤、电话等,没有统一的规定。
对于第一类,可以直接访问业务逻辑层,以提高效率,减少中间环节,服务接入层的作用只是消息转发,无其它任何处理。
2、服务接入层
服务接入层就是负责把各渠道的服务请求进行整合,形成统一的对核心业务处理层的交易请求。各渠道的服务请求报文各不相同,有定长和不定长方式,本系统中服务接入层对核心业务处理层的请求及应答采用扩展的ISO8583报文格式,当然也支持其它报文格式。ISO8583包(简称8583包)是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,有定长和变长之分。
服务接入层是整个系统的应用路由中心,是本身局域网内的中心节点,它和其它节点形成星型结构,其它节点的报文交换通过它来调度。
服务接入层的主要功能是通讯网关、应用路由、报文解析、流程控制。
通讯网关负责和其它系统的通讯。银行应用系统都要求通讯传输是实时的,交易报文如果不能及时到达,一般认为通讯失败,交易不能成功。
应用路由是系统内部通讯的交换器,负责网关和应用核心之间的通讯。应用路由能够将一个指定目的地址的消息报文发送到能够到达目的地址的下一个节点;也能将没指定目的地址的消息报文按照配置指定目的地址,并发送到能够到达目的地址的下一个节点。
报文解析是服务接入系统中和外部(主机、网银、第三方等)进行数据交易的模块。报文解析在系统中是一个相对比较独立的模块,它和系统中其它模块的接口主要是数据池(POOL池)。报文拆包时,报文解析模块按照报文格式的定义,把报文内容拆解到POOL池中;报文打包时,报文解析模块按照报文格式的定义,从POOL池中提取报文中需要的数据项,打成外部格式的报文。
服务接入层与核心业务逻辑层的通讯,利用TUXEDO客户端的系统调用来完成。
3、核心业务逻辑层
核心业务逻辑层包括BEA Tuxedo的事务管理器、可靠队列服务、应用域和服务(Server)。
事务管理器是Tuxedo的体系结构的中心,是Tuxedo服务器的核心,提供重要的分布式应用服务,包括:名字服务、数据路由器、负载平衡、配置管理、分布式事务管理和安全管理。它包含Tuxedo。的核心数据结构公告板BB(Bulletin Board),BB中包括服务名、路由信息、请求服务的队列和负载等基本信息,Tuxedo/T负责访问和维护BB中的信息,并利用这些信息实现其各项功能。
可靠队列服务保证系统提交的请求和数据可在网络故障或目的服务瘫痪的情况下,也能递交到目的服务器,应用程序将服务请求入队和出队,并可以设定系统,使队列中的请求自动地转发给Tuxedo的服务进程,并取回处理结果。
应用域是将核心业务系统按功能或结构划分为不同的域,每个域独立完成域内的操作,域间操作由域网关完成,以提高每个域和整个系统的运行效率。
服务由不同交易集合组成,这些交易是相互独立。系统在运行过程中,这些服务形成一个个处理进程。负责处理银行业务逻辑。
银行业务主要是开销户管理、存款业务、取款业务、银行结算、外汇兑换、贷款业务等
4、数据逻辑层
数据层是后台数据的存储层,它存放所有的核心系统后台数据,并提供标准和非标准的构件对这些数据进行访问,这些构件被业务逻辑层的交易进行调用。
核心业务系统服务模块设计
核心业务处理层中的服务(Server)是对交易(Service)的封装。一个服务包含有若干个独立的金融交易。每个服务是相对独立的系统。服务之间的访问视同如在服务接入层访问核心业务处理层中的服务一样,被访问的服务是服务端(Server),访问的服务是客户端(cllent),从而产生了联动交易,即在一个事务处理中完成对多个服务的访问服务(Seryer)的处理流程
虽然服务的内容不同,但每个服务的流程是一样的,一个服务的生命周期如图所示
服务(Server)的模块设计
在核心业务系统的设计上服务(Serve:)处于核心业务逻辑层。根据服务的生命周期的特点,我们把服务划分为四个模块:服务初始化模块、服务入口处理模块及每个服务的交易入口处理模块和服务结束模块。其中,服务初始化模块、服务入口处理模块及服务结束模块对于每一个服务(Server)功能都一样,不同的服务主要体现在交易入口处理模块的配置,不同的配置会产生不同的服务。
客户端(Client)的模块设计
Tuxedo有两种客户端:本地客户端和远程客户端。本地客户端(Native Client)是指客户端与Tuxedo应用服务器在同一台机器上,不用通过网络就可以访问Tuxedo的应用服务器;远程客户端(WorkstationClient)是客户端需要通过网络才能访问Tuxedo应用服务器。本系统的客户端主要是指服务接入层上对核心业务逻辑层的访问,或表示层上银行柜面系统经服务接入层对核心业务逻辑层的访问。
基于BEA Tuxedo的多层C/S架构的核心业务系统选用UNIX操作系统,主要的原因是UNIX系统稳定、安全、可靠。其架构有两种方式,即单集群和多集群方式。单集群方式主应用服务器单一,多集群方式主应用服务器有多个。
左图比较简单、单一,服务接入层前置直接访问唯一的应用服务器,是单集群方式。右图较复杂,服务接入层前置可以有选择的访问多个应用服务器,是多集群方式。从服务接入层前置的软件设计来比较,多集群复杂,在渠道前置机上要区分所要访问的哪一台应用服务器,而对于应用服务器端来说,部署一个或多个应用服务器的复杂程度一样。两者比较如表:
多集群方式在设计上,任一台主应用服务器上可提供所有服务,由渠道任意选择,静态控制着系统的负载均衡。在接入层前置应用设计上增加交易服务路由参数表
例如:对于相同的Tx0101(卡取现金交易)分别来自于三个渠道(柜面、银联ATM和本行ATM),都对应于同一服务Uwithdraw,而服务Uwithdraw可分布在三个不同的主服务器上,表示层的请求信息经过渠道层时,访问此表,获取服务名和访问的主机地址,由渠道层决定表示层所要访问的应用服务器。
理论上,单一应用服务器方式可以把它看着是多应用服务器方式的特例,在上表中设为同一应用服务器。将来随着业务量的增加,如果要动态地增加应用服务器,只需在渠道上调整交易服务路由参数表的应用服务器和应用服务器地址这两个参数。
多集群方式也进一步提高了系统的安全性。当增加一个新的服务时,为了不影响现有的系统的正常运行,不影响其它服务性能的情况下,可以把新的服务增加到备用应用服务器中,在渠道的交易服务路由表中指明所要访问的备用应用服务器,待系统稳定运行后,再把新的服务加入到原有的应用服务中。
当然,中小银行随着规模的不断扩大,分支机构不断增加,利用多集群方式的特点,还可以把新增加的机构的请求服务指向独立的应用服务器上来专门处理。
如果在设计阶段不能考虑增加交易服务路由参数表,那只能是单一主应用服务器方式,扩展性就比较差。总之,多集群服务方式是网状式提供服务,可以根据系统性能的变化,通过调整交易服务路由表的参数,优化应用服务的性能,同时还可以把应用服务器按服务的类型或机构分为多种专用的应用服务器,使得在新业务增加和新机构增加的情况下系统的性能保持相对的稳定。
交易和服务的自由组合
在核心业务系统中,后台提供服务(Server)供前台调用。后台的服务又由若干个交易(Service)组成,如图
从图可以看出,一个服务包含了多个交易,一个交易可以被几个服务来包含,这些将根据系统的性能变化,在运行阶段来调整。
设计时将交易放在一起的原则是:
(1)有互相调用的SERVICE不放到同一个SERVER中,有可能同时要访问某一资源,引起死锁现象。
(2)执行时间相近的SERVICE可放到同一个SERVER中。
(3)同一个SERVER中的SERVICE有相同的服务优先级,如果不同,最低的那个的请求可能要很长时间才得到处理。
(4)一个SERVER中不能有太多的SERVICE。
(5)把多资源要求相近的SERVICE放到同一个SERVER中。
(6)可根据业务规则把SERVICE放到同一个SERVER中。
(7)对一些使用率较高的(如:银行的取款对应的SERVICE)应单独放在一个SERVER中,并采用MSSQ方式。不把它们与其它的SERVICE放在同一个SERVER中。
中型机组成的集群系统
AIX、IBM 商用中小型机器 AS400的操作系統 OS/400
WAS(Web Application Server)
WAS 是实现 J2EE 体系结构的平台解决方案，它的作用在于在客户端/服务器环境下，动态处理和管理事务(Transaction)并联动异构系统之间的应用程序
Jeus 是 WAS 的一种。
Webtob 是 TmaxSoft 公司的 Web 服务器解决方案，设计用来处理通过 Web浏览器使用 HTTP 协议发送的请求。Webtob 克服了传统 Web 服务器解决方案的局限性，提供更高的稳定性和性能。
新韩银行
B/S结构(Browser/Server,浏览器/服务器模式),是WEB兴起后的一种网络结构模式,WEB浏览器是客户端最主要的应用软件。这种模式统一了客户端,将系统功能实现的核心部分集中到服务器上,简化了系统的开发、维护和使用。客户机上只要安装一个浏览器(Browser),如Netscape Navigator或Internet Explorer,服务器安装 Oracle、Sybase、Informix 或 SQL Server 等数据库。浏览器通过Web Server同数据库进行数据交互。这样就大大简化了客户端电脑载荷,减轻了系统维护与升级的成本和工作量,降低了用户的总体成本。B/S结构最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。只要有一台能上网的电脑就能使用,客户端零维护。系统的扩展性非常容易,只要能上网,再由系统管理员分配一个用户名和密码,就可以使用了。甚至可以在线申请,通过公司内部的安全认证(如CA证书)后,不需要人的参与,系统可以自动分配给用户一个账号进入系统。
例如：SmartTeller
SmartTeller 的开发平台，采用 Java、HTML、XML 和 TCP/IP 等开放的工业标准进行设计，使系统具有可移植性、可维护性和可扩展性。开发平台分为客户端的开发和服务器端的开发。
服务器端开发：通过工业标准开发环境来开发服务器端的构件。SmartTeller 开发包是基于银行的业务规则和需求来开发客户化应用的。新的开发结果将加入到应用元件库，元件库中包括信息、对象以及用于描述业务流程相关的所有工作的参数。这些元件将用于应用的开发、网页的制作等。
客户端开发：SmartTeller 采用 Web 开发工具用来开发客户端的 HTML 页面、Applets和 Web 站点的布局，通过 Web Server，Java Applet 附在 HTML 页面上发送到需要的地方。
X86服务器（微服务架构＋分布式数据库）
例：民生银行
分布式核心应用分层架构基本上可以分为四层,最上面这层叫做服务治理层,在这层上民生银行采用的是阿里云的Dubbo服务。民生银行在2013年与阿里云签订了协议,阿里云将Dubbo开源给民生 银行,民生银行在Dubbo上做了改进以适应银行的金融场景。第二层叫服务组装层,第三层叫原子 服务层,最后一层是数据库层。在应用层是服务治理的能力,过去银行在讲敏捷开发的时候,最困 难的地方在于微服务的治理。这在传统的系统架构上面是很难治理的,也导致了系统的开发很难复 用,但是民生银行这一次通过分布式化把服务治理好了以后,很多服务可以重新复用,无形之中能 快速的迭代开发,包括在数据层和基础设施层。
整个分布式技术平台包括的功能有:
1、分布式数据库访问。一个理想的数据库架构,其实最开始设计的时候就应该考虑很多后面的事情 ,但是大部分银行应用迫于业务的压力而匆匆的上线,导致后期很难修改,所以在数据库层面,民生银行进行分库分表,读写分离。
2、分布式事务。在分布式事务上面,民生银行是基于可靠消息的最终一致性和基于冲正模型的反向处理,来保证数据库可靠运行。
3、分布式服务框架与服务管控以及第四分布式批量作业调度。这是金融行业与传统的行业不一样的地方,在一个多并发的情况下,分布式的消息处理能力是最关键的,之前民生银行试了很多开源的框架,但是在压力测试下,都不满足民生银行的要求,因此民生银行重写了一套专有的批量作业调度的框架。
还有分布式配置管理、消息中心、分布式缓存,交易幂等性、统一冲正,全局系列的核心功能,这些所有的核心因素集在一起,构建了分布式的技术核心平台。
在分布式的技术架构的设计上面,有应用的分布式和数据库的分布式。通常大家在讲分布式的时候 ,有的是在底层数据库上实现分布式,有的是在应用层实现分布式。因为银行系统的业务在很多时候需要靠业务逻辑,需要保证应用的可靠运行,但是底层也需要分布式改造,所以民生银行系统的 核心架构在应用层和数据库层都实现了分布式。在应用的分布式上,首先在服务接入层实现了服务路由及管控能力,支持服务与数据单元化部署,然后在分布式服务层,建立分布式服务框架,集成 分布式消息及批处理框架能力。在数据的分布式上,首先在分布式数据库层实现分库分表的数据水 平扩展能力,然后在DevOps层面上建立分布式运维基础能力,支持分布式应用的持续集成和部署。
分布式建设中攻克的难点
1、在服务接入的时候技术难点
包括服务网关、访问控制、服务限流、交易幂等性等,系统需要提供服务的统一接口,并将外部请求路由到相应服务;需要提供细粒度服务访问安全控制,确保系统的安全生产运行;提供多维度服务限流,有效的应对瞬间爆发的高并发访问;支持交易幂等性,防止同一笔交易重复处理。
2、平台应用技术难点
包括服务框架、配置中心、消息中心、批处理框架等。需要攻克这些难点,提供面向远程过程调用的服务框架和面向消息通信的消息中心,解决分布式环境下大量应用节点配置管理和变更复杂的问
题,提供应用于数据分布式之后批处理作业开发与运行的机制。
3、配置中心技术难点
主要解决配置分发时的时延控制和多节点的一致性控制。
4、数据访问的技术难点
解决分布式数据访问问题,实现数据库水平扩展,完成分库分表、读写分离的SQL自动路由,且对 应用透明,性能高。解决分布式运维问题,支持数据库分表后的应用数据运维支持。
5、应用分库分表的技术难点:
数据库层支持横向扩展,尽量避免分布式事务,应用透明,降低运维复杂度。
6、一致性保证机制:
充分应用微服务和组件化的设计思想,充分解耦应用,最大程度避免分布式事务,在幂等一致性上由服务提供方实现服务处理的幂等性,避免重复提交事务。应用通过冲正、对账、一致性检查等补偿手段确保业务完整性和最终一致性。采用两阶段提交实现分布式的强一致性。
分布式架构实施建议
1、应用架构的X86化改造,目标是开发统一的分布式微服务框架,实现应用无状态化,数据集中, 统一管控。
2、云化基础设施改造,实现数据与业务分离,实施业务去状态化改造,并将数据层迁移到云化基础 设施,建立云平台,存储计算虚拟化,数据库分布式部署。
3、云化服务,打造开放的服务能力平台,抽取公告技术服务能力,统一数据处理,全面部署X86集 群,减少对数据层逻辑依赖,构建公告数据处理。
另外在应用设计上面,总则是进行垂直水平切分,垂直切分优先,并尽量拆分成流水型应用和状态 型应用,并将状态型业务集中下沉。目前民生银行已经把直销银行应用到核心系统之上了,运行效 果非常好,现在正在计划把其他的例如网银、手机银行等系统全部采用这样的核心分布式进行改造 。
核心系统采用两地多机房的部署架构，同城两个机房同时对外提供服务，核心账务数据按照客户号进行逻辑分区，每个机房包含多个逻辑分区，逻辑分区之间相互隔离，外部交易请求通过全局路由技术组件，根据路由规则路由到相应的机房和相应的逻辑分区。
这种方式改变了同城机房传统上只作为热备而不对外提供服务的使用方式，有效提升了机房资源利用率；同时可以在同城两个机房分别服务于不同的客户，在机房出现故障时能够降低客户影响范围，同城机房实现秒级切换，更有效地保障业务连续性，分布式核心系统双活部署架构如图
