【IT168 报道】
【聆听IT专家讲座，了解如何驾驭IT风险，更有机会获得限量蓝牙耳机！】
根据《2006-2007年中国网上银行发展研究年度报告》显示，2006年，我国网上银行（以下简称为“网银”）发展迅速，网银的交易额和交易笔数大幅增长，企业网银仍然占据市场主体，但个人网银市场潜力巨大。
2005年企业网银的交易额占了总交易额的96.7%，达70.2万亿元，较2004年增长21.3万亿元。
2005年中国个人网银发展非常迅速，尤其是招商银行、工商银行和农业银行个人用户增长率都超过50%。个人网上银行市场规模增长速度很快，增长率已达到300％。个人网银用户增长速度更快，截至到2005年底个人网银用户已达3460万户，较2004年增长103.5%，占互联网用户的38.7%，交易额也从2004年6000亿元增长到2.4万亿，增长率在300％。未来四年内，企业网银市场将呈平稳增长态势，而个人网银市场将继续快速增长，在2007年－2008年之间，市场交易额将接近成倍地增长，之后有所平缓，到2010年个人网银交易额预计有望超30万亿。
网银面临的挑战与要求
网银的迅速发展必然给其带来新一轮的挑战：
• 网银的用户数、交易量快速增长
• 网银的用户随时随地访问
• 网银用户访问模式的不确定性
• 新的业务渠道及模式导致业务需求的持续变化
• 层出不穷的安全攻击
网银应用，从物理上，看是涵盖多个系统多台物理服务器的应用；逻辑上看，是包含多个应用逻辑部件的应用系统——不论从业务逻辑还是数据传输，应用都跨越多个资源环境
大多数网银应用为前端用户提供复杂的业务系统（当前的趋势是越来越多的使用B/S架构的WEB应用），应用中的通用部件又可能被不同应用系统以各种形态相互互连或重用，单个用户请求可能贯穿甚至多次贯穿系统，业务请求对应的返回数据可能来源于多个子系统。前端赏心悦目的应用界面隐蔽了应用后端的这种复杂构架，但是不论后端的子系统发生何种异常——不论来自业务请求的异常、系统资源的异常还是应用内部逻辑和代码的异常——用户都无法完整发出的交易请求，因此，保持网银应用系统的高可用性，并在此基础上提高网银应用系统的性能，是IT业务支撑系统（系统维护部门、应用维护部门、应用开发部门、网络维护部门等）的关键任务。
正是由于网银应用系统的“复合”特性（业务逻辑和数据传输跨越多个资源环境），从优化其性能和可用性角度来看，它难以设计、难以构架、难以测试、难以管理；传统分立的块状系统管理工具和方法论也很难很好的对它进行管理和优化。
可以说，新的网银应用模式，对传统的系统/应用管理维护模式提出了新的要求。
网银系统现已经成为用户重要的交易渠道，是一个7x24小时面向用户的窗口，网银系统对提高用户满意度起着重要的作用。网银系统提供的交易功能在近几年内已经逐步完善，用户已经越来越多地使用网银进行交易。因此，确保网银系统交易的稳定可靠、高交易成功率和高峰访问条件下的高性能是行内现阶段需要考虑的重点，因此对网银的要求集中体现在以下几点：
• 完善、灵活的应用、系统架构
• 系统的高可用性，支持7x24小时
• 系统的高性能和高可扩展性
• 系统的容错性和强壮性
• 应用架构支持快速开发
• 抵御各种安全攻击
• 完善、全面的系统及应用测试
网银应用管理的现状
首先网银系统可分为对内网银和对外网银两个大的组成部分，对外网银采用B/S体系结构，对内网银主要采用C/S与B/S混合的架构体系，这里我们主要研讨用户量比较大，直接面对客户的对外网银。
对外网银其基本架构如图二所示：用户通过浏览器访问对外网银，由负载均衡器将用户的访问平均分摊到Web服务器组，由Web应用服务器组(包括Apache等)处理用户交易，使用应用服务器组（包括WebSphere, WebLogic等）的Cluster机制实现容错和负载均衡。用户交易通过中间件（包括MQ, CICS, Tuxedo等）访问后台的数据库（包括DB2,Oracle等）甚至主机(OS390)。
对外网银应用运行在应用服务器上。对于采用这种架构的应用，可以使用Cluster技术保证不存在单点故障，但由于交易的路径是随机的，因此，当出现部分交易出现性能问题时确定性能瓶颈是比较困难的。
除此之外，根据综合分析对外网银应用的特点，总结以下几点目前网银应用管理能力上的不足：
A: 交易整体响应时间监控缺乏
对于网银应用系统运行维护部门，目前缺乏手段了解网银交易系统的整体响应时间。部门只有获悉客户投诉后才能了解交易整体响应时间无法满足客户的期望。网络浏览中存在的8秒原则到目前为止并没有被找破，这就是如果网页不能在8秒钟之内被打开，浏览者就会对你的网站失去兴趣，转而去浏览其他网站。用户对于交易的容忍程度需要遵循8秒原则。但所有交易的时间是否都能够在8秒内处理完成？交易的成功率是多少？不同城市的用户对于网站的访问速度是否存在差异？差异是多少？这种差异是否会影响用户满意度？对于业务部门来说，获得上述问题的答案对于评估网银系统十分关键。
B: 应用服务器交易响应时间监控缺乏
应用服务器(包括WebSphere、WebLogic等)在目前的网银系统中启着越来越重要的作用，核心的应用都运行在应用服务器上，因此了解应用服务器的运行状态，性能信息及运行在应用服务器上的交易响应时间显得格外重要，但是目前没有非常适合的工具获取以上信息。这样，系统维护人员至多只能使用一些监控工具确保应用服务器在运行，而无法了解应用服务器的性能信息及交易的响应时间是否正常，只能被动地等待客服人员收到客户的投诉后才能诊断问题原因。这样会影响客户的满意度。
一般的资源监控工具只能够了解资源的运行性能，如：CPU利用率，JVM利用率等，无法了解交易的性能。往往出现资源性能正常而交易异常缓慢的现象。解决问题时需要采用手工进行交易的方式主观了解交易的性能，这种手工了解交易性能的方式没有统一标准，完全取决于操作员的主观感受，无法量化。
如果能够有手段获得应用服务器上的交易响应时间列表，尤其是了解交易的分段性能，然后对最慢的交易进行优化，就可以主动优化交易性能，提高用户的满意度。目前的管理系统缺乏这种监控能力。
交易性能的分析不能只是简单获得交易整体响应时间，即将请求送入交易系统到交易系统返回结果的时间。交易整体响应时间是业务部门关心的指标，这个指标不能够帮助技术部门在出现性能异常时确定性能瓶颈。交易分解是指把交易分解为子交易，从而获取交易的分段性能。这种技术对于确定性能瓶颈非常重要。对于基于J2EE的网银应用，交易分解应能够分解到方法一级的性能。目前的管理网银系统缺乏这种交易分解能力。
C: 应用系统级问题管理手段缺乏
现阶段对于网银系统缺乏有效的应用系统级问题管理能力。例如：网银应用的某些模块可能存在内存溢出的问题。内存溢出是一个普遍而又难以解决的问题，现在的解决方法是逐行分析应用代码，费时费力。有时分析代码也无法确定问题，如大对象调用问题，代码逻辑并没有错误，寻找原因往往需要提供应用服务器公司专家的帮助，也要花很长时间。
寻找内存溢出的另一个困难是诊断工具主要针对测试环境，部分故障只在复杂的生产环境中出现，而测试系统中无法重现。
除了内存溢出问题以外，网银应用维护人员没有手段了解系统中被挂起的交易，大量的挂起交易对交易系统的性能会产生严重影响。
D: 缺乏网银系统应用的深层次监控管理
传统的网银监控管理解决方案基于能够对服务器的系统资源进行监控，如：CPU利用率，内存利用率，文件系统状态等。另外，针对应用服务器的监控模块也只能监控应用服务器的资源状态。对网银应用的交易性能和交易拓扑无法实现监控。
这种基于资源监控的产品对于诊断交易的实时性能、交易系统的当前状态、交易系统的瓶颈点，交易的性能排名和代码缺陷均没有帮助。往往出现系统资源正常而交易系统异常缓慢的情况。
网银系统的特点具有典型的特征，网银系统底层的基础架构本身不具备监控的接口，目前几乎没有工具能够分解交易的分段性能。造成现阶段只能被动地等待问题出现，而不能主动优化系统性能而提高用户的满意度。网银系统需要一种能够像主机一样能够分解交易到方法一级的性能分析工具，才能够主动优化系统性能。
IBM Tivoli网银系统应用监控管理解决方案
网银应用环境的应用特性和监控管理要求网银系统以往按照分块资源进行系统资源的监控管理难以满足网银应用的复杂管理，网银应用管理需要整体性的方式。
首先，从网银应用监控管理角度，应用交易性能的整体性能需要被获取并呈现——
用户是否能够访问目标应用？
用户访问应用的响应性能如何？
整个交易流程中的哪一个子交易/子过程发生了可用性/性能异常？
同时，当确定的问题被隔离/定位/后，开发测试人员对该问题进行深入分析——
有针对性的在开发环境测试环境重现问题。
对发生问题时记录的上下文信息从应用开发角度进行分析。
打通生产和开发测试环节，并用通用的工具评估应用性能。
最后，从应用监控管理获得关于应用的数据并对业务过程提供总体性数据支持——
更好的制定服务水平管理标准/要求。
真正的业务影响视图。
定量的评估业务过程的合理性并评估期实现方面的合理性。
上述三个方面/阶段以前一个为基础，大多数环境下的构建和其它系统管理系统一样，遵循迭代的过程。
网银应用监控管理的需求
对于大部分关键应用系统，当前已经部署了系统和资源层面的监控系统，然而正如前面提到的网银应用的各种特性，单靠系统管理工具，难以实现高效和完整的应用监控。
交易监控与资源监控的差别
传统的系统监控对系统级别和应用级别提供了资源角度的监控能力，如内存、CPU、线程池总体利用等等。而从过去交易系统遇到的异常故障以及解决方式来看，大多数问题为应用系统内部的交易性能问题和交易可用性问题，突出表现为交易长时间无法提交，交易失败，交易占用过多系统资源等等。
交易监控的目标
由于传统监控从资源角度进行，难以快速有效的判定并定位应用系统存在的问题。应用系统的特殊性要求采用有针对性的、区别于传统资源监控实现方式的监控工具来监控，从而实现：
当交易异常发生时主动报警——通过交易监控系统主动报警的机制来提高系统运维部门工作的主动性，并大大减轻来自一线的压力；
尽可能提供对各级支撑系统（一线系统运维人员、二线应用部署维护人员、三线应用开发测试人员）有价值的诊断信息——通过交易监控系统提供的诊断信息帮助应用部署/应用配置人员以及应用开发/应用测试人员快速定位存在问题的区域并帮助前段应用支持人员做出及时响应。
网银应用监控的总体技术构架
本人认为监控管理网银应用需要包含三个层次的功能：
1、 资源监控。资源监控是一个监控系统比较容易实现的，各个管理软件供应商均能够提供此类软件。资源监控能够实现对操作系统、数据库、中间件、Web应用服务器的资源运行效率进行监控，从而了解资源的使用状况。资源监控无法真正地反映交易系统的运行状况，只能够反映支持交易系统的IT环境的运行状况。只有资源监控软件是不够的。
2、 Web交易的实时性能监控。Web交易的实时性能监控能够了解交易系统的当前性能，真实地反映交易系统的情况，从而实现对应用的监控。通过对交易的分解，能够初步确定性能的瓶颈点。从而减少性能故障的诊断时间。另外，通过仿真交易，性能监控系统能够主动探测交易系统的性能问题。
3、 深层次J2EE应用诊断工具。在Web交易实时性能监控确定大致的性能瓶颈点后，需要一种能够适合于生产系统使用的J2EE诊断工具来诊断产生性能问题的代码，从而进一步缩短故障诊断时间。
这三个层次的监控是相辅相成的，可以构成一个完整的网银应用监控系统。
笔者经过分析看到，需要通过一系列的监控管理软件实现这一系统。首先通过IBM Tivoli Monitoring (以下简称为ITM)和IBM Tivoli Composite Application Manager（以下简称为ITCAM）产品家族的重要成员ITM for OS 和ITM for Databases以及ITCAM for J2EE（ITCAMfJ2EE）和ITCAM for Response Time Tracking（ITCAMfRTT）来构建总体的应用监控体系。
ITM for OS帮助用户实时的监控网银中的操作系统的各项性能信息，如CPU、内存、硬盘及网络等，从资源层面监控网银应用中的服务器运行状况，保证服务器正常运行，资源使用得当，如遇到资源使用超负荷，进行及时的告警通知。
ITM for Databases帮助用户实时的监控管理网银中的数据库的各项性能信息，如表空间、锁信息、日志等，从数据库层面专业的监控管理网银系统中的数据库使用情况及性能信息，保证在数据库层面不会影响整个网银的表现。
ITCAM for Response Time Tracking，简称ITCAMfRTT是一个端到端性能分析软件，可以监控管理整个网银应用的交易响应时间，并且对交易进行分解，分析整个应用的瓶颈点，此软件包含三个组件：STI组件进行仿真交易，该组件主动访问系统获取交易总体响应时间；QoS组件获取Internet访问用户访问网银的真实体验和交易系统的总体响应性能而无需在客户端安装任何代码；J2EE组件分解应用服务器上应用的交易，获取交易的分段性能，确定性能瓶颈。
ITCAM for J2EE，简称ITCAMfJ2EE，帮助用户可视化的监控应用服务器的运行状态，J2EE资源使用情况，确保应用服务器正常运行，资源使用正常，另外在ITCAMfRTT确定性能瓶颈后，ITCAMfJ2EE可以帮助用户深层次分析应用服务器中的代码，追踪到性能问题的源头。
网银应用管理场景
这里我们只是简单描述IBM Tivoli网银系统应用监控管理解决方案中第三层的深层次J2EE应用诊断的两个应用场景，这两个应用场景分别是在运维中心和开发测试中心。完整的三层网银应用监控管理（资源监控、Web交易的实时性能监控、深层次J2EE应用诊断工具）的场景分析我们将在网上银行应用监控管理解决方案(二)中详细描述。
系统运维部门 --- 如何做深层次J2EE应用诊断
对于运维部门来说，首要的目标是把目标应用置于可控状态，因此，可以使用ITCAMfJ2EE报警方面的设定。
中间件资源监控
展现中间件系统资源的使用情况，大大地帮助了中间件运维人员监视资源使用情况，诊断瓶颈。经常我们会关注：数据库连接池，JVM, Web Container/Thread Pool, 等等：
需求：监控特定交易的响应时间，当交易缓慢时给出报警。
解决方案：利用应用程序报警功能，对请求进行筛选，以达到监控特定交易的目的。
历史报告
需求：希望能够对于交易的内存进行分析。
解决方案：在报告中没有对于交易内存状况的分析。可以提供对系统内存状况及交易历史数据的分析，进而间接达到客户需求。
其它可以关心的报表可以包括：“吞吐量”、“响应时间”、“CPU时间”、“优异吞吐量”、“优异响应时间”、“优异CPU时间”、“JDBC池”、“活动会话数”、“可用内存”、“服务器可用性”等，这些报表都可以方便的被导出成CVS或PDF格式，并通过自动化方式生成更具有可读性的报表文件。
