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直接支持补偿。