Java在银行业的应用

 因特网上应用的日益普及与深化，为Java技术的运用提供了广阔的活动舞台，也大大推进了Browser/Server模式的企业内联网应用与网络计算。

    作为某信息公司中的技术骨干，我有幸承担了某银行信贷管理与查询系统等的开发任务，独立地完成了其中的系统设计、类设计、部分开发及测试工作。

    整个系统完全按照J2EE的标准来设计。前台界面应用了JSP技术，控制部分采用了Servlet来开发，业务逻辑应用了EJB技术来封装，应用服务器采用了支持J2EE标准的BEA公司的Weblogic，后台的数据库选用的是Informix7.3，目的是为了与银行中其他业务系统数据库保持一致。在硬件平台上，我们选用的是HP公司的某台中型服务器机器，操作系统是HP-UX。

    该系统界面运用的是IE，它不仅兼容性较好，而且已为广大用户所熟悉。系统运行后，各个支行都普遍反映界面友善，功能强大，开发的效果令人满意。

【正文】

    在银行应用中私人的储蓄、企业的会计、国际的业务、信贷、财务管理都是十分重要的，它们构成银行的基础业务系统。我从事开发的信贷业务更是银行利润来源的重要部分。与储蓄，对公等以交易事务为主的业务模式有所不同的是，尽管信贷也是交易，但需要更多其他辅助信息的支持。如客户的基本资料，在本行内业务发生状况、信用等级、是否有逾期贷款未能归还等。各个支行的有关业务人员及分行管理人员都希望能方便及时地了解这些信息。传统的基于终端的用户界面难以传递这么多信息给用户，所以我们决定采用基于测览器IE的用户界面，一方面IE使用方便，不需要专门培训，另外它是与Windows操作系统捆绑在一起的，也可节省前台费用。在开发技术上有ASP，JSP可供选择。

    由于考虑到Java技术在Internet上的迅速发展，J2EE更是提出了全新的用语言来统一平台的思路，于是我们决定采纳J2EE标准，并选用了JSP。在设计上，基本上是采用了一个交易画面对应于一个JSP程序，充分发挥JSP动态处理页面的长处。

    为了使设计有更好的可扩性、灵活性与逻辑性，能为以后扩展奠定坚实的基础，我采用了（Modelu，View，Controller）的MVC设计模式，View全部由JSP实现，而Controller则是设计了一个Servlet程序，它负责处理前台浏览器传送来的所有请求，并按事先定义好的路径/程序关系，分发给相应的JSP程序去处理。由于Servlet本来就是为Java服务器端编程来设计的，因此由它来负责服务器端的处理是相当合适的。

    在开始设计时，我运用了构件技术，由EJB承担起设计模式的Modelu角色。具体的贷款开户，放款，结息逾期贷款，归还贷款等交易都对应一个具体的EJB。为了将这些处理逻辑与相应的数据库操作分离开，能更加便于维护，我将处理业务的EJB设计成Session Bean，而为每个Session Bean再配备一个相对应的Entity Bean，用于访问后台的数据库。贷款管理中有很重要的一点是进行查询，我按照需求分析的结果，为每类查询都设计了相对应的Bean，其目标是尽可能地提高查询的速度。

    在对数据库的存取中，我本来的设计应用Informix JDBC所带的Driver Manager，这样，在存取数据库中的Bean中就要把Driver及Server写入，后来考虑到应尽量提高应用的平台独立性，在参阅了J2EE中JDBC部分的说明后，改用了Data Resource的处理方法，这样，即使以后数据库换成Oracle或其他产品，程序也不用修改，只需要在配置时进行变动即可。

    在这次信贷管理系统的开发过程中，Java的平台无关性优势，在开发人员从事开发的活动中体现得淋漓尽致。由于经费相对紧缺，我们的开发环境是各个项目组共用一台HP机器，虽然每个开发小组都搭建了自己的环境，但项目一多，特别是遇上结息与批量测试等场合，机器就显得不堪重负，使开发与测试工作的效率大为下降。我们小组由于采用的是Java技术，大家可以在自己的NT机器上搭建相同的环境。这样一来，大家平时的开发工作，包括JSP，Servlet，EJB的程序，都可以在本地完成，只是到测试或展现阶段才需放到HP开发机器上进行。

    以前我们开发的Web应用，往往只是应用了部分的Web技术，如采用Apache Web Server、ASP开发语言等。整个体系的集成与组合往往不够理想，这次由于我们采用的一整套符合J2EE标准的组件，整个系统的协同性与一致性非常之好。再加上有一个支持J2EE的应用服务器——BEA Weblogic，以往我们做得不理想的复杂配置，模块间的连结，如今都用不到再操心了，只需在图形化的配置工具中，输入系统所需要的配置，如路径与实际应用程序的关系，组件中的EJB引用，Data Resource的属性等；全部配置完成后，Weblogic会替我们完成项目的部署，并将这一切有关的程序都封装起来。

    原来，我们开发小组的文档编制任务显得非常之繁重，因为整个系统既有交易部分，又有管理查询部分，交易、数据与源程序都很多。为了解决这个问题，我们直接应用了Java源程序中的Javadoc导出文档，这样不仅文档美观，而且能够保持与源程序的一致性，实乃一石二鸟之举。

    整个项目完成后，用户使用下来都觉得界面友好，操作简便。但是我心里知道．这个系统还有很多可以加以改进的地方。

    首先，基于Java系统的开发需要资金较多的投入，由于该系统受到经费的限制，只申请到一台生产用机，这样，Web Server、Application Server、DB Server只能被挤放在一起。虽然Weblogic能实现部分负载平衡，但在将来的业务发展时，这样的分布肯定不是最理想的。好在我们在设计时已经考虑过尽量有良好的扩展性，在以后条件许可时，只需进行在不同机器之间的进一步部署即可，应用程序大体上无需改动。

    其次，在设计上，可以采用UML的产品，如Rational Rose，另一方面，Rational Rose具有自动代码生成功能，也可以大大节省开发的成本。

    最后，目前的信贷管理系统相对用户数目量不多，当推广类似系统需要拥有大批用户时，基于Java的系统的响应时间与系统分布都会有较为突出的矛盾出现。

    以上这些，都是我在今后的系统设计与开发中需要加以注意的地方，也是运用Java技术应当努力的方向。（本文主要参考了上海戴黎平等人的论文）
