对组件化架构的再思考

标签: 随笔文章 | 发表时间: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层. 而组件化架构必须同时关注纵向的隔离和解耦. 在分层和分模块后,每一个业务组件由三层各自存在的部署包组成,包本身是一个包含了技术组件和服务组件的一个结合体. 由数据层,逻辑层,界面层三层的三个业务包可以构成一个完整的具备独立功能的业务组件.

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

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

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

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

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

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

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

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

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

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

从单体架构迁移到微服务, 8 个关键的思考、实践和经验

- - 互联网 - ITeye博客
随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多. 去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上. 毋庸置疑,微服务的理念正在席卷整个开发者社区,像Netflix、Uber这样的公司都是非常成功的应用案例.

终极思考

- wei - 牛博国际
我的海淀剧院演讲门票放出后,八小时卖了四百多张,同事们说,日. 我淡淡地说,别这样,也许正是因为便宜才这么好卖嘛. 一转身我马上就打电话给老婆,操. 早知道就他妈把票价定高一点啦,真倒霉......干. 很大程度上,这可以解释两件事:1.为什么已婚事业男性的健康状况会相对好一些. 2.为什么在社会上受到尊重和认可的事业男性在老婆的眼里都是傻逼.