SOA系列一: 初识SOA

什么是服务

通常,一个架构师进行系统架构顶层设计时,必须考虑使用者的利益,不能单单实现软件的功能,还要考虑到软件的性能Scalable 可用性available/usable 安全性等软件质量,还要借鉴社区的最佳实践和经验形成的模式和反模式,避免重蹈覆辙和陷阱,再大胆采取最新的软件技术。

服务的提出其实隐含了两个概念,服务提供者和服务消费者,这两者之间有一个合同约定,这非常类似我们现实生活中签订的服务合同,A单位和B单位分别是服务的提供者和消费者,两者签订了一个服务合同,规定A为B提供某项服务。服务就是提供一些公共需求的设施,通过一个工作过程能提供帮助,使用,让使用者受益。

服务两个重要特点:自治和管制,自治代表服务不能被外部势力牵制,比如如果一个服务内部处理中需要调用外部资源或等待外部流程结束,这种等待不能影响服务本身的调用,如果一个服务分为显式对外和隐式内部两个部分,那么自治是针对隐式内部,意味着我们不能在具体一个服务中直接使用同步代码实现复杂功能。

实现服务真正自治,实际就是解决类之间依赖耦合的问题,消息是一种方式,但是基于消息又有两种通讯方式,基于请求响应和基于事件的EDA。

从服务自治可以看出,为什么要提出服务必须自治,因为服务是受管制的,在实际业务活动中,不同服务是被不同部分管理,比如定价服务归属财务部门系统,库存归属仓库系统,涉及系统之间调用协调不能自己使用同步RPC,而是需要消息。


什么是SOA的服务

在现实世界中,服务是一种我们花费购买到的一种预期的服务。

  • 例1 (来自真实世界) :你去餐馆订餐,您的订单首先进入到柜台,然后在厨房进行食物准备,最后服务员提供的食物。因此,为了实现一个餐厅订购服务,您需要三个逻辑部门/服务协同工作(计帐,厨房和服务员)。在软件世界同样的方法称为业务服务。

  • 例2 (软件世界) :你去亚马逊订购了一本书,有不同的服务,如支付网关,库存系统,货运系统等共同完成一本书的订购。

所有的服务是自包含的,合乎逻辑。他们就像黑盒子。

总之,我们并不需要了解业务服务的内部工作细节。对于外部世界,它只是一个能够使用消息交互的黑盒子。

例如在“支付网关”业务服务获得消息“检查信贷”后会给出输出:这个客户的信贷有或没有。对于“订单系统”,“支付网关”的服务是一个黑盒子。


什么是SOA

SOA代表了面向服务的架构。

SOA是一种使用松耦合的黑盒子服务构建业务应用的体系架构,这些服务可以通过编排连接在一起以实现特定的功能。

SOA是一种思想,它是一个架构理念,Web服务是完成它的技术方法。 Web服务是实现SOA首选的标准。

在SOA中,我们需要的服务是松耦合的。 Web服务进行通信使用的SOAP协议是基于XML的,这是非常松散的耦合。它回答了什么是服务的一部分。

SOA服务应该能够来形容自己。 WSDL描述了我们如何可以访问该服务。 SOA服务都位于一个目录: UDDI的描述,从那里我们可以得到Web服务。这其实是SOA注册表的实现。

SOA的三个标准术语

  • 合同
    • 合同是两方或多方之间的协议。它定义了一种客户端如何与服务通信的协议。从技术上讲,它有描述参数和返回值的方法。
  • 地址
    • 地址表明在哪儿能找到这种服务。地址是一个URL,它指向服务的位置。
  • 绑定
    • 绑定是决定这个端点如何可以访问。它决定了如何完成通信。例如,你暴露你的服务,可以使用SOAP over HTTP或通过TCP的BINARY进行访问。因此,对于这些通信介质将被创建两个绑定。

每个服务都必须公开一个或多个端点,以便让该服务提供给客户端调用。


SOA有什么特点

以下是服务的SOA的主要特点:

  • 随时可用
  • 粗粒度的服务接口
  • 分级
  • 松散耦合
  • 可重用的服务
  • 服务接口设计管理
  • 标准化的服务接口
  • 支持各种消息模式
  • 精确定义的服务契约

随时可用

当有服务使用者请求服务时,SOA要求必须有服务提供者能够响应。大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。同步应用对于其所使用的服务具有很强的依赖性。

许多同步应用通常部署在前台,其最终用户很容易受到服务提供者短缺的影响。很多情况下,同步应用利用分布式服务提供者,这样可以响应更多的用户请求。但是,随着提供特定服务功能的服务器数量的增长,出现短缺的可能性也呈指数级上升。

相比之下,异步应用要更为稳健,因为其采用队列请求设计,因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台,用户通常不会觉察到短暂的短缺。大部分情况下异步应用能够稳健应对短时间短缺,但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将罕见的大量工作推到共享的应用资源中时,可能会出现队列溢出甚至服务死锁。

