SOA组件模型和系统间数据传输

image

面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA,即service-oriented architecture,面向服务架构。

  • 是一种面向通用集成服务的、松耦合的架构实现方式,是web时代服务发展的产物;
  • 使用”分层”理念,比传统的”观察者”模式更高级且更有优势,主要体现在易扩展性和可灾;
  • 适用于大型复杂业务系统的数据共享。

image

其中的服务平台可以用不同语言实现,比如php,python,java等,比较通用的是RESTFUL接口模式,对于user端,只需明确接口定义,既可以使用HTTP/HTTPS进行通讯,理论上是无限量的。

SOA对于客户端来说极大的简化了开发周期。对于一个特殊需求的出现不会措手不及,更不会大动干戈重构底层,开发者不需要知道具体底层原理即可快速开发实现功能。

SOA定义

  它是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

  这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。而另一方面,紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的,因而当需要对部分或整个应用程序进行某种形式的更改时,它们就显得非常脆弱。

  对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活,以适应不断变化的环境,比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素,这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需(On demand)业务,在按需业务中,一旦需要,就可以对完成或执行任务的方式进行必要的更改。

  SOA是传统的面向对象架构模型的替代模型,面向对象的模型是紧耦合的,已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务,但是其整体设计却是面向服务的。由于它考虑到了系统内的对象,所以虽然 SOA 是基于对象的,但是作为一个整体,它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构(Common Object Request Broker Architecture,CORBA),它已经出现很长时间了,其定义的概念与 SOA 相似。

  然而,现在的 SOA 已经有所不同了,因为它依赖于一些更新的进展,这些进展是以可扩展标记语言(eXtensible Markup Language,XML)为基础的。通过使用基于 XML 的语言(称为 Web 服务描述语言(Web Services Definition Language,WSDL))来描述接口,服务已经转到更动态且更灵活的接口系统中,非以前 CORBA 中的接口描述语言(Interface Definition Language,IDL)可比了。

  Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式,这样就有了面向消息的中间件(Message-Oriented Middleware)系统。但是为了建立体系结构模型,您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此,SOA 应该能够将业务的商业流程与它们的技术流程联系起来,并且映射这两者之间的关系。例如,给供应商付款的操作是商业流程,而更新您的零件数据库,以包括进新供应的货物却是技术流程。因而,工作流还可以在 SOA 的设计中扮演重要的角色。

  此外,动态业务的工作流不仅可以包括部门之间的操作,甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此,为了提高效率,您需要定义应该如何得知服务之间的关系的策略,这种策略常常采用服务级协定和操作策略的形式。

  最后,所有这些都必须处于一个信任和可靠的环境之中,以同预期的一样根据约定的条款来执行流程。因此,安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。

SOA用途

  对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活,以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现,IT 系统既可以利用现有系统的功能,又可以准备在以后做一些改变来满足它们之间交互的需要。

  改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说,这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生,这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是,架构师的作用就是引起对 SOA 模型大的改变。这种分工,就是让开发人员集中精力于创建作为服务定义的功能单元,而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起。

SOA技术

