对组件化架构的再思考

标签: 随笔文章 | 发表时间:2012-02-15 16:18 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi


首先对上图做一个解释。原来架构设计比较多关注的是横向的分层,即数据层,逻辑层和UI层。而组件化架构必须同时关注纵向的隔离和解耦。在分层和分模块后,每一个业务组件由三层各自存在的部署包组成,包本身是一个包含了技术组件和服务组件的一个结合体。由数据层,逻辑层,界面层三层的三个业务包可以构成一个完整的具备独立功能的业务组件。在业务组件和业务组件之间通过内部ESB进行总线式集成,在业务组件内部的三个业务包仍然通过总线式注册和集成。在组件化架构设计中,需要遵循如下一些原则,这些原则有些属于传统分层架构设计中的原则:

UI层调用逻辑层,逻辑层调用数据层,不应该出现逆向调用。

业务组件间的调用,或说跨模块的调用需要通过服务组件暴露的服务接口进行,跨模块调用建议尽量是同层调用为主,即A模块的逻辑层只能调用B模块的逻辑层,而不能调用B模块的数据层。如果存在对B模块数据层的调用应该转化为B模块的业务服务后暴露到逻辑层。

对于数据库也需要考虑隔离和解耦,为了达到这点,尽量减少对数据库存储过程和关联视图的使用,数据库基本不承载任何的业务规则和逻辑。对数据库中的公用基础数据剥离到公用业务组件中。

对于系统管理,组织,权限,流程等转化为独立的平台层基础组件,为各个业务组件都需要依赖的组件。基础平台层能力如权限,安全,流程,日志等一定要抽取为公用的独立基础组件,业务组件不在承担这部分内容。

不一定要引入复杂的ESB,但是系统内部基于IOC或OSGI模式来实现总线式集成和组件热插拔。

各层提供的服务存在分级,数据层提供数据服务,逻辑层提供业务服务,UI层提供UI组件服务。平台层提供基础的技术服务和流程服务等。

如果在DDD领域驱动架构设计下,数据层转化为基础架构层,业务层转化为领域层,整体思路仍然不变。而领域驱动设计中的应用层转化为组件集成和整合层。

将跨系统的流程整合的概念引入到系统内部,各个业务组件即可以理解为独立的子系统,可以考虑这些子系统间如何通过服务组装和集成解决流程整合的问题,但是并不一定要用到BPEL。

在这种原则下,业务组件之间本身也不存在交叉依赖,业务组件之间的依赖关系是一种多层传递关系,如A组件依赖B组件,B组件依赖C组件。对于整个组件依赖关系建议是一种倒金字塔的结构,这样可以实现最大化的组件独立部署。



相关 [架构 思考] 推荐:

Memcache架构新思考

- - ITeye博客
2011年初Marc Kwiatkowski通过Memecache@Facebook介绍了Facebook的Memcache架构,现在重新审视这个架构,仍有很多方面在业界保持先进性. 作为weibo内部数据处理量最大,对数据延迟最敏感的部门,基于本厂2年多来对mc的使用心得,我在本文总结对MC架构的一些新思考.

对数据库架构的再思考

- - 人月神话的BLOG
前面在谈PaaS的时候曾经谈到过共享数据库,私有数据库的问题,在这里再谈谈在多业务系统建设过程中的数据架构模式问题. 首先来看下传统的数据交换解决方案如下图:. 业务场景为单独构建的四个业务系统,在四个业务系统中SID数据为需要跨四个应用交互和共享的数据. 传统的做法则是对四个应用存在的SID库数据进行数据集成和交换,则后续的每一个业务系统中都有全部的共享基础数据,任何一个应用的SID库数据需要通过数据交换和集成同步四份.

对组件化架构的再思考

- - 人月神话的BLOG
原来架构设计比较多关注的是横向的分层,即数据层,逻辑层和UI层. 而组件化架构必须同时关注纵向的隔离和解耦. 在分层和分模块后,每一个业务组件由三层各自存在的部署包组成,包本身是一个包含了技术组件和服务组件的一个结合体. 由数据层,逻辑层,界面层三层的三个业务包可以构成一个完整的具备独立功能的业务组件.

对CQRS/EventSourcing架构的思考

- -
开始之前想先说一下微服务架构和CQRS架构的区别和联系. 微服务架构现在很热,到处可以看到各大互联网公司的微服务实践的分享总结. 但是,我今天的分享和微服务没有关系,希望可以带给大家一些新的东西. 如果一定要说微服务和CQRS架构的关系,那我觉得微服务是一种边界思维,微服务的目的是为了从业务角度拆分(职责分离)当前业务领域的不同业务模块到不同的服务,每个微服务之间的数据完全独立,它们之间的交互可以通过SOA.

关于IT企业组织架构的一些思考

- - 博客园_首页
渡过生死线:一段恩怨,一段商战》里面讲的是金山网络的一些事情,虽然有软文的嫌疑,但是里面说的有几点我觉得非常认同. 先谈谈一般公司的组织架构把,传统的软件企业的组织架构是水平的,涉及和跨越多个部门,例如下面的一个企业的组织架构(虚拟出来的,说明而已). 首先层级非常多,从CEO到最终的开发人员,中间估计有6级别,比较臃肿.

有关云架构建设和选型的思考

- - 博客园_知识库
  最近在负责公司内部私有云的建设,一直在思考怎么搞云计算,怎么才能够把云架构设计得好一些. 本文尽量全面的列出了云架构建设和选型的考量因素.   我们主要从五个层面逐步评估云架构的建设和选型,分别是:.   计算机云经过多年的发展,由一开始的概念,慢慢发展成熟并能够推向市场,提供多种多样的服务,市场空间非常之大.

[服务器架构]微服务的深入思考

- - CSDN博客推荐文章
微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能. 举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: . 计算新的库存该存到什么地方. 计算在仓库内将库存运往正确放置点的路线. 计算仓库内指定一组订单的拣货路线. 以上这些功能(可能还会有更多)都是由单个微服务实现的.

软件架构设计分层模型和构图思考(201122)

- - 人月神话的BLOG
今天谈下架构设计中的分层思维和分层模型以及基于分层思维下的架构构图逻辑. 对于架构思维本身仍然是类似系统思维,结构化思维,编程思维等诸多思维模式的一个合集. 由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁,因此架构思维最核心的就是要理解到业务驱动技术,技术为最终的业务服务. 要真正通过架构设计来完成业务和技术,需求和实现,软件和硬件,静态和动态,成本和收益等多方面的平衡.

配用电大数据项目中的架构研究与思考

- - IT瘾-bigdata
智能电网(Smart Grid)是以物理电网为基础,将现代先进的传感测量技术、通信技术、信息技术、计算机技术和控制技术与物理电网高度集成而形成的新型电网. 电力大数据(Power Big Data)是实现智能电网的关键技术之一,它通过挖掘数据之间的关系与规律,提高电网企业在生产、经营、管理等方面的质量与效率.

微服务架构之「 访问安全 」 - 不止思考 - CSDN博客

- -
应用程序的访问安全又是我们每一个研发团队都必须关注的重点问题. 尤其是在我们采用了微服务架构之后,项目的复杂度提升了N个级别,相应的,微服务的安全工作也就更难更复杂了. 并且我们以往擅长的单体应用的安全方案对于微服务来说已经不再适用了. 我们必须有一套新的方案来保障微服务架构的安全. 在探索微服务访问安全之前,我们还是先来回顾一下单体应用的安全是如何实现的.