风雨15年，瑞士信贷SOA架构演进之路

自SOA这一架构模式刚刚出现之时，甚至是在SOA这一名词出现之前，瑞士信贷就已经开始采用SOA原则和模式。本文作者通过回想这一金融巨头从使用紧密集成的主机程序到开放式SOA服务的历程，详述了接口契约和服务管理在企业IT中的重要性。

面向服务体系架构（SOA）的风格在过去10年中已经成为设计大型分布式系统的主流模式。SOA背后的核心思想是设计一个作为交互服务网络的系统。服务通过定义良好的接口提供清晰具体的功能。

数亿行自主开发的代码和许多成品应用程序支撑着复杂的环球化银行业务。与许多全球化银行类似，瑞士信贷拥有相当庞大的应用系统版图大约有6000个不同的应用程序。让事情变得更加复杂的是，整个系统版图紧密地结合在一起，这对大多数需要提供高效“直通”的自动化处理并且可以随时计算聚合风险敞口的银行来说是必需的。

由于银行的业务性质，一般情况下，他们都是新技术的第一批使用者之一。在一个比较典型的全球化银行机构中，拥有数以千计的全职软件开发人员，银行主动开发的系统必须既要适于30年前的遗留代码，也要适于最新的移动应用。庞大的应用规模，异构的技术和架构以及动态发展和紧密整合的需求为应用集成创造了一个非常具有挑战性的环境。

通过聚焦于集成框架，着重将整个IT系统分解成具有清晰界定的通过SOA解耦的子系统，瑞士信贷战略性地应对了这些挑战。本文报道了瑞士信贷过去15年的IT历程。

为什么是15年？因为15年前的两个事件从根本上挑战了传统的企业架构：其一是现存系统的替换需求，因为这些系统已经达到可用生命周期的尽头，其二是随着互联网的到来，银行必须要通过新的技术渠道提供服务的趋势已经越来越明显，这与现有的企业技术大不相容。90年代的挑战：开放主机在90年代早期，瑞士信贷在瑞士的平台仍然在使用1960和1970年代的典型系统架构：紧密结合的主机程序集合共享通用的中央数据库集。

图1瑞士信贷信息总线中的质量保证自底向上的设计和自顶向下的管理相结合

其中也包含一部分1980年代的技术“第四代”代码，基于生成器的开发以及一些运行在PC上的客户端-服务器端应用不过大部分的应用访问都是通过终端屏幕完成的。此外，整个系统版图中的相当一部分已经到了生命周期的尽头。

用全新的现代系统替换整个核心系统的尝试也已经失败：标准软件的计划采购和基于Smalltalk（首批获得商业认可的面向对象语言之一）的定制化开发项目都未能获得成功。分阶段替换平台的难度也非常大，因为共享的代码和数据让平台结合相当紧密。在试图构建分布式应用的项目中，高达80%的精力都花费在应用集成上。随着互联网银行的兴起，我们意识到实现一个全新的基于Web的交易渠道所需要的技术与银行中现有的技术完全不同。

此时，瑞士信贷重新审议了IT的整体策略并决定采用一种可管理的平台进化方案而不是更加激进的大改革：逐步完成平台替换以保证风险处于可控范围内，同时又能够维持必要的战略灵活性。特别是该计划准备在现有的富后端能力之上构建现代化的Web前端。想要成功达成目标，我们认识到需要一个强有力的集成架构实现异构技术的桥接并且能够支持在应用之间定义良好的接口基于这些需求，瑞士信贷信息总线的概念应运而生。该总线，作为“企业的神经系统”通过服务链接全部的主要子系统，这对我们的整体策略来说是至关重要的，通过它，我们可以逐步完成每个子系统的替换工作，同时又不会对其他的系统造成太大的影响。

在对市场上已有的分布式计算基础架构进行充分细致的评估之后，我们选择了通用对象请求代理架构（Common Object Request Broker Architecture），主要是因为当时CORBA能够不依赖于实现技术进行接口定义的故事十分令人着迷，不过在主机平台上还没有具体实现。我们与供应商一起开始将Unix平台上的实现向主机平台迁移，其中包括兼容PL1编程语言。

本阶段经验和教训：技术挑战无处不在，但都是可以解决的。经过15年的使用周期，CORBA现在已经被Web Service所取代正在逐步退出历史舞台。非常有趣的是，随着新技术的更替，最初的许多性能挑战又再次出现了。

