您可以捐助,支持我们的公益事业。

金额: 1元 10元 50元

姓名:

邮件:

电话:

公司:

说明:

认证码: 验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   专家招募  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
企业 SOA 设计
 
作者:胡庆访 来源:博客园 发布于: 2015-02-13
来自于要资料   1267 次浏览     评价:      
 

企业 SOA 设计(1)–ESB 设计

最近为公司完成了一个 ESB 的设计。下面简要说明一下具体的设计方案。

企业 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 整个系统内部的所有组件。

1.Web Portal:ESB 对外以网站的形式公布。同时,服务调用者、提供者,都是直接使用网站提供的功能。

2.Adapter:协议的适配器组件。

3.Service Invoker:服务的同步调用器。

4.Async Invoker:异步方式的同步调用器。

5.Service Mocker:这个组件用于实体 ESB 的服务可以以 WS 等方式暴露。

6.ESB Message:ESB 内部的消息结构体。

7.Service Registry:服务的注册库。

8.Service Router:服务的路由器组件。

9.Service Router Cache Notification:路由缓存通知组件。

10.Logger:日志组件。

11.Exception Handler:异常处理组件。

12.Performance Counter:服务调用过程中的一些性能统计工具。

以下是一些详细的调用设计。

ESB 网站:

模拟服务:

服务的调用:

服务调用过程中的管道模块设计:

路由表及路由更新:

适配器:

最后,是最重要的持久化的领域实体:

本篇写到我们的 SOA 设计分为两个层面来进行:一个是系统间的 SOA 设计,主要通过 ESB 来完成;另一方面则是单个应用系统内部的 SOA 设计,下边将会就后者进行详细说明。

企业 SOA 设计(2)–组件化产品开发平台

平台整体结构

在产品开发过程中,为了达到业务级别的较大粒度重用,我们需要把纵向把业务进行拆分,以业务组件的形式进行开发,并最终把多个开发完成的业务组件进行组合,形成最终的软件产品。

按照组件化开发的产品,是基于一个公共的产品开发平台来建立的。由平台来提供所有的底层设施。平台包括技术平台和业务平台两个层面。在技术层面上,平台提供了一系列的类库、框架、组件、工具,以及为业务组件化提供相应的技术支撑。在业务层面上,业务平台中积累了大量的封装完善的业务组件,以及一些常用的业务控件,以供开发新产品时进行选配。同时,平台还为整个软件过程提供一系列的其它支持,例如工具、设计器、管理界面等。

下图,是平台的整体结构图:

图中罗列了大部分的关键组成部分,细节本篇不述。

组件集成平台

对于一个独立的业务,我们可以将其封装为一个独立的业务组件,并最终放到组件库中。业务组件之间,则以服务、事件两种形式进行交互。要支持这种模式的交互,技术平台还需要提供几个技术框架:插件平台、服务容器、事件总线。

下图是组件集成架构:

1.技术平台提供事件总线、轻量级服务总线。

2.组件内部以领域驱动的模式开发,以领域实体框架作为基础框架。组件内、组件间,也都是面向领域实体来进行交互。

3.组件向外部的其它组件提供组件事件、组件服务。外部组件也只能直接调用组件提供的服务,或者监听组件的事件。

4.组件还提供了一些可重用的 UI、一些可直接使用的分布式服务。

5.整个应用系统在组合多个业务组件后,再开发一些特定的功能、UI 就可以完成一个完整的系统了。

产品构成

下图是一个完整产品的组件构成图:

由于我们的产品开发平台必须要支持 721 客户化定制,所以同一个业务组件还对应不同的业务通用级别进行划分:Organization Common 表示组织架构组件最通用的部分,Org Part1 表示组织架构组件的可选包。而 Customiztion 则可以对引用的业务组件做深入的定制和扩展,而不需修改引用组件的代码。

可以看到,对于整个产品来说,在引用了业务组件库中的一些业务组件后,就可以组成了产品的基础功能。Customer App Component 中是应用系统在组件的功能基础上需要再做的工作:完成产品的额外功能,并通过平台接口为一些组件做相关定制。

组件内部架构

对于单个的业务组件,其内部的架构依然采用领域驱动的分层架构:

图虽大,但并不复杂,就是领域驱动的经典分层:Distribute(DTO 接口层)、Application(应用层/领域逻辑层)、Repository(仓库)、Domain(领域实体)。

重点在于 Domain 包,它不但包括领域实体,还包括了组件事件、组件服务接口,这些都是领域的核心。

位于底层的技术平台,提供一系列支持:IOC/AOP、属性扩展框架、领域实体框架、721定制化框架、数据库生成框架等……

结尾

其实,组件化架构设计中,最为复杂是分析出一个封装完好的组件,所要面向的使用者是哪些,这些使用者分别对组件有哪些需求,而这个架构如何满足这一系列需求。例如,我们在设计过程中,对这些方面进行了分析:组件自身的发展需求、组件中各组成部分的可扩展性、组件间的交互需求、系统集成需求、项目组定制化需求、系统外交互需求、易用性。

欢迎感兴趣的朋友交流。

   
 订阅
  捐助
相关文章

阻碍使用企业架构的原因及克服方法
世界级企业架构的行业挑战
企业架构和SOA架构的角色将融合
什么最适合您的组织?
相关文档

企业架构与ITIL
企业架构框架
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

企业架构设计
软件架构案例分析和最佳实践
嵌入式软件架构设计—高级实践
企业级SOA架构实践
 

专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS


面向应用的架构设计实践
单元测试+重构+设计模式
软件架构师—高级实践
软件架构设计方法、案例与实践
嵌入式软件架构设计—高级实践
SOA体系结构实践

相关咨询服务
应用架构设计与构建


锐安科技 软件架构设计方法
成都 嵌入式软件架构设计
上海汽车 嵌入式软件架构设计
北京 软件架构设计
上海 软件架构设计案例与实践
北京 架构设计方法案例与实践
深圳 架构设计方法案例与实践
嵌入式软件架构设计—高级实践
更多...   
 
 
 实录  架构级性能评测
主讲:高楼
性能优化专家
 
 实录  企业架构建模
 主讲:俎涛
 火龙果软件创始人
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号