关于银行系统中SOA架构实施的一些讨论_建设银行 soa

作者：AllinToyou | 2024-05-01 15:35:45

踩

建设银行 soa

关于银行系统中SOA架构实施的一些讨论

一． SOA 简介

SOA （ Service Oriented Architecture 面向服务架构）最早由 Gartner 公司提出（国际权威 IT 研究与顾问咨询公司，提出 ERP 、 SOA 等划时代的概念）。遵循 SOA 规范的银行软件系统，是多个松散子系统协同工作的结合体。“松散”（或松耦合）意味着每个子系统（在 SOA 架构中被称为服务： Service ）独立开发，独立运行，有时和别的子系统进行数据交互。比如一个核心系统进行帐务处理，另外还有 ATM 子系统，信用卡子系统，中间业务子系统等，需要和核心系统发生数据交互。著名业界研究公司 Celent 对 SOA 的定义是：“一个为了实现业务上和 IT 上的需求和开发的松耦合服务的集合”（“ a set of loosely coupled modular services to support both business and IT requirements. ”）。

SOA 是个新的架构理念，却不是一个全新的事物。看看软件架构的发展过程：面向过程 → 面向对象 → 面向组件 → 面向服务。开发者基于对以往架构的了解，再学习这个 SOA 并不困难。看看 SOA 说了什么：单元模块（服务）实现独立的功能（对比函数、类、组件），模块之间的依赖关系（松耦合、紧耦合，这个在以前的架构中讨论很多了），以及模块协同工作的机制（对比函数调用、类调用、组件之间的消息通讯机制）。 SOA 里面的基本概念多是原有开发概念的扩展和提升。

那 SOA 好在哪里。个人理解它的一个重要优势就是把原有软件架构中那些主要体现在开发过程（如编码、详细设计）中的优点提升到系统的搭建、业务需求，系统的生命周期等更高层面了。这些优点在 SOA 上的体现可以总结为：

1 灵活性：系统的开发不受平台和语言的限制，每个服务可以在不同开发平台，用不同语言开发。而且一个系统的搭建变成了一系列服务的组合。使系统架构的设计变得很灵活。而且这种灵活性导致了一个项目可以引入多开发商分期实施，再统一项目管理。

2 复用性：每个服务可以一直重复利用，提高了开发效率。

3 一致性：一个服务实现单一的业务，实现具体业务和软件模块紧密联系。

4 对需求的快速反应：这种灵活性和复用性使得业务需求的变化可以很快在软件系统中实现。

5 延长银行系统的生命周期：基本业务的服务化，以及服务的重用性，使得系统升级可以通过重组旧服务来实现。

6 协助现有业务流程和软件开发流程的改进：这点既是优点也可能是难点：

6.1 通过 SOA 转型，对现有业务流程是一次改进的机会，而且也改善业务的整合能力

6.2 实现业务之间配合和交流的标准化。譬如通过建立统一的服务接口，实现数据特征的统一，包括数据结构（如地址信息中要包含的属性）的统一，语义（如“客户”的定义）的改进，以及数据格式的统一，等等。

然而，从以上最后一个优点，也引出了实施 SOA 的一个最主要障碍，就是实施过程中和已有系统和业务流程的冲突。也就是说， SOA 在行业中应用的优势主要体现在它得到全面实施之后，而它的缺点主要来自实施过程中和现有体系的冲突。 通俗地说，它是个好东西，前提是它能被用上。当然这样的特点在很多新的软件开发理念实施的时候都有，比如 MIS （ Management Information System 管理信息系统）和 ERP （ Enterprise Resource Planning 企业资源计划）的推广过程。 SOA 的实施过程可能有以下几个难点：

1．实施过程中导致的业务流程上的变化，而带来的时间和费用上成本

2． SOA 实施过程中，原有系统的模块重组，可能导致系统的复杂化。

3．业务流程上，甚至可能带来企业组织结构上的改变，导致人事变动等一些非技术的问题出现。

