|银行烟囱式系统难题,如何通过应用集成方式来解决?( 二 )


这就是我们经常说的牵一发而动全身 , 也是我们所“深恶痛绝”的网状型架构的由来 。
2)轮状型架构
由于网状型架构存在诸多弊端 , 为了更有效地利用现有的信息系统和资源 , 使人、财、物等资源在企业内部共享 , 银行IT建设开始注重系统的内部建设 , 如统一编码标准、命名标准、元数据定义 。
因此 , 演化出了轮状型的应用集成架构模式 , 也可称为''集中式'' 。
集中式典型的做法是将主要业务处理的综合业务系统作为中心节点 , 系统只需要与中心相连 , 便可实现彼此间的交互 。 其他节点作为综合业务系统的外挂系统 。
|银行烟囱式系统难题,如何通过应用集成方式来解决?
本文插图

即Hub模式 , 使得系统间连接数量大幅减少 , 而且很容易实现应用之间的整合 , 便于管理大量的连接和系统 。
Hub 模式:是将所有的运输量集中到一个中心节点 , 然后再向各节点发运的网络模式 。
不过 , 基于中心模式的集成架构 , 缺点也很明显 。 由于中间节点既要处理大量的银行业务 , 又要承担应用之间的交互 , 具有较大性能瓶颈 。 尽管国内少数银行仍然采用此种类型的架构 , 但已经落伍了 。
3)总线型架构
随着SOA的兴起 , 出现了总线型架构 , 它是目前国内银行中使用最多、最广泛的一种应用集成架构模式 。
在总线型架构中 , 银行的主要应用都通过总线连接和交互 , 总线不处理或很少处理银行业务逻辑 , 它主要负责应用之间的互联互通等功能 , 即中介代理 。
换句话说 , 总线型架构就是在渠道系统与核心、及外围系统间建立一座桥梁 。 各系统的接口都注册发布到ESB总线上 , 由总线发布统一的、标准的接口 , 不同应用只需要按照总线的规范与总线进行互联 。
|银行烟囱式系统难题,如何通过应用集成方式来解决?
本文插图

因此对服务使用者而言 , 无需关心服务提供者是基于什么开发技术或平台提供的服务 , 不仅避免了因服务提供者接口的变化而需要同步修改此服务调用者的资源 , 而且也降低了系统间耦合 , 更方便、高效地实现了对新系统的集成 , 为服务负载均衡、服务管控提供了更专业的能力 。
从而简化了银行信息系统的复杂性 , 提高了系统架构的灵活性 , 降低了行内信息共享的成本 。 但随着系统功能的追加 , 总线程序逐渐成为一个复杂的庞然大物 , 导致存在隐性风险 。
例如 , 逻辑耦合严重 , 代码难以理解 , 开发人员职责不清 , 系统部署困难 , 回归测试、总线的扩容升级、或是在网络设备上的资源投入成本巨大 , 以及ESB这种“中心化”服务可能带来灾难性的雪崩效应 。
加上互联网时代的海量用户与数据 , 对系统可扩展、高并发及业务响应速度等方面都提出了更高的要求 。 所以 , 为了进一步提高银行整体科技能力 , 需要通过适当的分布式架构转型 , 来降低开发和运维的成本 , 有效的实现业务创新和技术变革 。
4)API平台
分布式架构是利用网络计算机设备 , 将计算任务和数据分解 , 充分利用各计算机的计算能力 , 彼此协调、共同完成一项业务功能的技术架构 。
在2016年 , 人行发布了《金融业信息化“十三五”发展规划》 , 明确提出“以安全、可靠、高效、弹性为重点目标实施架构转型、探索分布式架构和成熟开源技术应用 , 逐步减少或摆脱对单一技术产品的依赖” 。
所以无论从技术发展还是监管要求来看 , 银行核心系统朝着分布式架构、云计算方向发展已是必然趋势 。
如果将此前的银行系统比作煮鸡蛋 , 那蛋壳是渠道系统(如营业厅) , 蛋清是前置服务(如人行前置) , 蛋黄就是银行核心系统 。
那现在银行IT系统采用了分布式架构 , 从煮鸡蛋变成了摊鸡蛋饼 , 底座鸡蛋饼的接触面更大了 , 里面可以掺着各种各样的蔬菜、各种各样的佐料 。


推荐阅读