评注：讨论具体，应用较为深入，表达清晰。存在的问题属实。

系分论文8

论改进Web服务器性能的有关技术——论文1：银行业的应用

【摘要】

    基于Web技术的数据库应用是当前应用的一个热点，在用户数目与通信负荷很大的场合，提高Web服务器性能是一个迫切的课题。本文从笔者参与某个银行系统项目开发的经历出发，阐述了提高Web服务器的性能应渗入到项目论证、选型、开发、运行和管理的各个环节，只有各个环节都能充分考虑到性能与质量的需要，系统的性能才是真正可保证的和可扩充的。

    文章从系统的实际运行与相应的经验出发，阐述了性能改进方面的一些具体措施。
比如：在本文中讨论了Web服务器平台的选型考虑；Web服务器的配置管理；应用系统本身的优化与预先设计系统时可扩性的性能保障等具体内容。

    通过技术上的分析与改进，综合性地运用多类措施与手段，在实际系统中，Web服务器运行的性能得到了一定程度的保证。

【正文】

    我所在的单位是把目标定位于金融领域开发IT应用的一家信息技术公司。随着金融电子化建设的发展和商业银行之间市场竞争的加剧，各主要商业银行不断通过信息技术提供新的金融产品，并且希望能整合市场渠道。比如主要的商业银行不断推出形形色色的网上银行服务。在这种背景下，本人参与了开发新一代网上银行产品，涉及到提供网上个人理财服务、网上外汇买卖服务、网上企业服务等具有市场竞争力的产品。作为项目开发的组织者之一和主要的技术骨干，在整个项目开发过程中始终要处于第一线，从而在改进Web服务器性能、提高整个网上平台系统性能方面收获良多，在本文中简要讨论如下，希望与读者们共享经验。在Web服务器配置与优化方面，我有如下几方面主要的体会：

    第一方面是Web服务器选型考虑。

    在Web服务器选型及网上平台搭建之初，我们就已充分考虑整个网上平台的性能及可扩展性问题。这一考虑为该系统的稳定性及扩展性能力方面打下了坚实的基础。

    某银行原有的一些网上产品由于开发较早，故而采用的是老式的HTTP Server+CGI程序调用的方式。这时，每一客户请求需要对应于后端系统的系统进程来运行CGI程序来处理，系统的开销相当大，系统的扩展能力也很差，性能已不能满足业务处理的需要，故而在为此银行系统具体选型的时候，我们一开始就否决了这种方案。

    通过市场上同类产品的比较选择，我们选择了国际商业机器有限公司IBM的Web Sphere产品系列作为该行网上银行系统的建立平台。作出这样选择是因为Web Sphere基于使HTTP Server和应用服务器相分离的整体架构，同时支持JSP、Servlet和企业组Java Bean等轻量级线程规范，所有的请求对应于应用服务器上的处理线程，系统的开销低、效率非常高，同时Web Sphere整个体系结构相当的灵活，为适应扩展需要可以作不同的横向和纵向扩展，从而可以满足各银行未来的扩展需要。

    正是因为在一开始选型的时候我们就已考虑到未来的扩展需要，整个系统在接下来的几次性能改进方面，我们大体上都能相对顺利地达到了预期目标。

    第二方面是Web服务器的性能配置。

    在一开始系统上线的时候，由于系统的负荷不是很大，为了节省系统总拥有成本TCO投资，我们在一台较低配置的IBM RS6000上投产了该系统。整个系统的HTTP服务器、应用服务器、通信服务器等均位于该台机器上，由于初始投产时用户不多，所以系统的性能基本上能令人接受。

    但随着业务的发展和用户访问量的增大，我们发现该服务器的响应变慢，系统的CPU利用率和内外存交换显著增大。经过跟踪，我们发现关键原因之一是系统的内存不足的缘故。由于网上服务器把大量用户的会话信息保存在内存中供给应用系统使用，当内存不足时，大量Session信息被迫交换至硬盘，大量CPU时间消耗在等候内外存的交换上，系统效率迅速下降。

    鉴于这种情况，我们把该服务器的内存由2GB扩充为4GB，同时相应调整用户会话信息的保存时间，这样整个系统的效率又回到较为理想的状况。

    由于新应用的不断投产及数据库操作的日益增加，我们后来逐渐监控到系统的数据库处于繁忙状态，系统的错误日志也记录下了供应用服务器使用的数据库连接处出现资源不足的情况。在这种背景下，我们认为整个系统由于硬件配置所限，应该进行横向扩展，因此我们把数据库服务器分离出来，配置到另一较高性能的服务器上，相应定义的数据库资源也大幅增加，这样整个系统的性能又处于较为理想的状况。

    第三方面是对应用系统进行相应的优化以提高性能。

    Web服务器配置及相应的硬件扩展不失为解决系统性能问题的一条捷径，但应用系统的优化也是应该重点加以考虑的，毕竟它能够在投入较少的情况下提高系统的运用效率。

    在开发的初期，我们就已经十分注意系统的利用效率，比如提醒程序员尽量不要利用用户会话信息(Session）来传递大的对象，对于内存要注意回收等。同时，通过内部的交流会推广与介绍一些小的、有用的编程技巧来提高开发人员的水平，通过代码的抽查，希望能在早期就发现问题等。

    在系统运行期间，我们通过监控发现，应用服务器所基于的Java虚拟机，其内存堆的空闲空间有不断下降的趋势，每隔若干天导致空间消耗殆尽、无法分配新对象空间，从而导致系统重启。在排除了系统本身问题的原因外，我们确定为应用系统的开发有问题。通过从网上万载IBM公司检测Java虚拟机的相关工具对JVM进行监控后终于发现系统内部存在着不能回收内存的对象，再通过查找相应的程序发现在该程序中有“环状”的对象引用，从而导致对象使用后不能被垃圾收集器所回收。这个问题的解决过程虽然十分艰苦，但由于该问题不能通过升级硬件或增加资源配置而得到根本解决，会给系统带来很大的隐患。所以，整个过程的分析与解决是完全值得的，更何况通过查找故障原因的过程，给整个项目组上了生动的一堂软件质量保证课，对项目组的质量意识起了很大的促进作用。

    所以说改进Web服务器的性能井不单纯是系统管理方面的工作，它渗透到开发以及
系统运行等一系列环节中。

    第四方面预先考虑未来的扩展与性能需要。

    随着系统的发展及成熟，考虑到用户访问量的不断上升，为了预留系统的发展空间，我们最近又对整个系统作了一个系统性的升级。通过引入多台HTTP服务器及应用服务器并行工作提高整个系统吞吐量及单点故障克服能力。由于在一开始选型的时候就已经充分考虑到动态负载均衡及横向扩展方面的需要，这一项的升级无需对整个系统的体系结构作根本的变革，对应用程序来说，更是没有造成任何影响。

    整个项目历时近两年，从这两年的系统情况来看，整个系统是成功的。根据我亲身的经历，系统性能并不单纯是系统运行与管理阶段的问题，而是渗透在项目论证、开发以及运行的各个阶段。只有在各个阶段都能充分考虑性能方面的需要，在实际运行时，整个系统的性能才可能真正有保障。在技术方面来看，可以综合利用选型评估、硬件扩展、应用优化和系统配置优化等一系列的手段；比如在硬件扩展方面，又可以分为主要部件扩容，纵向升级、横向升级等方面。在我们的项目实践中，曾综合地利用了上述的各种手段。比如某银行的整个系统从日访问量不足1万至现在的每日超过I0万次以上的点击的发展情况来看，整个系统的性能保障及提高方案是比较成功的。

    评注：实践过程较有说服力。条理与思路相当清晰，技术措施与管理措施的推进也很明确。所论述的技术还有一些局限，不够开阔。