SOA 本身是应该如何将软件组织在一起的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外,它还需要安全性、策略管理、可靠消息传递以及会计系统的支持,从而有效地工作。您还可以通过分布式事务处理和分布式软件状态管理来进一步地改善它。

  SOA 服务和 Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互,而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面,Web 服务在需要交互的服务之间如何传递消息有具体的指导原则;从战术上实现 SOA 模型是通过 HTTP 传递的 SOAP 消息中最常见的 SOA 模型。因而,从本质上讲,Web 服务是实现 SOA 的具体方式之一。

  尽管我们觉得 Web 服务是实现 SOA 的最好方式,但是 SOA 并不局限于 Web 服务。其他使用 WSDL 直接实现服务接口并且通过 XML 消息进行通信的协议也可以包括在 SOA 之中。正如在别处指出的,CORBA 和 IBM 的 MQ 系统通过使用能够处理 WSDL 的新特征也可以参与到 SOA 中来。如果两个服务需要交换数据,那么它们还会需要使用相同的消息传递协议,但是数据接口允许相同的信息交换。

  既为了建立所有这些信息的适当控制,又为了应用安全性、策略、可靠性以及会计方面的要求,在 SOA 体系结构的框架中加入了一个新的软件对象。这个对象就是企业服务总线(Enterprise Service Bus,ESB),它使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。虽然 ESB 并不是绝对必需的,但它却是在 SOA 中正确管理您的业务流程至关重要的组件。ESB 本身可以是单个引擎,甚至还可以是由许多同级和下级 ESB 组成的分布式系统,这些 ESB 一起工作,以保持 SOA 系统的运行。在概念上,它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而来的。

  SOA 可以与许多其他技术结合在一起使用,然而,组件的封装和聚合在其中扮演着重要的角色。如前所述,SOA 可以是一个简单对象、复杂对象、对象的集合、包含许多对象的流程、包含其他流程的流程,甚至还可以是输出单一结果的应用程序的整体集合。在服务之外,它可以看作是单个实体,但是在其自身中,它可以具有任何级别的复杂性(如果必要的话)。出于性能方面的考虑,大多数 SOA 服务并没有下降到单一对象的粒度,并且更适合于大中型组件。

  除了可能离不开 XML 和 WSDL 之外,SOA 并不是特定于语言的。可以用任何编程语言来实现服务,只要这种编程语言可以生成服务并且可以与 WSDL 结合在一起使用就可以了。SOAP 本身并不是绝对需要的,但它是通用的消息传递系统。因此,可以使用几乎任何一种编程语言和支持 WSDL 的平台来实现 SOA 中的成员服务。

  SOA 和 Web 服务是独立于编程语言的,但 Java 是主要的开发语言之一。可以使用定义良好的 Java 接口以及各种协议丰富的 Java 实现为正在构建这个模型的开发人员提供了优势。Java 在此担当了开发每个服务的功能、管理数据对象和与其他在逻辑上封装在服务内的对象进行交互的角色。

  SOA 与 Web 的另一个重要的关系是自主计算和网格计算的概念。自主计算的概念应用于管理分布式服务体系结构的范围,具体来说,就是帮助维护策略和服务级协议以及 SOA 系统的总稳定性。

  另外,网格计算可以以两个级别与 SOA 系统一起使用。网格是分布式计算的一种形式,它利用分布式特性和服务之间的交互来为 SOA 应用程序提供计算支持。在这种情况下,网格起到了框架的作用,其中实现了一些或所有单独的服务。因此,SOA 应用程序可以是网格服务的消费者。

在另一方面,网格本身也可以构建在 SOA 之上。在这种情况下,每个操作系统服务都是构成整个 SOA 应用程序的成员,而 SOA 应用程序就是网格本身。因此,单独的网格组件既可以使用 Web 服务进行通信,又可以以 SOA 的方式进行交互。总而言之,网格系统可以是 SOA 本身,也可以提供服务来在其上构建应用程序级 SOA 模型。

随着近年来SOA(面向服务技术架构)的兴起,越来越多的应用系统开始进行分布式的设计和部署。系统由原来单一的技术架构变成面向服务的多系统架构。原来在一个系统之间可以完成的业务流程,通过多系统的之间多次交互来实现。这里不打算介绍如何进行SOA架构的设计,而是介绍一下应用系统之间如何进行数据的传输。

应用系统之间数据传输有三个要素:传输方式,传输协议,数据格式

数据传输方式一般无非是以下几种:

  1. socket方式
    Socket方式是最简单的交互方式。是典型才c/s 交互模式。一台客户机,一台服务器。服务器提供服务,通过ip地址和端口进行服务访问。而客户机通过连接服务器指定的端口进行消息交互。其中传输协议可以是tcp/UDP 协议。而服务器和约定了请求报文格式和响应报文格式。如图一所示:
    image

目前我们常用的http调用,java远程调用,webserivces 都是采用的这种方式,只不过不同的就是传输协议以及报文格式。

这种方式的优点是:

  • 易于编程,目前java提供了多种框架,屏蔽了底层通信细节以及数据传输转换细节。
  • 容易控制权限。通过传输层协议https,加密传输的数据,使得安全性提高
  • 通用性比较强,无论客户端是.net架构,java,python 都是可以的。尤其是webservice规范,使得服务变得通用

而这种方式的缺点是:

  • 服务器和客户端必须同时工作,当服务器端不可用的时候,整个数据交互是不可进行。
  • 当传输数据量比较大的时候,严重占用网络带宽,可能导致连接超时。使得在数据量交互的时候,服务变的很不可靠。

