[size=large]SOA 架构[/size]
SOA,面向服务架构,它强调系统之间以标准的服务方式进行交互,各系统可以采用不同的语言、不同的框架来实现,交互则全部通过服务的方式进行。
缺点:
1.服务多级调用的延迟,a->b,b->c,这样会带来大幅度的延迟。
2.调试\跟踪困难
3.更高的安全/监测要求
4.现有应用移植
5.Qos的支持
每个服务提供者能够支撑的访问量是有限的,因此设定服务的Qos非常重要,尽可能的采取一系列措施来保障Qos,如流量控制、机器资源分配。
6.高可用和高可伸缩
7.多版本和依赖管理
从标准上看,SCA提供了清晰的发布服务、调用服务及无缝和现有应用集成的支持。
在调试/跟踪的支持上SCA标准中没有明确的定义,依赖管理上也没有明确的定义。
ESB和SCA不同,它并不是由多个厂家联合指定的SOA实现标准,可以认为ESB只是个概念,核心思想是基于消息中间件来实现系统间的交互。系统间交互的数据格式采用统一的消息格式,由总线完成消息的转化、路由,发到相应的目标应用。
在统一服务调用方式上,可以认为ESB中的消息方式承担了这一功能,且支持多种通信及交互(同步、异步)方式,在调试/跟踪支持上没有定义,在依赖管理上,由于所有交互都通过总线来进行,可以根据消息的流转来判断和形成各个系统的依赖关系。在高性能和高可用这两点上,则取决于实现框架。
SOA,面向服务架构,它强调系统之间以标准的服务方式进行交互,各系统可以采用不同的语言、不同的框架来实现,交互则全部通过服务的方式进行。
缺点:
1.服务多级调用的延迟,a->b,b->c,这样会带来大幅度的延迟。
2.调试\跟踪困难
3.更高的安全/监测要求
4.现有应用移植
5.Qos的支持
每个服务提供者能够支撑的访问量是有限的,因此设定服务的Qos非常重要,尽可能的采取一系列措施来保障Qos,如流量控制、机器资源分配。
6.高可用和高可伸缩
7.多版本和依赖管理
从标准上看,SCA提供了清晰的发布服务、调用服务及无缝和现有应用集成的支持。
在调试/跟踪的支持上SCA标准中没有明确的定义,依赖管理上也没有明确的定义。
ESB和SCA不同,它并不是由多个厂家联合指定的SOA实现标准,可以认为ESB只是个概念,核心思想是基于消息中间件来实现系统间的交互。系统间交互的数据格式采用统一的消息格式,由总线完成消息的转化、路由,发到相应的目标应用。
在统一服务调用方式上,可以认为ESB中的消息方式承担了这一功能,且支持多种通信及交互(同步、异步)方式,在调试/跟踪支持上没有定义,在依赖管理上,由于所有交互都通过总线来进行,可以根据消息的流转来判断和形成各个系统的依赖关系。在高性能和高可用这两点上,则取决于实现框架。