一个最基本的设计原则是客户端只能通过瑞士信贷信息总线上的服务接口访问主机上的数据。因此我们选择了自底向上、按需驱动的方法，同时自顶向下完成质量保证工作（如图1）。

各个项目在需要时才会构建服务。初期，当需要数据而又没有足够的接口存在时，各个项目会申请新的接口或扩展原有接口。集成架构师在初步质量检查步骤中评审这一“基本请求”并从如下三种可能的结论中选择其一：

当能够满足需求的服务已经存在时，当前项目可以直接使用该服务。例如，股票交易系统可能计划构建一个股票代码服务，但并不知道其他应用已经可以提供这一信息。
如果申请的服务并没有重用的潜力，当前项目将构建一个私有服务，独占式地在该应用内部使用。这种情况经常发生在原本就是面向服务的较大型应用上。

如果申请的服务有重用潜力，就需要一个有扩展性的设计以便更广泛地应用。这种情况下，股票代码服务可能会被扩展成在提供标准的ISIN代码的同时还为每个币种提供内部编码。

在第二次质量检查时，一组设计专家会评审这一扩展后的设计并让设计方案更加清晰可执行。最后一次质量检查将确保服务的实现能够满足非功能性的质量指标，如性能。

本阶段经验和教训：在质量控制的严格性和构建服务的项目所需的灵活性和敏捷性之间找到合适的平衡花费了我们相当一段时间。通过将评审集中在那些会对整个系统造成重大影响的决策上，我们解决了这一问题。例如，我们只会检查某个服务对于其他服务来说并不冗余，并且该服务遵照可重用的方式设计，而并不会讨论服务签名中的每一个数据字段。

图二展示了瑞士信贷信息总线的采用情况。

图2瑞士信贷信息总线的服务可用性和使用量增长情况可用服务数量达到临界点后的广泛采用

尽管从1998年开始就已经可以使用信息总线，不过项目经理们并不愿意构建和使用服务。在几个大型的性能和稳定性十分关键的应用采用了瑞士信贷信息总线后，开发团体的信任度才逐渐增加。从2002年开始，总线上暴露的功能不断增加，直到2007年，大部分的服务已经可用时，增长开始放缓。在客户端方面，采用量从2003年开始有了飞跃。当暴露在总线上的功能超过一半时，大型客户端（调用几百个服务并且每天产生上百万个服务调用的大型程序包）最终全面采用了该服务架构。此后，直到大约2009年，基本上所有客户端都会通过服务层访问主机。

我们的战略目标是通过服务暴露主机上所有的数据和功能。目前为止构建的绝大多数服务用于让分布式应用访问和操作数据可能是主数据（客户信息）、参考数据（货币代码）或业务数据（账户信息）。一小部分服务提供对业务功能的访问，例如发起一次支付、提交一个交易订单或者税额计算。

一个重要的目标是鼓励在多个应用中重用服务。平均的重用因子是4，也就是每个服务被4个不同的应用使用。重用的情况很不平衡。某些服务会被大概100个应用重用，而大概有一半的服务只有一个消费者。意料之中的是，提供了参考数据和客户数据的服务具有最高的重用率。

大量的服务（和相对较低的重用率）是我们这种按需驱动方法所导致的。我们相信在理想的设计中，可能只需要大概一半的服务就能够提供同样的功能。当然这在事后说起来很简单。在启动这个项目时，我们根本没办法说清楚应该以何种优先级构建哪些服务。

图3国际化SOA的目标架构一个前端通过服务访问多个后端

经验教训总结：从最初的战略决策到整个组织决定全力投入该计划花费了4年时间。这是因为在对性能、稳定性和安全性都非常敏感的环境中完成复杂中间件技术的全面部署要花费相当一段时间。真正的挑战在于普及这一战略性决策所需要的耐力和管理让所有人都通过服务层访问主机耗费了10年的时间。我们曾经争论过这么缓慢的进程是否不正常，不过现在我们确信对于这类组织和这种规模的应用版图来说，这种节奏很正常。从业务角度来说，SOA方法推动了用户界面的变革。不再有人需要通过终端屏幕访问主机。瑞士信贷在服务层之上构建了多个互联网渠道，从最初的电子化银行应用到如今的复杂移动银行。

