SOA、ESB、NServiceBus、云计算 总结
SOA
SOA 是通过功能组件化、服务化,来实现系统集成、解决信息孤岛,这是其主要目标。而更进一步则是实现更快响应业务的变化、更快推出新的应用系统。与此同时,SOA 还实现了整合资源,资源复用。
SOA 服务的设计标准是粗粒度、高重用、灵活、标准。性能则并非首要考虑因素。
SOA 的两大功能是集成、服务编排(BPEL、BPM)。WF 在 SOA 架构中,实现服务编排的功能。
参考架构:
相关资源:
ESB
ESB 是 SOA 的重要实现手段。ESB 实现 SOA 时,它作为中心、媒介,集成的系统将只与它进行交互。而 ESB 实现与各种系统间的协议转换、数据转换、透明的动态路由功能(基于内容)。
在设计 ESB 时,集中的分发模块会影响性能、可伸缩性、容错能力,所以 ESB 要有良好的可伸缩性,支持集群。
IBM 总结了 ESB 的功能,较完整的功能如下:
通信 | 服务交互 |
|
|
集成 | 服务质量 |
|
|
安全性 | 服务级别 |
|
|
消息处理 | 管理和自治 |
|
|
建模 | 基础架构智能 |
|
|
而最低要求的 ESB 需要具有的功能:
通信 | 集成 |
|
|
服务交互 | |
|
相关资源:
NServiceBus
NServiceBus 是 .NET 平台上最受欢迎的一个开源 ESB 框架。有较完善的文档及示例代码。
目前,.NET 平台上开源的 ESB 框架,大多基于消息队列来实现。NServiceBus 同样也使用消息队列机制来实现消息的传递,例如可以使用 MSMQ。由于消息队列天生就是异步传输的,所以 NSB 也同样只支持异步消息,是一种‘发送即忘却’的模式。(As a general purpose communications technology, WCF does not enforce the queued messaging paradigm. NServiceBus does, and the architectural implications are profound.)。
NServiceBus 相对于 WCF 的优势在于:事件驱动的架构(发布、订阅)、更好地支持长时间运行的工作流。
缺点一:只支持异步的消息机制的问题是,无法进行传统的的数据查询。(To allow clients to perform queries, it is best not to use NServiceBus. Messaging is designed for non-blocking operations, and queries are (for the most part) operations for which the user wishes to wait.)
如果一定要使用 NSB 来实现数据查询,那么只能通过 CQRS 来进行系统的设计:
缺点二:NSB 的服务可以轻易集成到 WCF 中使用 MSMQ 实现,但是反之则不行。也就是说,已经使用 WCF 开发的服务,是无法使用 NSB 来完成简单的迁移的。(原因也主要是因为 NSB 的异步机制。)
相关资源:
infoq 官方采访介绍:NServiceBus——让创建企业级.NET系统更加容易
NServiceBus---最流行的开源企业服务总线 for .Net
云计算,及与 SOA 的关系
云计算是一种部署体系结构,而 SOA 则是企业 IT 的体系结构。
SOA与云整合既带来应用和业务流程灵活的虚拟化和节省的费用(云),又带来原有应用的集成应用及业务流程的敏捷重构(SOA)。
上层基于 SOA 进行应用服务的开发,底层基于云计算进行资源整合,包括存储,网络,数据库,服务器等。
目前业界比较多的观点赞同:SOA 与云计算将整合发展。
它们的关系:
- 从产生的背景和原因看,SOA产生的原因是为解决企业存在的信息孤岛和遗留系统这两大问题。云计算产生的原因是企业的信息系统数据量的高速增长与数据处理能力的相对不足,还有计算资源的利用率处于不平衡的状态。
- 从关键的技术和属性看,通过产生背景和原因的分析,SOA和云计算是不同的概念,但是它们却互相联系,又有一定的相似性。从服务角度来看,SOA实现了可以从多个服务提供商得到多个服务(一个服务便是一个功能模块),并通过不同的组合机制形成自己所需的一个服务;云计算实现了所有的资源都是服务,可以从云计算提供商购买硬件服务、平台服务、软件服务等,把购买的资源作为云计算提供商提供的一种服务。
- 从关键技术来看,SOA需要实现业务组件的可重用性、敏捷性、适应改变、松耦合、基于标准;云计算则需要虚拟化技术、按需动态扩展、资源即服务的支撑。
- 从应用场景来看,当企业的业务需求经常改变的时候可以考虑使用SOA;当企业对IT设施的需求经常改变或者无法提前预知的时候可以考虑使用云计算,当有大量的批处理计算的时候也可以考虑使用云计算。
- 从应用的侧重点来看,SOA侧重于采用服务的架构进行系统的设计,关注如何处理服务;云计算侧重于服务的提供和使用,关注如何提供服务。
- 从商业模式来看,SOA可能会降低软件的开发及维护的成本,商业模式是间接的,需要落地;云计算根据使用的时间(硬件)或流量(带宽)进行收费,具有明确的商业模式。
下面列出最近看的与本文相关的一些 pdf 书籍,东西太多,不上传了,列下书名:
《中国SOA最佳应用及云计算融合实践》、《SOA in the Real World》、《SOA应用案例分析及设计》、《A Developer’s Guide to the Microsoft .NET Service Bus》、《IBM ESB概要设计说明书@CBOD》、《Mule+ESB+Studio+v3.3安装使用手册》、《软通动力 兰州ESB平台项目详细设计说明书》、《SOA实践者指南》、《基于.NET+Framework+WCF的面向服务SOA中间件设计》、《基于WCF的SOA框架设计》、《IBM-ESB 在 SOA 内的工作角色》、《WSSF(服务工厂)架构剖析》、《开源SOA快速入门指南》、《Composite Software Construction》、《Enterprise Integration Patterns - Designing Building and Deploying Messaging Solutions》、《Enterprise SOA Adoption Strategies》、《Prentice.Hall.SOA.with.NET.and.Windows.Azure.May.2010》。
企业 SOA 整体方案
在前一篇《SOA、ESB、NServiceBus、云计算 总结》中说到,SOA 是面向服务的架构,其核心思想是把业务进行组件化,而业务组件的能力服务化。
我们的整个 SOA 的设计分为两个层面:一个是系统间的 SOA 设计,另一个则是单个系统内的 SOA 设计。系统间的 SOA 设计,主要是设计一个 ESB 系统来实现各业务系统间的交互。而系统内部的 SOA 设计,则是建立一个组件化的技术平台,使得系统的开发能以一个个业务组件的形式完成,并通过技术平台来实现各业务组件的组合与互连。
一般说的 SOA 设计,都是在讲如何进行系统间的互连,例如如何进行 ESB 的设计。但是,不论是系统间互连,还是系统内部的组件化,其实都是 SOA 思想在不同层面上的体现。而我认为,应用系统内部的 SOA 设计,会更重要。因为它不但是一个低耦合、高复用的产品设计,而且也为系统间的 SOA 提供了更好的支持。
本文,主要说明如何实现 ESB 的设计。而更重要的应用系统内部的组件化产品开发平台,则留到下一篇。
ESB 目标功能
在前一篇中,列出了一个较完整 ESB 应有的功能。SOA 不但包括简单的系统间互边的功能,也应该包含更高级的 BPM 业务流程编排的功能。
下面,简单列出了我们对于我们的 ESB 的功能树:
图中,功能按优先级进行了排序。第一个阶段,只会实现其中红色的部分。而服务编排,则放到了最后。红色部分,是一个 ESB 应该具有的最小功能集。在交互模式部分,我选择了实现‘响应/请求’模式,这种交互方式在系统间互连时场景相对较少,但是不需要引用 MSMQ 等功能,所以实现起来会更简单。
ESB 主体设计
对于 ESB 的主体设计,是参考了网上另一个 ESB 的设计,下面是它的设计图:
ESB 详细设计
首先,规划出 ESB 整个系统内部的所有组件。
- Web Portal:ESB 对外以网站的形式公布。同时,服务调用者、提供者,都是直接使用网站提供的功能。
- Adapter:协议的适配器组件。
- Service Invoker:服务的同步调用器。
- Async Invoker:异步方式的同步调用器。
- Service Mocker:这个组件用于实体 ESB 的服务可以以 WS 等方式暴露。
- ESB Message:ESB 内部的消息结构体。
- Service Registry:服务的注册库。
- Service Router:服务的路由器组件。
- Service Router Cache Notification:路由缓存通知组件。
- Logger:日志组件。
- Exception Handler:异常处理组件。
- Performance Counter:服务调用过程中的一些性能统计工具。
以下是一些详细的调用设计。
ESB 网站:
模拟服务:
服务的调用:
服务调用过程中的管道模块设计:
路由表及路由更新:
适配器:
最后,是最重要的持久化的领域实体: