2个架构路线，我们该如何抉择？ - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

从90年代初开始至今，国内银行业信息化建设已经走过20多个年头，在这个过程中，出现了多种建设模式。
四大国有商业银行都选择了几乎全部自主开发的模式。它们的发展历程大致可以分为三个阶段：第一阶段是从90年代初到96、97年，分别建立了对私、对公和联行汇兑等独立的业务系统，采用PC机+终端，数据分散存储的架构。第二阶段是从96、97年到02、03年，引入小型机（有一些AS400，某些发达地区甚至还运用了ES9000），按照C/S架构、或者三层架构构建城域和省域数据集中的综合业务（包括了主要的、标准化的业务）系统。第三阶段是从02、03年至今，普遍运用大型机，以全国数据大集中和建设几乎囊括银行所有应用、功能极为全面的核心银行系统（基于一套统一的平台或框架的超级大核心）为标志。
从这个发展历程可以看出，大型银行的业务系统一代比一代集中、一代比一代综合。这种集中、综合的架构好处显然易见：
首先，从开发的角度看，如果各应用系统能够综合在一起，构建在一个统一的框架或平台上，那么，它们之间的交互和应用集成（EAI）就非常方便，应用运行起来非常可靠，性能指标也最高。比如，一个产品应用调用一个帐务管理应用的接口，在这种架构上，都是以函数调用或者类似函数调用的方式进行，相关逻辑往往都是在一个线程内执行的，这使得数据交换（函数传参）非常高效、可靠，在数据库事务机制的支持下，也不存在数据一致性问题。相反，如果产品应用和帐务管理应用是独立、分布的系统，那么，这种调用就必须基于系统间通信进行，开发不方便，数据交换低效、不可靠，并且会产生严重的数据一致性问题。
其次，从运维的角度看，对于整个IT系统而言，这样的架构能够以最低的成本做到极高的可靠性——只需要针对核心银行系统部署时几个关键的逻辑节点制订一套高可靠性部署方案（集群、灾备等等），并配以相应的运维保障团队，那么，整个IT系统运行的可靠性问题就基本解决了。相反，独立、分布的系统往往由于技术架构不统一，质量良莠不齐，制订高可靠性部署方案并配备相应的运维保障团队代价巨大，加之未来的应用环境中，这些系统相互间存在大量的调用，可靠性相互依赖，因此，站在全局的层面看，其整体可靠性不如集中、综合的系统。
    既然集中、综合的系统架构优势这么大，那为什么银行没有一上来就搞超级大核心呢？这是受当时条件所限。
要想建设集中、综合的系统，必须具备2个基本条件，1是要有足够强大的基础技术架构，确保对所面对的领域内的各种类型的应用都能够提供很好的支撑；2是要有足够强大的应用开发团队，确保相关应用都能够自行开发出来，或者虽借助外部开发人力资源，但都在自己指定的平台上，在严格的架构管控下开发出来，而不必依靠公司提供技术架构完全不同的应用组件。
基础技术架构又可以分成硬件和软件两个层面。硬件是指服务器和网络，服务器必须能够提供廉价但性能强大、可伸缩性、可靠性均很高的部署方案。90年代的PC显然是不行的，2000年后的小型机也难以承担这个重任，但现在，大型机，小型机与PC服务器均能在硬件层面提供有效的解决方案。PC服务器的集群，以及以PC服务器集群为基础构建的云计算基础设施，已经被业内看作基础架构未来的发展方向。
软件是指中间件或业务基础平台软件。传统的中间件产品，例如CICS，TUXEDO，用来构建最后端的联机交易处理系统可以，但用来构建连接、集成多个外部系统接口的服务集成应用——在超级大核心中，这种应用比比皆是——就难以胜任了。所幸的是，新一代的中间件和业务基础平台软件已经出现，它同时具备用作交换系统、前置系统和最后端的联机交易处理系统的技术支撑平台所必须的主要特性，在这些新一代的中间件和业务基础平台软件上，即能够开发最后端的联机交易处理应用，也能够开发需要与各种外部系统对接的服务集成应用，甚至还能够开发数据统计分析应用，以及多种渠道上的前端展示层应用，并保证这些应用具有优秀的品质——KKKK既是这种新一代的业务基础平台软件产品。
有人认为所有应用都在一个框架上，坏的应用会干扰好的应用，导致整个系统运行不稳定、不可靠——这个问题其实早已经不存在。即便是运用上一代中间件技术（CICS，TUXEDO）构建的应用系统，也早已通过一些基本的编程规范（例如，应用最好只使用局部变量，不使用全局、静态变量，严禁使用共享内存等等）有效地消除了这些问题。xxx行数据大集中以来，还从未看到过因为某个应用的问题而导致整个综合业务系统停止运行。新一代的业务基础平台软件又采用了各种有效的措施隔离、保护应用的执行空间，这种问题已经完全消除。
不过，光是技术方面的条件已经具备还不行，银行还要有强大的应用开发团队或者应用开发管控团队，才能做到在统一的平台上完成所有应用的开发——而这恰恰是规模较小的商业银行无法具备的条件。
    规模较小的商业银行只能完成部分或者根本不能实施自主开发，大量应用组件，甚至全部应用组件都要依赖公司开发，甚至直接采购、部署公司的技术架构完全不同的应用软件产品。在这样的架构上进行应用的连通、整合非常困难，正是在这样的背景下，有人提出了ESB以解决EAI的问题。但必须看到，ESB只是通过统一接口和访问点，解决了访问方便的问题，但分布式系统架构固有的可靠性、效率、数据一致性等问题依然存在。实际上，ESB只是在肯定无法达到理想目标的前提下迫不得已、不得不采用的一种不完美的EAI解决方案。但凡有条件的银行，都不会走以ESB为中心的应用架构路线。
