详解SOA五种基本架构模式

详解SOA五种基本架构模式2008-11-18作者：袁发明来源：IT168目前，面向服务的架构（SOA）已成为连接复杂服务系统的主要解决方案。虽然SOA的理论很容易理解，但要部署一个设计良好、真正实用的SOA系统却非常困难。本文试图通过解析SOA的模式，提供与架构相关的技术指导，进而对以上问题提供详尽的的解答。在本文中，一共提到了五种模式。表1列出了这五种模式以及各自相关的问题。模式名称相关问题服务托管如何使服务能够适应不同的配置，避免设置监听器、组件连接等重复性常规工作。主动式服务如何提高服务的独立性以及如何处理暂时性的问题？事务处理服务如何可靠地处理消息？工作流化如何提高服务对不断变化的业务流程的适应性？边缘组件如何将服务的业务功能从无关的交叉问题（比如安全、登录等）中分离出来。表1：模式列表其中服务托管（ServiceHost）与主动式服务（ActiveService）是两种最常见的模式——即使服务的使用范围很小，通常也会使用这两种模式。这两种模式的主要内容都与解决服务相关问题有关，即与具体的服务部署有关（见图1）。模式一：服务托管服务托管是我们要讨论的第一个模式。它是最基本的模式，或者至少是最基本的模式之一。服务托管模式主要负责运行着服务实例的环境，以及与此相关的路由任务。问题随便选一个服务，任何服务都可以，别告诉我具体是哪个：）。你可以找到一些处理传入的消息或请求的监听代码；你可以找到一些连接组件的代码，还有一些初始化并激活这个服务的代码；或许你还能找到一些能适当地配置服务的代码。有没有觉得我很厉害？实际上，你可以在服务里找到上面的所有代码，至少是大部分。有许多工作都是重复性的、常见的。我们可以好好利用这一点。如何使服务能够适应不同的配置，避免设置监听器、组件连接等重复性常规工作？第一个办法（实际上也不是什么办法），就是为每一个服务重写所有的连接代码。很显然，这不是个好方法，因为重写的次数越多，就越可能产生一些缺陷。并且，对于维护来说，许多重复的代码产生的问题更为严重。在维护的时候，你不仅要确保每一个服务中的缺陷都已经得到修正，还要保证没有任何疏漏、所有的服务都已经同步更新。另一个相对较合理的办法，就是创建一个共同任务库，所有的服务都通过API与库相连接。这样确实会有所帮助，但是为了充分利用库的功能，你仍然需要编写连接代码。还有一个办法是利用继承创建一个超类，用超类实现共同的功能，然后让各个服务继承这个类。然而利用继承也有问题，因为服务的功能通常无法通过一个单独的类获得很好的实现。此外，不同的服务所处理的业务也完全不同——否则它们就是一样的服务了。因此，也无法让把这些服务归于同一类结构。继承几乎已经可以解决我们面临的问题——因为我们只需要写一次代码，只有不同的服务才需要定制。如果想不用继承得到相同的结果，我们就得使用框架。解决方案创建一个通用的服务托管组件，把它当作服务的容器或者框架。容器是可以配置的，并执行服务连接、安装等工作（见图2）。服务托管就像是一个肩负着许多职责的迷你框架。它的第一个职责就是正确地示例服务所包含的组件或类。服务托管还负责读取配置信息，比如，它可以读取服务消费者用来连接服务的端口。其它职责包括创建服务环境，比如在终端创建监听器。最后，服务托管可以负责连接组件——终端监听器上的协议绑定或者创建一个与数据库的连接。所有这些职责的共同特征是它们都与服务的实例化和初始化有关，并且正如我们在问题部分所描述的一样，你很可能会在多个服务中遇到同样的情况。前面已经提到，服务托管是一个框架，与第二种方法中描述的库的概念有所不同。库是一个实用类或方法集，你可以调用它们来获取特定的功能。而框架则包含了一些功能或流程，并通过调用代码来扩展流程或将其转变为具体的流程。这就是“控制反转（InversionofControl）”原理。这种原理已经在面向对象的框架中获得广泛的应用，比如Spring或Spring.NET、Picocontainers等。服务托管模式与其它方法相比有许多优势。其中一个优势前面已经提到——即服务托管是一种框架，它可以调用代码来改善性能，而无需你亲自进行编排。另一个优势是它能更好地实现开放/封闭原则（OCP）。OCP原则认为类应该是可以扩展的，但是不能修改；而框架的概念正是这个原则的具体表现。一个服务托管可以托管多个服务——虽然这种情况可能并不常见。我们曾经构建了一个系统，使用的方案规模小到一台计算机即可应付。这真的很方便。如果换另一种方案，那么服务可能就要扩展到多台计算机上，这样你就得应用多个服务托管实例，各个主机托管服务的一部分，而不是整个服务。服务托管模式已得到了技术供应商的广泛应用，这一点我们可以在下面的技术相关部分看到。技术相关这一部分我们将简单地了解一下利用当前的技术实现这个模式的意义。服务托管是一种基本的SOA架构模式，因此大部分技术都支持这种模式。JAX-WS和WindowsCommunicationFoundation都能用标记语言（XML）进行配置，并使用Web服务器（比如Servlet引擎或IIS）完成大部分的连接工作。WindowsCommunicationFoundation还提供了一个称为ServiceHost的类。Microsoft的说明文档是这样解释ServiceHost的：“如果你不使用InternetInformationServices(IIS)WindowsActivationServices(WAS)提供服务，就用ServiceHost类来配置并提供服务。IIS和WAS都能与ServiceHost进行交互。”从根本上说，其内置WCF对ServiceHost的执行与我们所描述的服务托管模式是基本一致的。如果你要自己实现一个服务托管模式，那么你可以从Spring（或者Spring.NET）、Picocontainers等轻量级容器中学习如何进行连接和实例化。这方面的技术实现并不多，因为服务托管模式实际上是一种相对简单的模式。轻量级容器与依赖性注射Spring和其它一些框架被称为“轻量级容器”。这些“轻量级容器”的优点是它们提高了方案的松耦合性和可测试性。这种优点是通过一种非SOA模式——依赖性注射模式（DependencyInjectionPattern）实现的。依赖性注射，正如名字所示，指一个类通过第三方“汇编程序”提供所需的接口。通过依赖性注射技术，类不再依赖于特殊的实现，而只依赖于接口和抽象类。这使可测试性获得了提高，因为你可以使用桩或模拟来为类提供虚拟环境。这同时也提高了灵活性，因为只要它们之间的关系不变，你就可以轻松地改变具体的实现方式。服务托管模式是一种简单而有效、并且已经获得广泛应用的的模式。质量属性场景这一部分是从需求的角度讨论使用模式的架构效益。大多架构需求是根据使用场景表现的质量属性（可扩展性、灵活性、性能等）来描述的。这些场景也可供其它可以应用模式的情况参考。使用服务托管模式的主要原因是重用性。由于多个服务需要使用的相同任务只需写一遍代码，因此重用性也随之提高。这还能带来另一个好处，就是可靠性的提高，因为你只需要调试一次。另外，服务托管模式还能提供可移植性的质量属性。由于这个模式的分离问题的效应，因此可移植性也得到了增强。另外由于可以使用标记语言配置服务环境，可移植性又会得到进一步提高。下面的表2列出了几个场景，可以给你虑使用服务托管模式的理由。质量属性（第一层）质量属性（第二层）场景示例重用性减少开发时间开发时，在20分钟内设定新服务的环境。可移植性安装系统必须支持以服务为单位对服务器进行配置。安装过程中，从一个环境切换到另一个环境所用时间应该少于一小时。一旦配置好并开始运行服务，你就得决定服务应该是被动式的（应请求唤醒）或是主动式的（无需等待服务消费者激活，并做一些零工，比如显示状态或处理超时）。正如名字所示，主动式服务模式下，服务是主动运行的，而不是被动的。模式二：主动式服务服务的自治性（Autonomous）很重要。自治性能够提高服务之间的松耦合性，并使整体方案产生更好的灵活性。但是自治性服务有什么实际意义呢？有人说，自治性意味着在不同的服务上工作的团队的自治性。这种定义表示，由于各个服务之间只有契约上的关系，因此服务之间几乎没有依赖性。这意味着各团队可以独立工作，专心于自己的服务，而不会互相绊脚。虽然这是一个不错的“功能”，但是同时还有一个更有价值（比如说商业价值）的定义，就是服务是非常自主（self-sufficient）的。下面我们通过一个示例来解释这个定义。问题有一家报纸订阅代理机构（比如Ebsco或Blackwell），它需要为客户创建一份申请。申请服务的一项内容是产生一份形式上的清单。要得到这样的一份清单，该机构必须同时有给顾客的折扣率和从各出版商处能够得到的折扣，这样才能计算出这份申请是否有利润。图3就是这样一个流程的简单示意图。在场景示例中，申请服务需要等待另外两个服务的信息。顾客服务是内部服务，与申请服务是同一系统；但出版商的折扣服务却很可能是外部服务——如果出版商的系统没有联机，那么会对我们的申请服务造成什么影响呢？会造成申请服务无法使用。即使我们花费了天文数字的资金来保证申请服务的容错性，但现在的问题是完全无法使用，因为申请服务是与外部的出版商的服务随时耦合的。因此申请服务不具有真正的自治性。如何提高服务的独立性以及如何处理暂时性的问题？上面所描述的问题表明，仅仅根据请求唤醒的被动式服务是有问题的，因为服务可能无法满足依赖于外部服务的契约条件（或服务等级协议）。一个解决办法是让服务对先前的结果进行缓存，但这只能解决部分问题，因为这样做数据就无法得到及时更新，并且时而也会有缓存失效的情况发生，这时仍然需要连接其它服务。这种方法还有另一个问题，那就是如果传入的请求过多，在处理一个请求的时候，其它的请求就会处于“等待”的状态，这样又会产生资源问题，因为而这些“等待”的请求都需要外部服务的输入。即使我们解决了前面的缓存问题，我们仍然得处理其它的暂时性事件。暂时性事件包括重复发生，或者与时间相关的一次性事件。比如，生成每月账单或发布股票数据或任何其它重复性的报告都是暂时性事件。一种解决方法是从外部编排服务。这种方法的问题是你得将服务的业务逻辑具体化。但是请记住，封闭的服务层是应用SOA的一个重要原因。因此我们得另寻解决方案。解决方案要使服务成为主动式服务至少需要一个主动类（ActiveClass），这个类可以在边界上，或者服务上，或者两者都有。然后让这个主动类处理暂时性问题和管理自治性。主动服务模式意味着在服务层上执行“主动类”（见图4）。在OfficialUML定义中，“主动类”是指“不需要调用方法即可启动自身行为的对象。”这定义对服务也适用。就是说，服务可以有独立的线程来处理循环类事件，比如每月账单或发布状态。主动式服务也可以监控自身的情况，处理超时，甚至可以用来处理请求。那么，怎么使用主动服务模式来解决我们上面提到的问题呢？就像帕特·森田在《空手道小子》里扮演的宫城先生所说，“最好的防守就是不要在场。”如果你要避免等待另一个服务这种事情发生，那么最好的办法就是不要等待；你可以主动地、周期性地从其它服务获取数据，更新你的缓存。你还能给其它服务减少类似的麻烦，并预先发布自己的变化状态。表面上看起来，缓存数据可能会引起数据重复的问题，但实际上这种情况是不会发生的（详见下面标注）。缓存与数据重复问题我想有些人，特别是那些学过数据库的人，看到我说从远程服务主动获取缓存数据的时候，肯定会从椅子上蹦起来质疑我远程数据复制的动机，认为我是不是大脑出了什么问题。然而，在我看来，这已经不是相同的数据了。缓存在服务上的数据是服务的数据，可以用来计算、处理甚至根据服务需要进行修改。当然，你也必须明白缓存数据的服务并不是负责控制数据的。一个带有计时器的线程基本上足够应付其它暂时性事件了（如果事件少，你可以为每一个事件安排一个定时器；或者定时唤醒，检查哪些事件需要处理并处理它们）。使用边界组件的线程处理契约相关的暂时性问题是