网上银行系统应用交付建设案例分析.docx
《网上银行系统应用交付建设案例分析.docx》由会员分享，可在线阅读，更多相关《网上银行系统应用交付建设案例分析.docx（18页珍藏版）》请在冰豆网上搜索。
网上银行系统应用交付建设案例分析
1网上银行系统应用交付建设案例分析
随着互联网和电子商务的发展，越来越多的银行客户喜欢在网上操作银行业务，因此，在各大银行中，网上银行的建设都是重中之重的一个系统。
并且，作为一个对Internet开放的电子渠道，在网上银行建设中会面临各种复杂的问题。
本节就以银行网上银行建设作为一个案例，讨论应用交付网络在银行新一代数据中心建设中的主要作用以及建设规划。
在网上银行建设中，可能使用F5应用交付网络中的以下产品和技术：
B✋☝-✋P☝❆M:
用于数据中心虚拟化建设，通过GTM的统一域名解析，提供网上银行用户的统一接入点。
隐藏实际多个物理数据中心概念，实现多数据中心的并行处理和灾难备份。
并且通过智能判断实现用户就近接入，提高客户体验。
B✋☝-✋P☹C：
用于链路虚拟化建设，通过LC的统一域名解析和多链路接入处理，提供网上银行用户的统一接入点。
隐藏实际多条物理线路的概念，实现多链路的并行处理和故障备份。
并通过智能判断实现用户的优先链路选择，提高客户体验。
B✋☝-✋P☹❆M：
用于应用虚拟化建设，通过LTM对服务器应用的虚拟化处理，在同一数据中心中对网上银行用户提供同一的访问地址。
隐藏实际多台物理服务器的概念，实现服务器的负载均衡处理和高可用性自动切换。
B✋☝-✋PS✌M：
应用于大客户的远程安全接入，通过SAM安全接入控制器，位于Internet上的客户端可以安全的接入到银行的安全区。
企业客户可以通过SAM建立一条直接与银行业务服务器之间的沟通渠道，起到替换原有专线接入的效果。
B✋☝-✋PW✌：
用于应用优化处理，通过WA的硬件SSL加解密功能、HTTP页面压缩功能和动态内容加速功能，提高远程客户的访问速度，并减小网上银行系统的Internet接入带宽。
在提高客户体验的同时节省银行的Internet接入带宽费用。
B✋☝-✋P✌SM：
用于Web应用安全处理，通过ASM的被动和主动安全模式，可以对已知和未知的Web应用攻击进行应用层面的安全防护。
实现代码级的应用安全。
1.1网上银行系统结构规划
在大型银行的数据中心建设中，通常设计为2个或两个以上的数据中心，数据中心之间采用Gbps以上高速连接。
根据银行的网上银行发展战略的不同，通常情况下，网上银行的系统建设分为两种部署结构，初期建设时采用单站点结构，在进一步完善的时候采用多站点结构。
1.1.1单站点结构
单站点结构主要用于在系统建设的初期，在数据同步、后台处理的技术手段尚不完善的情况下使用。
在单站点结构中，使用一个数据中心作为网银的中心接入点，在系统的最前端，使用多台GTM设备分布在每条链路上，作为用户访问流量选择的控制设备。
在链路的接入层采用一对BIG-IP高端设备，并安装LinkController模块，作为系统的接入点。
负责处理链路接入、NAT和安全防护，并且和GTM配合，实现接入链路应用的最大优化。
高端BIG-IPLTM的理论最高吞吐能力为36Gbps，可以在较长的一段时间内满足网上银行扩展需求。
在前端接入后，采用多台防火墙设备形成防火墙负载均衡结构，多台防火墙同时工作，并通过两端BIG-IPLTM实现负载均衡和高可用性。
多台防火墙可以采用同一品牌或者不同品牌的防火墙实现安全和高可用性的最大化。
在防火墙负载均衡结构后，根据业务的类型，建议采用三对BIG-IPLTM高端设备分别处理Portal，对公和个人业务实现防火墙负载均衡和服务器负载均衡。
这几对BIG-IPLTM的处理基本上为混合模式，既包含四层模式也包含七层工作模式，针对不同的应用采用不同的工作模式。
余下的Proxy、邮件等业务可以单独采用一对BIG-IPLTM实现负载均衡。
在负载均衡处理的BIG-IPLTM后，可采用多台应用加速和应用安全设备（BIG-IPWebAccelerator和ApplicationSecurityManager等）实现应用加速系统，其中包括：
SSL硬件加解密、HTTP页面压缩、Web应用加速等多项功能。
这些设备主要以运行在七层工作模式为主，其主要目的为提高用户体验、节省带宽、减小服务器端压力和提高系统应用安全性。
在Web层到应用服务器层之间，可以选用一对F5BIG-IPLTM设备实现对应用服务器的负载均衡，在这对BIG-IPLTM上主要以七层工作模式为主，主要实现对应用服务器的连接优化、七层会话保持等。
考虑到系统的风险分担，也可以采用多台BIG-IPLTM按照业务类型进行分别处理。
1.1.2多站点结构
当网银系统发展到一定规模时，则建议采用多站点分布式处理。
多站点分布式处理与单站点处理的主要不同点在于存在两个数据中心，但在大部分的情况下，数据库还是只能使用一个数据库作为主数据库，因此涉及到数据库远程访问的问题。
根据应用的类型不同，可能存在两种方式：
Web->APP通过广域网
Web-APP通过广域网主要适合于一次客户端请求，应用服务器需要对数据库进行多次查询的应用特点。
将需要多次交互才能得到结果的这部分工作在局域网内完成。
减小在广域网上的多次来回以减小延迟带来的影响。
APP->DB通过广域网
APP-DB通过广域网主要适合于在应用服务器一次查询得到结果后，客户端需要多次请求才能获得全部结果的应用特点。
同样的道理，将需要多次交互才能得到结果的部分在局域网内完成，减小在广域网上的多次来回以减小延迟带来的影响。
无论采用哪种方式，均可通过BIG-IPLTM或者内网GTM实现站点间的高可用性，保证在任何一个数据中心只要有同一应用的一组服务器在工作，就可以实现用户访问的不间断。
1.2网上银行数据中心虚拟化（广域网负载均衡）
F5BIG-IPGTM主要通过DNS解析来实现数据中心虚拟化功能。
当用户访问网上银行的各个应用的时候，首先是通过一个统一的域名进行访问。
而这个域名的解析权由GTM进行控制。
在每一个数据中心，针对同样的业务，都对外提供一个IP地址服务。
而GTM则根据特定的算法给用户端的DNS请求返回不同数据中心的地址。
从而实现虚拟化的数据中心访问控制。
在GTM内部，可以有以下算法保证用户始终访问到最佳的数据中心节点。
• 循环
全球可用性
☹D☠S持续性
应用可用性
地理分布
虚拟服务器容量
最少连接
Pk♦/♦♏♍（数据包/每秒）
KB/♦♏♍（千字节/每秒）
往返时间
中继段（♒☐☐）
数据包完整率
用户定义服务质量（✈☐S）
动态比率
☹D☠S循环
比率
随机
在实现优选算法的同时，GTM还将动态检查每个数据中心的业务实际运行状态。
如果发现某个数据中心的某个业务出现故障，则将其和其相关业务从DNS解析选择组中去除，而只返回给客户端仍然正常工作的数据中心业务地址。
1.3网上银行链路虚拟化（链路负载均衡）
由于采用了多条链路接入，在实现链路虚拟化的时候，必将面临将系统中的一台或多台服务器同时对多条链路提供服务的问题。
在系统设计中，我们采用了F5BIG-IPLTM/LC来实现了多出口接入。
如图：
在BIG-IPLTM/LC实现多链路接入的时候，采用了BIG-IPLTM/LC上的AutoLastHop技术。
对于每条线路，在BIG-IPLTM/LC上均配置一个与线路分配网段对应的IP地址，这些IP地址均映射到后端的一台或同一组服务器。
当用户访问不同地址的时候，BIG-IPLTM/LC上将建立每个请求与来源设备Mac地址的对应关系表。
即将每个用户的请求连接和上端的路由器MAC地址进行对应，在服务器数据返回的时候，则根据该对应表将返回的数据包发送到相应的路由器，避免了数据往返通路不同的问题。
通过AutoLastHop技术，BIG-IPLTM/LC得以内部的单台或者一组服务器对外映射成为多个服务IP地址和服务端口，以提供DNS解析选择。
当一个系统中没有GTM存在时，BIG-IPLC将自行负责DNS解析，自动将用户引导到最佳的链路上。
同时，BIG-IPLC对每一条接入链路的健康状态进行检查，一旦发现某一条链路发生故障，则对外停止该链路上的所有服务地址的解析。
保证用户访问的持续性。
1.4数据中心和链路虚拟化的配合
当网上银行系统存在多个数据中心，并且一个或多个数据中心存在多条链路时，在系统设计中就会同时存在GTM与LC。
GTM与LC之间采用iQuery协议进行加密通讯。
该协议采用443端口，采用标准SSL加密通讯协议对传输内容进行封装。
在协议层全部采用业界标准XML进行数据传输。
●通过iQuery协议，GTM可以从BIG-IPLC上获得以下主要信息：
VirtualServer定义：
通过配置AutoDiscovery，GTM可以自动从LC上获取所有的VS定义和Link定义，从而不需要在GTM中对这些配置进行重新定义和配置。
当在LC上进行VS的添加或删除时，GTM可以自动在配置中对这些VS进行添加和删除，以供WideIP算法进行选择。
LinkThroughput:
链路的带宽使用状态，即每条链路实际使用的带宽大小，GTM获得该信息之后，可以通过带宽负载均衡算法对用户的访问请求进行动态调整分配，使每条链路的带宽使用保持平衡。
同时，在GTM上也可以通过限制每条链路的使用带宽来调整分配算法，避免单条链路使用带宽达到其极限值，避免网络层丢包造成用户访问失败。
该设置也适用于不同的数据中心之间的链路选择。
LinkStatus：
链路的通断状态。
即每条链路的当前健康状态。
GTM获得该信息后，则可以通过链路当前的健康状态决定是否将新的用户请求分配到该链路上。
如果发现链路故障，则将该链路关联的所有VS设置为不可用状态，并停止将新的用户分配到这些VS上，从而避免用户访问失败。
VSConnections:
每条链路上每个应用的当前并发连接数。
GTM获得该信息后，可以通过负载均衡算法和上限设置方法平衡每条链路上各个应用的实际分配连接数，避免单个VS在单条链路上的连接数过高而导致用户访问失败。
该设置也适用于不同的数据中心之间的链路选择。
VSKilobytes/Second:
即每条链路上的VS的流量值。
GTM获得该信息后，可以通过负载均衡算法和上限设置的方法平衡每条链路上各个应用的实际适用带宽，避免单个VS在单条链路上的连接数过高而导致用户访问失败。
该设置也适用于不同数据中心之间的链路选择。
●在GTM从LC上获取信息的同时，也可以驱动LC进行RoundTripTime算法的探测工作
当GTM收到一个LocalDNS请求时，会首先查找本地的RTT表。
如果请求的LocalDNS在该表中，则直接返回RTT值最小的链路上的VS给LocalDNS。
ldns{
address61.136.178.229
cur_target_state419446729
ttl2419199
probe_protocoltcp
path{
datacenter"CNC"
cur_rtt189850
cur_hops0
cur_completion_rate10000
cur_last_hops0
}
path{
datacenter"TEL"
cur_rtt57209
cur_hops0
cur_completion_rate10000
cur_last_hops0
}
}
如果访问的LocalDNS不在表中，则先随机选择一个VS返回给LocalDNS，然后通过iQuery协议通知每个DataCenter的LC对该LocalDNS进行探测。
在得到返回信息后，将返回值存放在RTT表中，以待下次使用。
1.1减小远程访问延迟带来的影响
对于目前的网上银行业务单站点接入结构和多数银行计划中的多站点接入结构来说。
将面临的最大的一个问题就是应用的跨广域网访问。
通常情况下，多数的网上银行系统都是分为3层结构：
由于网上银行的实际功能就是一个银行业务的电子渠道，因此，实际上还存在有App-主机前置的通道，由于App-主机前置的通道在各银行的处理手段不尽相同，因此，在本书中暂时不讨论此部分带来的影响，读者可以根据本书的分析方式去评估如何减小广域网访问延迟带来的影响。
在网上银行的应用结构中，最为核心的部分是数据库系统。
在目前的技术手段中，还没有稳定、可靠的跨广域网并行数据库技术出现。
因此，无论网上银行系统分布在多少个数据中心，其核心数据库只能是集中式的主/备部署，同时采用尽量实时复制的方式，保持主备数据库的一致性。
主备数据库通常位于不同的数据中心。
当多中心并行处理的时候，可能存在有三种跨广域网的数据访问方式：
●用户接入跨广域网
这种结构是最为简单的一种处理手段，采用二层链路透明传输的方式，将异地接入的Internet接入链路汇聚到一个数据中心，直接接入到F5BIG-IPLTM，然后由BIG-IPLTM转发到后台的服务器。
当服务器对请求进行处理后，将回应的请求发送到BIG-IPLTM，再通过BIG-IPLTM的Autolasthop功能，将回应的数据包转发到和请求来源相同的路由器上。
再通过Internet返回给最初发起请求的客户端。
在这种结构下，实际上是利用银行的内部网络延伸了互联网接入链路。
优点是处理简单，方便，比较适合于网上银行的初期建设，避免Internet本身的不稳定现象带来的用户体验问题。
同时避免了应用服务器分布在多个中心带来的复杂性。
其缺点是所有的用户请求并没有进行适当的处理，在占用较多的内部网络带宽的同时，对实际用户体验的提高并不是非常显著（与互联网状态较好时相比较）。
●Web-APP跨广域网
在Web跨广域网的结构时，在每个接入的数据中心至少需要有Web服务层。
用户的请求直接发送到Web服务器，Web服务器对请求的内容进行处理，如果发现请求的是静态内容，就从本地直接返回，如果发现请求的是动态内容，则通过银行的内部广域网链路发送到生产中心的App服务器，App服务器查询本地的数据库服务器之后原路返回内容。
Web-App跨广域网带来的一个主要优点是静态内容可以直接从用户就近接入的数据中心直接返回给客户端，提高客户体验，同时减小了内部的带宽损耗。
缺点是通常在备中心都会部署的App服务器得不到利用。
●App-DB跨广域网
App-DB跨广域网的结构下，在每个数据中心都部署有Web层和App层服务器。
用户的请求发送到就近接入的Web服务器后，Web服务器对请求的内容进行处理，如果发现请求的是静态内容，就从本地直接返回，如果发现请求的是动态内容，则直接转发到本地的App服务器，如果App服务器位于备中心，则通过广域网查询生产中心的DB服务器取得结果。
APP-DB跨广域网的主要优点是备中心的APP服务器都在工作状态。
缺点是数据库的广域网访问可能带来更大的隐患。
在F5公司已经实施的案例中，几种结构都有在实际环境中部署。
具体选择那种部署模式，主要取决于应用的处理流程类型。
但无论采用那种结构，都必将面临到如何提升广域网效率的问题。
如果应用的部署必须采用跨广域网访问的情况下，如何解决问题？
如何减小远程广域网访问带来影响？
采用Web-App跨广域网方式在大多数的情况下为一种折中的方案，也是对现有系统的影响和改造最小的一种方案，
F5提供了三种优化的方案可供选择：
对于Web-App跨广域网的方案，首先可以通过BIG-IPLTM的HTTP压缩功能，对App服务器的返回内容进行压缩，将内容压缩后再通过广域网进行传输。
在通常情况下，压缩比都在1:
5，也就是10K的内容可以压缩到2K左右，减小了4/5的广域网数据传输量。
其次，通过BIG-IPLTM的连接优化功能，可以将Web服务器发送到APP服务器的连接进行聚合，将多个HTTP短连接的请求聚合到少数的TCP长连接中进行传输，减小TCP连接建立和拆断带来的延迟消耗。
另外，对于网上银行的资讯类页面，还可以通过F5WebAccelerator对动态页面进行缓存。
F5WebAccelerator可以在每个数据中心内部署，通过其特有的动态页面缓存功能，可以将资讯类的动态页面进行缓存，在缓存的有效期内，所有对于该动态页面的请求都可以从WebAccelerator直接返回，而不需要到后台服务器经历一次Web-App-DB的查询过程，这样，可以有效的减小广域网延迟的影响，并且减轻了数据库的查询压力。
1.2网上银行应用虚拟化（服务器负载均衡）
当用户的请求通过数据中心虚拟化和链路虚拟化层面之后，就到达了数据中心。
在数据中心内部，实际上也不止一台服务器在为客户提供服务。
这些服务器通过F5BIG-IPLTM整合在一起，形成应用虚拟化结构，使多台服务器同时对外提供服务。
BIG-IPLTM利用虚拟服务（VirtualServer,虚拟服务由IP地址和TCP/UDP应用的端口组成，它是一个组合）来为数据中心内的的一个或多个目标服务器（称为节点：
目标服务器由IP地址和TCP/UDP应用的端口组成，它可以是internet的私网地址）提供服务。
因为BIG-IP专门为此设计，因此，它具备超强的性能，能够为大量的基于TCP/IP的网络应用提供服务器负载均衡服务。
BIG-IPLTM连续地对目标服务器进行L4到L7合理性检查，当用户通过VS请求目标服务器服务时，BIG-IPLTM根椐目标服务器之间性能和网络健康情况，选择性能最佳的服务器响应用户的请求。
如果能够充分利用所有的服务器资源，将所有流量均衡的分配到各个服务器，我们就可以有效地避免“不平衡”现象的发生。
应用虚拟化带来的好处：
●实时监控服务器应用系统的状态，并智能屏蔽故障应用系统
●实现多台服务器的负载均衡，提升系统的可靠性
●可以监控和同步服务器提供的内容，确保客户获取到准确可靠的内容
●提供服务器在线维护和调试的手段
1.3网上银行应用优化
1.3.1网上银行SSL加速
目前，所有的网上银行在交易部分，均采用SSL连接方式，实现端到端的数据加密传输。
在SSL处理过程中，所有的传输内容均采用加密算法处理。
其中最重要的两个部分为SSL握手时交换密钥的非对称加密和数据传输时的对称加密。
在现有的系统中，通常非对称加密采用1024位的密钥进行加解密，因此对服务器的CPU占用率非常高。
在一台新型号的双XeonCPU服务器上，大约每秒钟400次非对称加解密就能导致CPU占用率100%。
同时对称加密通常采用128位，最高256位加密的加解密也会导致服务器CPU占用率居高不下，同样的服务器SSL流量大约能达到150Mbps。
因此当我们在部署SSL应用时，必须考虑到以下参数：
●TPS：
TransectionPerSecond，也就是每秒钟完成的非对称加解密次数
●Bulk：
SSL对称加解密的吞吐能力，通常以Mbps来进行衡量。
当SSL的客户端压力超过400TPS时，单台服务器就很难处理请求了。
因此，必须采用SSL加速设备来进行处理。
BIG-IPLTM系列可从最低2000TPS到200,000TPS实现全硬件处理SSL非对称加密和对称加密流量。
其实现的结构如下：
所有的SSL流量均在BIG-IP上终结，BIG-IP与服务器之间可采用HTTP或者弱加密的SSL进行通讯。
这样，就极大的减小了服务器端对HTTPS处理的压力，可将服务器的处理能力释放出来，更加专注的处理业务逻辑。
在BIG-IP可处理单向SSL连接，双向SSL连接，客户端证书认证等。
并且可同时处理多种类型和多个应用的SSL加解密处理。
由于采用了独立的安全芯片使用硬件加速SSL流量，基本上对于SSL的流量可实现“零”CPU占用率。
1.3.2网上银行Web应用加速
目前基本上所有的网上银行系统都是按照全动态的方式进行编写，后台服务主要以IBMWebSphere和BEAWebLogic为主。
全动态系统带来的优点是反应迅速，在资讯和功能发布后立即得到展现，但存在性能差、对大用户访问量难于应付的缺点。
针对网上银行的应用系统特点，Web应用加速主要从以下几个方面进行：
●动态静态内容分离
在网上银行的业务中，实际上存在有大量的相对静态内容，例如图片、CSS和JavaScript等。
通过WA强大的Policy配置功能，F5可以和网站开发人员一同，设置适当的策略，对相对静态的内容进行分离。
也可以通过WA的IBR智能引擎，对动静内容进行自动分离，将分离后的相对静态内容进行客户端和服务器端Cache处理。
●动态页面压缩
对于网上银行系统来说，所有的交易均通过动态页面进行。
用户的账号、余额以及其他很多信息，都是全动态的内容，对于这些无法进行缓存的内容，WA可以将其进行压缩处理，对服务器的返回内容进行压缩，然后由客户端进行解压缩处理。
这样，就减小了在广域网上的数据传输量。
通常情况下，一个100k的动态页面经过压缩处理后，可以达到20k的压缩后大小。
对于这部分的流量，则可以节省80%的网络带宽占用，同时提高了客户端的页面打开速度。
●静态内容缓存
在进行了动静内容分离后，对于相对静态内容，WA就可以通过IBR技术实现客户端缓存。
客户端缓存的最大优点就是静态内容都保存在客户端，因此对于此部分内容，客户端无需再到网站进行再次请求。
从而减小了网络带宽占用，并且，由于大部分的内容从客户端硬盘直接调入浏览器，大大的加快了客户端的页面访问速度。
同时，WA也可以在自身硬盘上进行内容缓存，减小后台服务器压力。
●动态页面缓存
在网上银行的实际处理中，有大部分的所谓动态页面实际上也是属于相对静态的内容，这些内容的变化通常是根据动态页面的不同查询参数而决定的。
对于同一个动态页面，同样的参数即返回同样的内容。
这些内容最典型的就是在网上银行的资讯类内容。
对于同一个栏目，基本上都是采用同一个动态页面进行呈现，只是通过其中的查询参数不同而显示出不同的页面，比如ContentIdentification功能，可以将这些指定的页面按照其查询参数进行一定时间缓存。
这样，当不同的用户按照同样的查询参数请求动态页面的时候，WA可以直接返回页面内容，而不是将请求转发到后台服务器进行一次完整的数据库查询。
这样，就减小了后台数据库的查询压力，提高系统的整体响应速度。
同时，还可以避免一些动态页面查询攻击给网上银行系统带来的潜在风险。
网上银行的大客户虚拟专线接入
在网上银行的实际业务中，针对大客户服务，通常是有专用的服务器、应用系统和接入方式来保障大客户的银行业务操作。
在传统方式下，这些接入较多采用点到点专线方式进行接入。
即在客户的数据中心到银行的大客户统一接入点直接开通一条专线，使客户端可以直接到达银行内部网络。
这样的优点是稳定、数据传输安全。
但缺点也非常明显，费用比较昂贵，而且维护的费用更加高昂。
F5通过SAM安全接入网关，可以有效的降低这种建设和维护费用。
SAM使用SSL通道技术，在客户端和银行接入端建立一个安全通道，通道的建立基于互联网基础上，但是通过强有力的SSL加密通讯机制，保证了端到端的数据传输安全。
在这个安全通道内，可以运行任何基于IP协议的应用。
同时，SAM还具备客户端SDK开发包，因此在
升级会员 