据我们了解，第一个提出并开发了ESB的是***行，其系统08年上线，但ESB在***行难以算作重要的、关键的中心系统，09年其每天处理的服务笔数仅约为1000左右，真实作用和ESB这个名称相去甚远；xxx行的ESB是在10年开发的，那时xxx行正开展最新一代的核心银行系统B的规划设计，B是一个超级大核心，所有服务层应用都建立在一个框架上，应用之间的交互就是函数调用，由此就可以判定，xxx行的ESB从一开始在应用架构规划中就没有被作为一个中心系统对待。不只是xxx行，yyy行、zzz行等正在开展的最新一代核心银行系统也都是超级大核心架构。
在《KKKK与ESB》一文中，我们把ESB的发展分成了3个阶段：原型（交换系统）阶段、适配增强型阶段和服务集成型阶段。相应的，ESB系统也可以分成3个层级：原型ESB，适配增强型ESB和服务集成型ESB。显然，随着层级的提高，ESB成功实施的技术复杂度也大幅上升。
原型ESB在大型银行的确是成功实施过的，不过那时候概念和定位都还远没有上升到ESB的高度，例如，xxx行的借记卡交换系统（在未实现全国数据大集中之前用以解决借记卡跨省交易问题）。
随着中小银行信息化的开展，普遍出现了EAI的问题。不少公司开始鼓吹ESB概念，并在一些中小银行实施了ESB项目。这些ESB大都定位成适配增强型ESB。遗憾的是，绝大多数这种项目也都是失败的，其原因在于很多公司用前置系统，而非交换系统的技术基础和积累来实施ESB！堵塞、宕机经常发生。很多上了ESB的中小银行都不得不降低了对ESB枢纽化程度的设定。
不管ESB枢纽化程度是否达到预期，运用了ESB的银行渐渐又觉得ESB不能只解决统一接口和访问点的问题，他们进一步提出了在ESB上进行服务集成的需求——ESB要承担类似前置系统的职责，即所谓的服务集成型ESB。业内先前提供的设计延续自前置系统框架的ESB技术平台倒是能够满足这方面的功能要求，但是运行起来就更加不堪重负了。因此，业内服务集成型ESB的成功案例目前还没有。
不过，业内的专业厂商也已经看到关键问题所在，并试图推出新一代的ESB中间件，这些中间件都是以交换系统框架作为一个基本设计，同时增加上层设计用以解决服务集成所需面对的服务流程设计、数据一致性等问题，例如Oracle的ORB，IBM的MB。本质上，KKKK的XCS/SC也是同样的思路。
这让试图构建服务集成型ESB的银行终于看到一丝曙光。但是，无需多少时日，架构师们便会发现，服务集成型ESB所需技术支撑平台（以下简称ESB平台，例如ORB和MB）与新一代业务基础平台（例如KKKK）的服务层应用框架（XCS/SC）在设计和实现等很多方面都可说是殊途同归，实际上，新一代业务基础平台的服务层应用框架就涵盖了ESB平台所需的所有特性，完全可以作为ESB平台加以运用。
银行迟早都会运用新一代业务基础平台来升级其业务系统。如果先建设了服务集成型ESB，再上基于新一代业务基础平台构建的业务系统，架构师们最终将不得不反思ESB是否还有存在的必要。
思路和我多年前想的一样啊。

最大的问题在于，地球上目前没有一家公司有能力把所有银行业务在一个系统内实现。
Ray001 发表于 2013-9-12 15:34

思路和我多年前想的一样啊。
最大的问题在于，地球上目前没有一家公司有能力把所有银行业务在一个系统 ...
我想，关键不在公司，而在银行
思路基本和我想的一样，完全是反现在的“瘦核心”的，哈哈。
不过也不是所有功能都在一个系统里实现，还是有一定的规则去划分的。比如，外围接口显然就不会放在里面。
非常赞同集中、综合的架构，个人认为实现的关键点有两个：一套非常成熟、可靠、高效、灵活、易于开发、调试、部署的技术平台；一套面向银行全球化运营全领域金融业务模型（要涵盖成本、风险、产品定价等方面的分析支持及操作反馈），这个相当难，必须有大批金融业务领域的专家投入大量的时间和精力才有可能做出（感觉除了IBM级别的厂商有资金和人力能做成这样的事情之外，就只有顶级银行如花旗有能力完成这样的建模工作）。如果efsca兄已经有了相应的产品，非常愿乐欲闻！