SOA 另外一个潜在问题是，国内银行业的某些强调时间和效率的业务流程，可能不适合 SOA 的松耦合架构。 SOA 虽然在架构组织上有优势，但是服务之间的频繁交付一定程度上是以牺牲效率为代价的。但是基于国内银行业庞大的个人用户基数以及操作的频繁性，大量 OLTP （ On-Line Transaction Process 联机事务过程）的处理，使得某些个人业务强调高效性和准确性，可能高度统一的紧耦合系统架构更适合。这也是实施 SOA 过程中必须考虑的。

关于 SOA 的优缺点，还可以参考建行的刘立先生在 SOA 中国路演的讲座【 1 】，以及 IBM 和 Bank Technology 的两篇文章【 2 】【 3 】中的讨论。

说起来，SOA和软件开发中另外一个体系 AOSE （ Agent Oriented Software Engineering 面向代理软件工程）倒是很相似，这也是我的技术方向之一。它的核心组件代理（ Agent ）是传统开发理念中对象（ Object ）的扩展，而且更复杂，功能更强大；具有消息驱动，目标坚持，自主决策，以及环境适应等特点，形象的比喻就像一个软件机器人。 Agent 这些特点和 SOA 中服务（ Service ）的特征很类似。而 Agents 之间的基于消息驱动的工作机制，也和 SOA 架构中各种服务协同工作的原理有着很大的相似性。如果利用 Agent 帮助 SOA 的开发也是软件研究一个讨论的话题。如果有 AOSE 的研究或开发背景，再转入到 SOA 领域是一件很顺手的事情。

二． SOA 在银行业的应用

SOA 规范在国际的银行业中已经得到了大力提倡和推广。独立研究机构 FORRESTER RESEARCH 在 2010 年夏季对全球 80 家著名金融企业的决策者调查报告【 4 】显示，超过 80 ％的企业在他们的系统中采用了 SOA 。在所有被调查者中，虽然有 80 ％左右的公司在业务应用中使用 SOA 比例小于 1/3 ，但是超过 70 ％的公司打算在未来两年内让这个比例超过 1/3 。另外这份报告还建议，银行最好独立于提供商来决定如何实施 SOA ，建议银行根据自己的实际情况来制定 SOA 的实施计划。因为每个银行都有自己独特的业务流程和系统架构，而软件提供商通常只给出一个通用解决方案。这些建议的本质就是银行要自己拿主意。

在具体的例子中，不乏成功的案例【 3 】。譬如美国国民城市银行（实施了 ORACLE 的 EBA 系统）是最早实施 SOA 架构的银行之一。该银行的技术总监 McCartin 介绍，该行的 SOA 是一个高度分散的模型（ decentralized SOA model ），实现了服务的高度复用性。平均每个服务可被 3.1 项业务功能使用，而且 2007 年通过服务的复用，在新的业务系统开发中节约了 1600 万美元。而美洲银行作为建设银行的重要战略合作者，它实施 SAP 的 ERP 系统，利用 SOA 架构来促进系统标准化以及整合能力。尤其美洲银行在并构其他银行的过程中， SOA 使得被合并银行的原有系统能快速高效地被整合到美洲银行的系统中。在国内的应用中，建行利用普元公司的 EOS 系统，实施了 SOA 架构，是一个成功的例子【 5 】。

三． SOA 的开发

SOA 的开发并没有一个严格的大一统标准，由各个软件产商自行定义。比较流行的标准有 SCA （ Service Component Architecture 服务构件结构）【 6 】和 WCF （ Windows Communication Foundation ）【 7 】。前者由开放组织 OSOA 提供，并得到很多主流软件开发商的支持，包括 IBM, ORACLE, SAP 以及国内的普元公司。后者主要是微软提出的基于 Windows 平台的 SOA 开发标准。（这又是一个微软搞自己的标准对抗全世界的现象。）

以 SCA 标准为例，它定义了一个遵循 SOA 规范来进行系统建模的过程。这个建模过程的核心思想是通过专门开发的软件构件（ component ）来实现服务，并通过软件构件的相互调用来实现业务流程。这个建模过程有两个主要部分：构件开发：每个构件实现相关的服务以及调用其他服务（类似于生产单个汽车零件）；构件组装：把相关组件组装起来实现业务流程（类似于把零件组装起来成为一辆汽车）。