2.ftp/文件共享服务器

ftp/文件共享服务器方式对于大数据量的交互,采用这种文件的交互方式最适合不过了。系统A和系统B约定文件服务器地址,文件命名规则,文件内容格式等内容,通过上传文件到文件服务器进行数据交互。
image

最典型的应用场景是批量处理数据:

例如系统A把今天12点之前把要处理的数据生成到一个文件,系统B第二天凌晨1点进行处理,处理完成之后,把处理结果生成到一个文件,系统A 12点在进行结果处理。这种状况经常发生在A是事物处理型系统,对响应要求比较高,不适合做数据分析型的工作,而系统B是后台系统,对处理能力要求比较高,适合做批量任务系统。

以上只是说明通过文件方式的数据交互,实际情况B完成任务之后,可能通过socket的方式通知A,不一定是通过文件方式。

这种方式的优点:

  • 在数据量大的情况下,可以通过文件传输,不会超时,不占用网络带宽。
  • 方案简单,避免了网络传输,网络协议相关的概念。

    这种方式的缺点:

  • 不太适合做实时类的业务
  • 必须有共同的文件服务器,文件服务器这里面存在风险。因为文件可能被篡改,删除,或者存在泄密等。
  • 必须约定文件数据的格式,当改变文件格式的时候,需要各个系统都同步做修改。

3. 数据库共享数据方式

系统A和系统B通过连接同一个数据库服务器的同一张表进行数据交换。当系统A请求系统B处理数据的时候,系统A Insert一条数据,系统B select 系统A插入的数据进行处理。

image

这种方式的优点是

  • 相比文件方式传输来说,因为使用的同一个数据库,交互更加简单。
  • 由于数据库提供相当做的操作,比如更新,回滚等。交互方式比较灵活,而且通过数据库的事务机制,可以做成可靠性的数据交换。

    这种方式的缺点:

  • 当连接B的系统越来越多的时候,由于数据库的连接池是有限的,导致每个系统分配到的连接不会很多,当系统越来越多的时候,可能导致无可用的数据库连接
  • 一般情况,来自两个不同公司的系统,不太会开放自己的数据库给对方连接,因为这样会有安全性影响

4. message方式

Java消息服务(Java Message Service)是message数据传输的典型的实现方式。系统A和系统B通过一个消息服务器进行数据交换。系统A发送消息到消息服务器,如果系统B订阅系统A发送过来的消息,消息服务器会消息推送给B。双方约定消息格式即可。目前市场上有很多开源的jms消息中间件,比如 ActiveMQ, OpenJMS 。
image

这种方式的优点

  • 由于jms定义了规范,有很多的开源的消息中间件可以选择,而且比较通用。接入起来相对也比较简单
  • 通过消息方式比较灵活,可以采取同步,异步,可靠性的消息处理,消息中间件也可以独立出来部署。

这种方式的缺点

  • 学习jms相关的基础知识,消息中间件的具体配置,以及实现的细节对于开发人员来说还是有一点学习成本的
  • 在大数据量的情况下,消息可能会产生积压,导致消息延迟,消息丢失,甚至消息中间件崩溃。

下面具体来分析一个场景,来看看系统之间数据传输的应用
场景 目前业务人员需要导入一个大文件到系统A,系统A保存文件信息,而文件里面的明细信息需要导入到系统B进行分析,当系统B分析完成之后,需要把分析结果通知系统A。
image
A 系统A先保存文件到文件服务器。
B 系统A 通过webservice 调用系统B提供的服务器,把需要处理的文件名发送到系统B。由于文件很大,需要处理很长时间,所以B不及时处理文件,而是保存需要处理的文件名到数据库,通过后台定时调度机制去处理。所以B接收请求成功,立刻返回系统A成功。
C 系统B定时查询数据库记录,通过记录查找文件路径,找到文件进行处理。这个过程很长。
D 系统B处理完成之后发送消息给系统A,告知系统A文件处理完成。
E 系统A 接收到系统B请求来的消息,进行展示任务结果

4种系统间交互方法比较

image

附录 MVC、RPC、SOA框架

单一应用架构

当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。
此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

垂直应用架构

当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。
此时,用于加速前端页面开发的 Web框架(MVC) 是关键。

分布式服务架构

当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。
此时,用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

流动计算架构

当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。
此时,用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

Donate comment here
Title - Artist
0:00