|
企业 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定制化框架、数据库生成框架等…… 结尾 其实，组件化架构设计中，最为复杂是分析出一个封装完好的组件，所要面向的使用者是哪些，这些使用者分别对组件有哪些需求，而这个架构如何满足这一系列需求。例如，我们在设计过程中，对这些方面进行了分析：组件自身的发展需求、组件中各组成部分的可扩展性、组件间的交互需求、系统集成需求、项目组定制化需求、系统外交互需求、易用性。 欢迎感兴趣的朋友交流。 出处：http://www./zjjs/201502134.asp |
|
|
