SOA与松耦合

来源:百度文库 编辑:神马文学网 时间:2024/03/29 18:46:58

《什么是SOA》中可以看到松耦合对于SOA架构的意义,SOA架构最求的就是将原来一个超级大型的系统裁剪,减少依赖,减少相互之间的影响,简单的说就是增强灵活性:增强接需求的灵活性,增强修改bug的灵活性,SOA架构最求的就是这个,当然这并不是说引入了一个SOA框架,比如WCF,或者一种服务调用框架,hsf,就可以实现这个目标了,这还是和你的服务划分的方式,部门之间的协作程度,一些技术点的抉择有关

 

下面讲一下一些技术点里的耦合联系:

 

 

紧耦合

松耦合

物理连接

点对点

通过中介者

通信风格

同步

异步

数据模型

公共复杂类型

只是简单的公共类型

类型系统

交互模式

通过复杂的对象树导航

以数据为中心、自足的消息

业务逻辑控制

集中控制

分布式控制

绑定方式

静态

动态

平台

强平台依赖

平台无关

事务性

2PC(两阶段提交)

补偿

部署

同时进行

非同时进行

版本划分

显示升级

隐式升级

 

 

1.物理连接,在WCF中使用,直接使用添加引用的方式,其实就是点对点的连接,服务端关闭的时候就会调用失败,包括hsf服务,有时候也要配置地址,这也是紧耦合的,另外hsf还可以通过configserver去获取,消费者可以通过服务名(标签或者符号)来标识要访问的服务,虽然还是点对点的,但是已经实现了间接性(要做适当缓存,避免每次询问地址,影响性能)。这实际上就是通过中介者,这相对来说可以更加松耦合。它可以同时在里面做负载平衡和是失效备援,这属于那种在出发之前就告诉你正确的服务端点,这要求消费者端只能一点,比如配置一个ConfigServer。另外,还可以让每个服务做到动态提供,在启动或者运行时,每个供应者注册自己。

 

除了connfigServer,还可以提供一种拦截器的方式,或者叫做代理,每个请求都请求道一个七负载均衡作用的硬件或者软件,消费者仍然使用一个正式的端点,该端点再委派真正的任务:当消息到达时,负载均衡器把消息分发到自己所知的不同的物理服务供应者上。

 

更复杂一些的ESB方法为每个供应者和消费者提供一个拦截器代理,消费者只与正对自己的特定拦截器进行“点对点“方式的通信。

 

Web Service天生就是一种点对点的协议,没有包含对负载均衡和失效备援的规定。这两个仍然是大型分布式系统的核心需求,因此,每个基于Web Service的ESB迟早都要把拦截器结合进去。

 

2.通信风格,异步通信意味着消息的发送和消息的接收者没有同步,这好比电子邮件。这里发送者面对的而一个难题就是需要一个答复,可以这并不是马上就能获得答复,这样,当应答到来的时候,必须把答复和最初的请求关联起来(例如,通过处理类似ID的东西);另外,处理答复的时候看,可能需要最初请求的时候的初始状态和上下文环境;还有,大量的异步请求发出的时候,收到应答的顺序可能不同发出的顺序,调试的时候可能非常悲剧;这样引入异步处理的逻辑变得这么复杂。

 

《ESB的消息交换》

 

3.数据类型,.NET中有DataTable类型,结合一些控件使用,非常方便,但是在使用WCF的时候,如果将它作为返回类型,那么将会散失互操作性,java中并不能引用到解释这种类型,这就是紧耦合。

 

虽然搞一个简单的数据类型是最好的,但是在一个大型的系统中,最求完美的一致性可能是一种灾难,会让你的工作停步不前;另外,在大型组织中,人们就是无法一致化意见,各个子系统的所有者有不同的利益,达成一致意见很难;另外不断变化的需求业务,也会使得模型改变。

 

在大型的系统中,数据类型如果没有一致化,那你可能需要一种适合你的“数据映射”,虽然增加了一点复杂性,但是这是一种解耦,应该避免直接依赖供应者提供的数据类型;另外不采用一致的数据模型,那么你的修改不会对其他系统直接造成影响。

 

4补偿

为了保持状态同步,可以使用称为2PC,两阶段提交的技术创建一个公共的事务上下文环境,最后执行成功的话,提交执行在两个系统,这可能是作为一个中间件的重要特性,这可能会造成死锁和延迟,并且在多个异质的平台上实现这个,会有很多技术上的复杂性。补偿可能是一种更加松耦合的方式。BPEL直接支持补偿。