为了实现一个 SOA 系统， SCA 还需要另外两个要素，一个是数据模型。业务的核心是数据，大多数业务流程也可以理解为是对数据的处理过程。 SOA 作为一个抽象的架构规范，它需要一个数据模型来定义组件所访问的数据格式以及访问外部数据源的接口。 OSOA 组织提供了 SDO （ Service Data Objects 服务数据对象）规范【 8 】，作为 SCA 的姐妹标准。 SDO 定义了数据图（ data graph ）作为基本的数据单元，每个数据试图是一个树状的或者图形结构的数据对象。 SDO 定义的接口可以读写各种外部数据源，如 XML ，数据库，文本文件等。外部数据被 SDO 数据读取后被存为数据图的格式，供内部构件访问。

SCA 所需的第二个要素是业务流程描述。一个业务流程是一系列服务的编排组合（需要一个例子）。一个的 SOA 系统需要相应的方式来描述各种业务流程（服务的编排组合，流程的状态管理等）。业务流程可以通过专门的流程语言来描述，例如 BPEL （ Business Process Execution Language 业务流程执行语言）。一个用 BPEL 描述的业务流程可以实现成一个服务，供其它相关服务使用。

在 SCA 标准中，基本的软件发布单元（可被外部系统使用的）是组合构件（ composites ）。组合构件提供了可以直接被外部系统使用的基本业务服务，譬如帐务管理、信用卡管理、日志记录等。一个业务流程的搭建也是基于组合构件的排列组合。每个组合构件提供的服务可被别的组合构件或者外部系统直接调用，也可以调用别的系统的组合构件。譬如帐务管理构件调用日志记录等构件来进行日志记录（很类似函数调用）。一个组合构件由一个或者多个底层构件（ component ）组成，每个底层构件实现一个单一的服务，也可以调用或被其他底层构件调用。 SOA 系统 → 组合构件 → 底层构件的关系有点类似于传统软件开发中系统 → 模块 → 类之间的关系，当然结构和相互之间的关系更复杂。关于 SCA 标准的更详细介绍，可参考【 6 】。关于 SCA, SDO 和 BPEL 之间的关系，可参考 SOSA 官网的介绍【 9 】【 10 】。

另外，对于 SCA 标准是否可以完美实现 SOA ，也存在一些争议。 David Chappell（Oracle公司副总裁及SOA首席技术专家）就提出SCA的一个特点是一个组合构件内的基本构件必须是由同一软件厂商的技术开发的（ a single-vendor construct ）。譬如一个组合构件不能由.Net C#开发的基本构件和Java开发的EJB基本构件组合而成。这个特点影响了 SCA 系统的交互性，具体到开发流程中，也就是单一的组合构件必须在同一软件厂商的平台上开发。不过个人认为这只是理论严谨性的问题，在实践开发中似乎不是个大问题，一个组合构件由同一平台开发也是有好处的，有助于提高它的开发效率和运行效率。毕竟一个组合构件对应一个基本业务服务，就好比一个团队工作里的一个成员。成员之间的合作可以讨论耦合度和合作方式，但是每个成员自己要做的事情还是要讲求效率优先。

四． SOA 和 ESB

以上谈的都是规范和标准层面的问题，具体到开发层面，还有一个重要概念就是 ESB (Enterprise Service Bus 企业服务总线 ) 。 ESB 就是一根连接各种服务的纽带，也可以理解为放置各种服务，使之能够协同工作的容器【 12 】【 13 】。 ESB 并不是 SOA 的特有的，而是可以帮助实现 SOA 的一项技术。它的重要性在于解决一个很现实的问题：不同服务（主要是实现服务的程序模块）之间进行数据交互时，数据格式不统一的问题。特别不同服务可能是不同语言开发的，也可能是不同时期开发的新旧不同的程序模块。它们的接口很可能具有不同的数据格式。一个 ESB 就像一个万能翻译器，实现构件之间的交互。 ESB 的实现标准也没有一个统一的规范，不同厂商各有标准。一般来说 ESB 要具有以下几个特点：