瑞士信贷信息总线的成功激发了SOA在其他战略环境中的应用。其中一个例子就是国际化私人银行业务。进入一个新市场的典型策略是基于一个在本地购买的，符合产品和法规要求的银行系统设立一个本地分支机构。本地系统中所包含的前端通常都相当复杂并且难以学习，这导致客户关系经理不会按照要求维护客户关系数据。

我们的战略方案是将成熟市场中一流的内部前端部署到新兴市场。从架构的角度来说，这一需求就是将一个全球化的前端与多个本地化的后端相整合（见图3）。这与我们在瑞士信贷信息总线中完成的工作类似，不过不是多个消费者应用共享同一个服务，而是一个消费者访问同一个服务的多个不同实现。

这一乍看起来相当明确的需求却开启了瑞士信贷集成架构一个全新的话题。我们必须更加正式的对待接口语义，特别是通过接口所传递的数据的确切语义。有意思的是，这在之前并未成为真正的问题。在之前的工作中，接口实现和底层的数据库已经隐含定义了数据语义。大部分的客户端能够理解这些语义，因为它们与引入服务之前的语义一致。在国际化SOA中，这一点完全不同，每个后端都是完全独立开发的。尽管高级业务对象，如客户、账户和交易，在每个后端系统都存在，不过他们在各个后端系统的具体表现却完全不同。

国际化SOA有两个需求：

1. 我们需要基于所有后端系统的最小公分母来定义服务，让服务在每个后端都可能实现。

2. 服务需要精确语义定义，因为每个服务的实现者都需要桥接语义空缺。语义定义是我们通过定义层次化业务对象模型所解决的一项新的挑战，如图4。

在企业层级，模型包含了一系列抽象的对象（客户、合约、产品等）以及对象之间的关联。领域架构师完善各自领域所拥有的对象并在领域层级增加额外的对象。例如，抽象对象“产品”通过增加描述所交易股票、交易价格等的属性会被细化为一个表示股票交易的对象。每一应用层级都会产生进一步的细化工作。一致性原则确保低层级的对象能够与较高层级的对象匹配。在逻辑层和物理层，数据库属性或数据库中的参数会映射到相应的概念业务对象。

一方面，它保证了通过接口存储和传递的信息有一致的概念模型。另一方面，它可以将不同名称和语法的属性和参数映射到通用的语义概念上，反之亦然。这一方案成功的关键就是联邦治理。无法通过集中化全部必须的专业知识，定义大型银行应用格局中的具体概念信息模型。第二个重点是该模型并非是自顶向下的：它是自顶向下的概念模型和自底向上的现实映射的混合体。因此，满足现有实现或成品软件的异构性的需求成为可能。这也是企业级数据模型间最主要的区别。

在最初的一段时间内，服务数据库曾经是SOA策略中重要的组成部分，不过几年之后，服务数据库显然已经不能满足需求。随着服务和开发活动数量不断增长，手工进行管理过程的管理变得越来越困难。而且很明显，CORBA不会永远持续下去，只用CORBA接口定义语言（Interface Definition Language (IDL)）一种形式捕捉服务定义，在后续的迁移过程中可能会出现问题。另外，我们也发现我们需要一个能够管理服务整个生命周期的系统，从初始设计到最终服务退役。

图4层次化业务对象模型企业层级模型实行集中管理，具体层级则联邦管理。

我们决定建立一套管理工具，帮助我们以独立于实现的方式捕捉服务同时又能够在服务的生命周期内维护各种管理过程。最初我们尝试过购买SOA仓库。不过，在2005年的时候，市面上的工具所具备的能力都十分有限，特别是在SOA管理方面我们所需的工具需要能够有效推动大批量服务联合开发的设计管理。为了达成这一目标，我们最终自主构建了服务管理应用。接口管理系统（Interface Management System（IFMS））支持设计、管理、实现以及生命周期管理。

IFMS的核心是一个以独立于实现的方式捕捉服务完整合约的数据库，包括消息签名和所有相关的元数据。元数据包括语义信息（如，服务所影响的主要业务对象以及前提条件和后置条件），非功能性信息（如，服务所在的平台和所用的技术。）该数据库还会跟踪所有已知的某个服务的消费应用。这些信息会用于生成实现服务所用的特定技术的合约之中（如，使用CORBA IDL或Web Service Definition Language [WSDL]）。

