观点丨​​浅谈银行业中间件发展

Posted 2021-04-10 金融电子化

欢迎金融科技工作者积极投稿！

各抒己见！

投稿邮箱： 

[e-mail]

                                 ——金融电子化

文 / 上海浦东发展银行信息科技部    赵烨婷 蒋瑶瑶

随着银行业务发展以及云计算、大数据、移动互联等新一代IT技术的兴起，中间件产品也在不断演化。它能够为企业级的分布式应用提供标准的平台，使得应用软件开发和运行可以独立于特定的计算机硬件和操作系统场景；同时中间件通过其标准接口和协议，可以实现不同操作系统平台上的数据共享和应用交互，从而为企业应用系统的集成提供助力。中间件从80年代兴起的“CORBA中间件”到90年代出现的“J2EE中间件”发展至第三代“SOA中间件”，再到服务平台，成为了基础软硬件设施中必不可少的组成部分。

中间件在银行业务的发展历程

1.中间业务及交易中间件。银行发展初期主要以对公业务为主，在资金的使用和管理上，银行主要承担出纳角色，逻辑相对简单，但随着对标国际化金融、储蓄、外汇、托管等业务加入，银行不断创新金融产品，客户数和业务量不断增加。由于传统IBM主机处理价格高昂，技术转型从单机逐渐发展为网络分布式处理的C/S结构，让客户端分担中心服务端的工作量。在引进交易中间件前，开发应用程序经常需要重复编写应用功能模块，不仅导致编程工作量增加，难以维护。同时，在金融领域的关键系统中，对效率、可靠性有着严格要求，在核心网络铺设过程中，需要消息交换的通讯枢纽，支持大量客户端的连接和高并发度的交易处理；在平台运行上，应用程序需使用服务器的各种资源（CPU、内存、文件系统等）有效实现并发操作和多台主机资源的性能叠加。

历史上第一代中间件产品Tuxedo为分布式操作扩展提供了联机事务处理（OLTP）操作的事务的管理功能。客户端一般通过结构化查询语言调用，或其他类型的请求，产生对server的请求。这一阶段的银行应用开发采用嵌入SQL的标准C语言，数据库采用Informix，中间件构筑于Tuxedo之上。

Tuxedo应用特性如下：基于Server编写服务端应用，基于Client编写调用Server端服务；Client和Server之间支持多种类型请求的调度；动态调度系统资源，通过tmadmin监视各类资源，通过tmconfig动态调整配置文件参数；通过优先级和负载均衡完成多个服务器之间的平衡调度；在客户端及服务端之间提供同步和异步操作，保障安全传输。

Tuxedo保证了数据准确可靠的传送和事务的完整性，对大规模并发处理能够及时响应，在实际应用中系统稳定。交易中间件是历史最长、最成熟的中间件，至今仍广泛用于银行核心系统。

在中间件领域起步阶段贴合Tuxedo迅速发展的90年代，东方通科技在1993年推出第一个产品TongLNK/Q，虽然起步时间并不比国外晚，但该阶段消息中间件还在发展期，仍未大量推广。

2.中间件蓬勃发展周期。面向服务的互联网应用Web Services诞生后，C/S结构慢慢转向B/S模式，典型中间件（Web容器）所遵循的主要规范EJB及J2EE逐渐走向成熟，Java成为主流编程语言，JVM作为Java应用程序的基石，提供了如多线程、安全、内存管理等功能，应用服务器进入了蓬勃发展的阶段。开源领域也逐渐兴起，由于接口发展成熟，提供此类产品的厂商众多，竞争十分激烈。同时，由于应用服务器本质继承了交易中间件和消息中间件的功能特性，大量系统采用B/S结构及非传统编程语言进行开发后，Web应用服务器逐渐蚕食交易中间件及消息中间件地位。无论是开源MQ还是国产TongLINK/Q等消息中间件的应用场景都较少，消息中间件的关键业务转向了与外部机构之间的信息通道及内部机构的少量通信需求。

依赖于银行硬件负载均衡设施分发，此阶段银行开发的面向业务的管理类应用系统均采用应用服务器为主的中间件。对于银行中间件应用来说，Web容器、EJB容器的生命周期管理功能在大部分产品能够满足的情况下，可维护性、BUG修复能力是首要考虑因素。因此在2000~2015年期间，Oracle及IBM的产品依靠其自身领先水平成为大型银行的主要选择，而国内从2015年起基础设施厂商迅速成长，应用服务器产品与国外厂商之间的差距逐渐收小，目前也已进入成熟周期。

3.大批量应用统一部署。随Web应用复杂化，依赖于应用交互关系，逐渐衍生大批量部署需求。在大批量部署模式下，应用需满足快速迭代及快速部署的要求，对于中间件必须满足如下特性。

部署的可扩展性：在部署和应用扩展过程中，可以通过接口动态添加Server，降低停机窗口及重启系统。大规模集群集中部署：单个Server更新或配置对用户不产生任何影响，实现无缝升级或迁移。银行多套开发测试环境的部署需求，对于新建环境，可以通过定制化策略快速交付业务测试。