服务使用者要求提供同步服务时,通常是基于其自身理解或使用习惯。在多数情况下,采用异步模型可以达到同样的效果,但更能够体现SOA的最佳特性。
当然,并不是所有情况下都应当采用异步设计模式。但大多数情况下,异步消息可以确保系统在不同负荷下的伸缩性,在接口响应时间不是很短时尤其如此。

粗粒度服务接口

粗粒度服务提供一项特定的业务功能,而细粒度服务代表了技术组件方法。举个例说明最为清楚——向计费系统中添加一个客户是典型的粗粒度服务,而你可以使用几个细粒度服务实现同一功能,如:将客户名加入到计费系统中,添加详细的客户联系方式、添加计费信息等等。

采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复,一次往复就足够。Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高,因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。

除去基本的往复效率,事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时,从而中止。与此相反,从事务的角度来看,向后台服务请求大块数据可能是获取反馈的唯一途径。

服务分级

一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差,因为粗粒度服务倾向于解决专门的业务问题,因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务,也包含粒度较粗、重用性较差的服务。

在服务分级方面,须注意服务层的公开服务通常由后台系统(BES’s)或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。

松散耦合

SOA具有“松散耦合”组件服务,这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。

服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。

大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式(如HTTP、JMS、TCP/IP、MOM等)。基于消息的接口可以采用同步和异步协议实现,Web服务对于SOA服务接口来讲是一个重要的标准。

可重用的服务及服务接口设计管理

如果完全按照可重用的原则设计服务,SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能,为开发人员节约了大量时间。设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。由于服务设计是成功的关键因此,因此SOA实施者应当寻找一种适当的方法进行服务设计过程管理。

服务设计管理根本上讲是服务设计问题,服务设计需要在两点间折衷——走捷径的项目战术与企业构建可重用通用服务的长期目标。

超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步,同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。

在大型组织中实现重用的一个先决条件是建立通用(设计阶段)服务库和开发流程,以保证重用的正确性和通用性。此外,对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键。

简言之,不按规则编写服务将无法保证可提供重用性的SOA的成功实施。在执行规则的过程中会产生财务费用,需要在制定SOA实施计划时加以考虑。

标准化的接口

Web服务使应用功能得以通过标准化接口(WSDL)提供,并可基于标准化传输方式(HTTP和JMS)、采用标准化协议(SOAP)进行调用。例如,开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用,并可以重用ERP系统和定制化J2EE应用中的现有服务,而完全无须了解这些应用的内部工作原理。采用XML,门户开发人员无须了解特定的数据表示格式,便能够在这些应用间轻松地交换数据。

你也可以不采用Web服务或XML来创建SOA应用,但是这两种标准的重要性日益增加、应用日趋普遍。尽管目前只有几种服务使用者支持该标准,但未来大多数的服务使用者都会将其作为企业的服务访问方法。

支持各种消息模式

SOA中可能存在以下消息模式。在一个SOA实现中,常会出现混合采用不同消息模式的服务。

  • 无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信息,从而更易扩展。
  • 有状态的消息。使用者与提供者共享使用者的特定环境信息,此信息包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信更加灵活,但由于服务提供者必须存储每个使用者的共享环境信息,因此其整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系,提高了交换服务提供者的服务难度。
  • 幂等消息。向软件代理发送多次重复消息的效果和发送单条消息相同。这一限定使提供者和消费者能够在出现故障时简单的复制消息,从而改进服务可靠性。

精确定义的服务接口

服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外,还可以在其中规定服务质量。此处需要注意的关键点是,服务契约必须进行精确定义。

META将SOA定义为:“一种以通用为目的、可扩展、具有联合协作性的架构,所有流程都被定义为服务,服务通过基于类封装的服务接口委托给服务提供者,服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。


SOA有什么优点

编码灵活性

可基于模块化的低层服务、采用不同组合方式创建高层服务,从而实现重用,这些都体现了编码的灵活性。此外,由于服务使用者不直接访问服务提供者,这种服务实现方式本身也可以灵活使用。

明确开发人员角色

例如,熟悉BES的开发人员可以集中精力在重用访问层,协调层开发人员则无须特别了解BES的实现,而将精力放在解决高价值的业务问题上。

支持多种客户类型

借助精确定义的服务接口和对XML、Web服务标准的支持,可以支持多种客户类型,包括PDA、手机等新型访问渠道。

更易维护

服务提供者和服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。

更好的伸缩性

依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独立调整,以满足服务需求。

更高的可用性

该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解提供者的实现细节,这样服务提供者就可以在WebLogic集群环境中灵活部署,使用者可以被转接到可用的例程上。

SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。SOA将能够帮助我们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式,它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往,以SOA架构的系统能够更加从容地面对业务的急剧变化。


坚持原创技术分享,您的支持将鼓励我继续创作!