在某些情况下，我们还会生成一部分实现，例如用PL1编写的服务框架或者用Java编写的消费端抽象层。这一方法所带来的主要的好处就是我们只需要用不同的生成器就可以更换服务的实现技术。例如我们可以同时生成同一个服务的CORBA版本和Web service版本，这样就能够更好地管理技术的过渡。这一功能大大简化了我们一直持续的COBRA替换工作。这种生成器方法还大大降低了更换现有服务所需的时间，在一些情况下，甚至能节省75%的时间。

IFMS管理三种类型的管理过程：服务的设计管理，确保在整个服务领域中数据语义一致性的数据管理，以及确保服务在生命周期结束时能够正常下线的生命周期管理。图一所示的设计管理过程由工作流管理组件实现，该组件通知即将完成的任务的审查者和所有者并记录所有中间步骤和结果，如债务及其履行过程。这一自动化过程能够以相对较小的开销和相对较快的周转时间，实现每年数百次的同行评审。如果不需要设计变更，评审通常能够在服务提交之后的一周之内完成。

数据管理与业务对象模型联系紧密。通过简单地标识属性与某个特定对象相关的关联关系或通过模型转换从业务对象中直接推导出属性的类型，服务定义中的属性可以链接到业务对象。这一管理过程的主要焦点在于确保语义清晰度和数据一致性的评审。

适当的服务版本控制能够有效地将服务提供者与服务消费者解耦。因为所有的版本都需要有人维护，服务提供者需要投入许多精力。这也是为什么我们在生产环境中限定了版本数量的上限。从经验上来说，将版本数量上限设定为3个相对来说比较实用，这样既可以有效地控制服务提供者的成本，同时又可以让服务消费者在必须采用最新版本之前可以略过两个中间版本。

举例来说，如果一个服务每年有一次主要版本的变化，其消费者在必须采用最新版本的服务之前就有三年的准备时间。通常情况下，在这段时间内消费者应用本身会有一次升级，这样，新的服务版本的采用就可以作为正常的生命周期管理的一部分顺其自然地完成。与可能开销巨大的强制迁移相比，这显然是更受欢迎的方案。就我们的经验而言，三个主要版本的规则也是良好的折中选择。

虽然我们从来没有打算创建自己的SOA仓库，但是由于在当时开发的过程中，市场上缺乏成熟的解决方案，导致我们不得不这么做。即使到今天，虽然许多解决方案已经能够提供比八年前更多的能力，其中仍然有许多限制，特别是在平台独立性（绝大多数工具都仅限于Web Service）和可扩展的管理过程自动化方面。希望这种状态在将来会有所改变。

通过代码生成所节省的开发工作量让在IFMS中描述服务的工作更加吸引服务开发人员。这解决了最初的一个问题开发者不喜欢文档化。在IFMS之前，服务描述总是滞后于具体实现，并且经常与具体实现不一致。现在，服务的实现始于独立于平台的规格说明和技术接口文档，以及部分具体实现。

回顾瑞士信贷过去15年的企业服务架构，我们总结了许多经验和教训。首先，在大型公司中，深层次的架构变更所花费的时间要比大多数人们认为的时间更长。导致这一情况的原因是大部分的项目都是厌恶风险的，只希望采用经过验证的方法。新方法的验证加上从设计决策到完成实施的时滞，大概需要增加三到四年的时间。

在此之后，则取决于不同的推广策略，完全实现某个策略可能要花费数年时间。如果想在这个领域取得成功，耐心和毅力是必不可少的。如果你们公司的首席信息官希望在一个季度内就看到结果，就不要推进SOA或其他的企业架构方案。其次，在考虑SOA时，在企业范围内所采用的技术是一个非常重要的先决条件，不过这一部分比较容易。在我们看来，更加困难的部分在于如何围绕SOA安排整个组织，如何为整个组织提供可以创建通用语言的恰当的语义框架，以及如何实现必要的管理过程。

来源：InfoQ

关于21CTO

21CTO.com是中国互联网第一技术社交与学习平台。 为CTO、技术总监，技术专家，架构师、技术经理，高级研发工程师、PM等提供学习成长，教育培训，工作机会、人脉影响力等高价值的在线教育和社交网站。

本文转载自：微信公众账号 - 21CTO，版权归原作者所有！