基于上述要求，Web中间件必须支持统一的部署及更新接口，满足复杂应用的批量实现方案。一般情况下，建议采用管理节点作为统一入口，实现通用的RPC/Restful接口调用，并衍生实现相关的监控方案。

应用调研参数：包含业务名称、JDK版本及JVM参数、应用安装路径、管理域主机、受管服务、数据库驱动、连接池信息。

拆分中间件properties特性，基于Windows或Linux部署脚本定制cmd/bash脚本，满足Web及应用安装。

通过Python脚本调用properties参数，调用中间件自有restful接口实现批量及独立配置，针对复杂JVM、数据库配置参数，实现一键生成及扩展应用能力。

中间件发展现状

1.中间件选择困境。近十年来，互联网技术创新运用于金融领域，带动了传统金融服务体验和运营模式的巨大变革。随着金融发展趋势，对公业务基本饱和带来的对公资产萎缩；个人消费金融每年持续高速增长带来的零售业务高速发展已经是必然趋势。银行信息系统需要支撑更加差异化、综合化的产品和服务，典型中间件层在大规模系统之间调用过程中开始逐渐弱化。中间件发展之初，其本身的技术目的在于用自身的复杂换取应用开发的简单，但由于自身技术本身已经有过于复杂和通用的倾向，原本提供便利的中间件产品逐渐被其他技术复杂化。如何使中间件技术能够更加简便、明了地满足应用和开发的需要成为了新的问题。

依靠RPC相关的服务治理中间件，相关应用系统可以做到限流熔断，链路追踪，分布式配置中心等。基础中间件平台架构如ESB、统一门户等成为了基础应用构件平台，以贴近银行形成了应用支撑平台，使应用只需面对一个可以解决的软件平台，而非一大堆中间件产品。依赖业务解耦、大量数据生成、高TPS场景下的异步处理问题等等，消息中间件、缓存中间件在这两年的银行开发中逐步取得更多地位，除拥抱开源社区之外，银行不仅需要社区开发友好的开源产品，更要面对复杂的市场化选择标准的统一。

2.中间件赋能场景。随业务产品竞争激化，技术发展推陈出新，为了给客户提供更好的体验和服务，银行必然要不断更新计算机技术和业务系统。同时，为了应对互联网态势下的高并发场景，新的业务需求不断迭代，分布式应用迅速发展，银行基础设施正在面临越来越复杂的场景。不同的硬件平台下，网络通讯L2/L3跨异地中心访问，私有云建设下计算、网络、存储资源的池化，繁杂的网络程序设计和管理，数据分散处理，这些与业务功能没有直接关系，对于系统开发者而言往往难以触摸，仅仅通过更高性能的设备、更新的应用软件技术也依然无法避免这一问题。

在单一或基础应用系统已经逐渐成熟的领域，新的应用热点是对应用系统的整合，进而实现决策分析系统、增值业务系统等新建项目，使企业能够进一步挖掘信息和对外提供多元化的服务。而国外及互联网公司已经倾向于依赖一个新的中台实现这一目的。基于中台系统，依然需要解决的根本问题仍然包括操作系统之上的兼容性，开发标准接口及系统标准接口，高并发、高效的处理能力，负载平衡、故障恢复能力，为分布式数据提供解决方案，并为业务提供安全可靠的监控方案。

总    结

在中间件30年的发展周期中，中间件的目的始终是将不同时期、不同操作系统上开发的应用软件集成起来，形成一个天衣无缝的整体，这是单应用、操作系统、数据库目前尚未做到的，中间件的RPC、restful接口还可以实现附加的运维价值。基于新兴领域的发展趋势，在分布式服务框架、分布式数据库中间件、分布式消息服务、开放缓存服务、分布式数据库等基础上进行建设，对多数银行现有的科技团队而言仍然是不熟悉的，在当前阶段，需要多样发展的技术与合作。

新一代中间件技术需要继续对这些共性问题进行提炼，在数据中心、操作系统等异构平台之上形成一个可复用的部分，满足迅速增长的业务需求。面对人力资源尚存在瓶颈的阶段，单点突破、逐步完善更适用于银行的现状，从开发效率入手，是云原生的微服务+DevOps体系优化和典型中间件的结合；从基础设施运营能力入手，统一私有云平台和基于云化服务的PaaS平台建设，并结合开发及业务发展的角度，通过中间件为银行带来可靠的服务能力。

往期精选：

（点击查看精彩内容）

关于仿冒我刊收费的声明

我刊自创刊以来，从未向投稿人收取过任何费用。任何以刊发文章为名向投稿人收取费用的行为，均属于对投稿人的欺诈行为。

我刊投稿邮箱为 [e-mail]。

《金融电子化》新媒体部：主任 / 邝源  编辑 / 潘婧 傅甜甜