组件化的业务系统架构观念据说已经提出来20多年了,可是至今没有见到让人信服的组件化业务系统(注:组件化≠模块化).关于业务组件是什么,长什么样子,如何实现,又有什么样的远景? 大家也都做了很多思考和讨论.
看了社区里的一些内容,再加上平时跟同事们的交流和讨论,对组件化业务系统的实现产生了一点想法。下面我说下我的想法,欢迎大家来拍砖讨论。
我觉得目前大家对业务组件有一个共识:就是各个业务组件相对独立,并且具有可组装性和可插拔性。
每个组件的运行仅依赖于平台或者容器,组件与组件之间不存才直接的耦合关系。同时,组件与组件之间又并非绝对的独立。组件经过组装后可以与其他的组件进行业务上的交互。比如销售组件与财务组件,一笔销售业务的完成必定会产生一笔或几笔财务的业务,如销售发票的开出和一笔新的应收应付或者现金银行的记账。又比如,采购与库存管理,当采购的需求被提出,那么是不是要先看看仓库是不是有存货呢?如果本仓库没有,是否允许从其他仓库调拨呢?等等等等……,诸如此类的业务场景无法穷尽,而不同行业不同规模的用户他们的业务过程又各自不同。
也就是说,组件之间的交互在业务上存在着不可规范和不可穷尽的特点.这是个比较头疼的问题,暂且记下,稍后再做讨论。
另外,我的理解:组件化是介于模块化与应用系统集成之间的一个概念.关于组件化、模块化、应用的不同,社区中的一篇文章写得很好。这篇文章的最后,提到了组件化不同于模块化,引文:模块化开发不同于组件开发,模块化开发只是在逻辑上做了切分,物理上(开发出的系统代码)通常并没有真正意义上的隔离,一切都只是在文档中。文章中间也提到过组件化与应用集成的不同,引文:EAR或者WAR部署的是一个企业应用,请注意EJB规范中明确说:The Enterprise JavaBeans architecture is a architecture for the development and deployment of component-based (distributed) business applications(EJB 2.x和3.x唯一的区别是2.x有distributed),它们有自己的应用域,彼此相互隔离(简单的看,它们有各自独立的会话管理)。.NET也是有自己的应用域概念。
根据上面所描述,结合我把组件化放置到模块化和应用集成之间的定位。组件化应比模块化更独立,但比应用集成结合得更加紧密。借助上面提到的那篇文章分析的,引文:基于应用的部署导致了三个隔离问题:交互(界面)隔离、程序访问隔离和数据隔离.来看看组件化、模块化、应用集成的区别,以更清晰的看清楚组件化的位置。
|
用户交互(界面) |
程序访问 |
数据 |
模块化 |
统一 |
模块间直接依赖访问 |
统一存储 |
应用 |
独立 |
对外部开放访问接口 |
独立 |
组件化既然是介于上面两者之间的,那么这三个方面又该如何定位,如何实现呢?
1. 界面交互
我认为用户交互应该统一,因为组件化的各个业务组件最终拼装成同一套企业应用,UI作为用户操作接口,必须看起来是统一的而不是独立的。这一点与模块化实现的各种系统类似,虽然属于不同的模块但用户界面使用起来始终如一。另外,开发和部署上我认为应该根据组件不同来分离。
于是矛盾出现了,既然要看起来统一,又要可以分开来开发,可以分开来部署。首先如何保证不同的开发小组开发出的界面风格一致。其次分开部署使用什么手段整合到一个界面中呢?
针对第一个问题我们可以模仿模块化开发的经验,复杂一点:使用统一的UI工具开发;简单一点:也可以基于约定。至于UI整合的事情我们可能需要有一个门户组件来搞定了。
2. 程序访问
这个问题比较纠结。
基于“组件仅依赖于平台运行,而不依赖其他组件运行”这个前提.组件之间的交互就不能像模块化那样直接访问。那么像应用集成那样开放访问接口如何呢?
我认为也不妥。为什么呢?让我们想一下系统集成发生的场景。某公司已经有一套某业务领域的系统,现在又要上另一套其他业务领域的系统。当这两套系统在业务上出现了交互时,找来两套系统的开发商,制定方案,进行二次开发,彼此开放接口修改程序相互调用。从这里我们可以看出,这种方案首先从诞生的那天起就是一个出于无奈的方案。注定被结合的两方不够紧密,其次开放访问接口存在一定的安全隐患。另外,加上我们前面留下的那个难题:“组件之间的交互在业务上存在着不可规范和不可穷尽的特点。”这样的集成方案是不是不适合我们的组件呢?首先,组件之间会存在如此频繁复杂的交互,我们需要更紧密的结合,或者说是无缝的结合。另外,我们在开发组件的时候,不可能预想到那么多的其他组件它们期望从我们这里得到什么,我们不可能事先为它们准备那么多的服务接口。
那么程序间的访问,又有什么样的介于模块化和应用集成两者之间的方案呢?这个平衡点在哪里呢?我有个还不太清晰的想法,这里提一下,大家来拍吧。
先说一下常规的方案.比较常规的想法,可能多数人(包括我)会想到引入总线,或类似于主板和插槽的概念,把我们的组件插上去,组件与总线结合,通过总线与其他组件实现交互。这样做确实能实现交互和通信,可我总觉得这样的方案不是最好的,组件的结合还是不够直接不够紧密,依然存在我们无法穷尽哪些服务需要提供给总线,供其他组件调用的问题。而且,既然是总线就有类似于带宽的问题,当业务高峰期,组件间的交互频繁,势必会发生拥堵,带来效率问题.
我认为我们需要更灵活、更直接的组装结合.
我们来创造一个“粘合层”或者“胶水层”怎么样?由“胶水层”来负责各个组件之间的交互和粘合问题.组件的组装,我们经常比喻成搭积木或者拼图。但实际上我们不能够像积木和拼图那样,事先定义出明确的尺寸大小和足够的插槽或接口,我们的组件实际形状是比较灵活的、形状不一、大小不一的。对于这样形状体的组合,我认为使用强力“胶水”来粘合比较合适。当我们选定了两个组件,并要将他们联合起来使用的时候,我们在中间涂上一层“胶水”把他们粘合起来,“胶水”实际是一种导体,它作为信息传输的介质,在两个组件中进行程序的调用和数据的传输。某一个组件可能会与多个组件进行结合交互,我们在它们之间分别加入“胶水”进行组合,使他们之间各有单独的组合介质,而不是统一通过唯一的总线。这样可以让组合更加灵活,交互更直接。
至于胶水层的实现问题,可能需要一些技术上的突破。需要进一步的探讨研究。目前考虑Python或者Ruby这样的动态语言。这里存在有诸如:事务控制,同步异步,并发控制等问题,也需要进一步研究。
另外,引入胶水层可能会对人员的布局产生一些影响。不仅仅有负责各种组件开发的开发团队,还可能需要有负责胶水组合的实施团队(这个实施团队貌似技术门槛有些高,我们可能需要考虑做一个工具来减轻这个团队的技术门槛,使之尽可能多关注业务,少关注技术。当然,对于经常组合的组件我们会积累下他们之间的“胶水”代码来复用)。
3. 数据
介于模块化与系统集成之间。我认为各组件的业务数据应该分别存储,各个组件数据库上实现大部分的数据自治。这部分自治的数据包括业务数据和元数据,至于主数据考虑使用冗余的方式,通过引入主数据组件来同步分发给各个业务组件。注意,这里我们叫做“主数据组件”,而不叫做“主数据总线”,表示其在系统中的地位与其他组件无异。
关于查询和统计分析。简单的查询,数据仅涉及本组件内的,可以直接查询本组件内数据库获得。一些跨组件数据的查询或者报表、报告,考虑进行数据抽取进入BI组件,利用BI组件进行分析。
我简单画了一个基于业务组件的系统的布局图,也顺带提一下关于容器的事情。
每个容器内可以部署1-N个业务组件,容器可以有多个(注:容器≠物理服务器,一台物理服务器上可以有多个容器)。组件间的程序调用通过胶水层实现粘合,与本容器内或其他容器内的组件进行交互(胶水图上不好画,就不画了)。这些组件中包括我们的功能权限组件、数据权限组件、主数据管理组件等一些我们常称之为系统级组件的组件。另外,需要有一个对用户的出口,必须有一个容器上需要部署门户组件。门户组件将其他业务组件的操作界面嵌入到用户页面中,提供一致的人机交互出入口。
上面这些只是些想法,尚未形成实际的方案,这里先发出来抛个砖,大家集思广益一下能扔块玉回来就最好了。
提供该文档的机构为 OECP社区,更多的博客文章可以到 OECP社区查看。该文档附件欢迎各位转载,但是在没有获得文章作者许可之前,不得对文章内容或者版权信息进行更改,版权归 OECP社区所有,仅此声明。
分享到:
相关推荐
基于组件化的电商网站前端系统的设计与实现.pdf
采用组件化设计思路保证整个操作系统的可移植性、可裁减性和高配置性,方便应用跨平台。本文针对无线传感网络的特点,提出了一种操作系统组件化设计方法,在保证系统的较高性能的同时,通过设计硬件模块抽象层等来...
基于组件化的电商网站前端系统的设计与实现
基于标准URL的iOS路由系统,可实现业务模块组件化,控制器之间零耦合,可实现黑白名单控制,可进行native降级到hybrid。 软件开发设计:PHP、QT、应用软件开发、系统软件开发、移动应用开发、网站开发C++、Java、...
包含前端、后端、移动开发、操作系统、人工智能、物联网、信息化管理、数据库、硬件开发、大数据、课程资源、音视频、网站开发等各种技术项目的源码。 包括STM32、ESP8266、PHP、QT、Linux、iOS、C++、Java、python...
组件化的可配置旅行社门户系统的设计与实现,刘太轩,刘传昌,随着中国互联网技术和电子商务的高速发展,以携程网为代表的一批新型B2C旅游电子商务网站快速崛起。传统旅游企业和旅游创业企业都
论文《基于异构多核体系与组件化软件的嵌入式系统研究》
这些功能整体实现思路基本一致,但是大部分项目都需要实现一次,这无形中就形成了巨大的资源浪费。本项目就是针对这个问题,提供了一套通用的权限解决方案----品达通用权限系统。 品达通用权限系统基于SpringCloud...
半导体生产线组件化计划与调度仿真系统的设计与实现,李莉,乔非,针对半导体生产线计划与调度特点,建立了半导体生产线计划与调度通用结构模型(包括物理层、配置定义层、过程信息层、计划调度层)�
基于android平台h5组件自动化测试系统设计与实现
这是一款功能简单实用的在线考试系统,后台采用springboot开发,前台采用vue.js。...系统前后端分离,前端组件化。后端采用SpringBoot+JPA++Swagger2+JWT校验; 前端采用Vue+AntDesign,组件化拆分,方便维护和二次开发
智能电视操作系统组件层自动化测试的实现.pdf
#资源达人分享计划#
万绿测试工具组件化开发平台"是编写驱动模块程序的新方式,可以实行测试工具插件设计,快速开发,界面统一。...这样测试程序的代码是独立的,任何一个测试工具的修改不会影响其他,这样测试工具能实现组件化开发。
智能电视操作系统组件层自动化测试的实现.rar
该文设计并实现了一种基于分布式组件技术的监测网络系统,能够实现各种实时监测和非实时监测功能,具有良好的可扩展性,并实际应用于全国短波监测系统中。现代监测网络系统由一套完整的信号检测、传送、分析、控制和...
只需一行代码搞定pdf的框架,x-easypdf基于pdfbox构建而来,极大降低使用门槛,以组件化的形式进行pdf的构建。简单易用,仅需一行代码,便可完成pdf的操作 特性 轻量级 仅添加pdfbox相关依赖,无其他任何依赖 简单...
基于vue3实现的svg可视化web组态编辑器,可无需修改代码动态添加svg组件,可直接把 svg 文件和 vue 组件作为编辑器图形库使用,赋予其缩放和旋转等功能,并支持自定义拓展参数,实时控制组件状态等,主要用于物联网...
包含前端、后端、移动开发、操作系统、人工智能、物联网、信息化管理、数据库、硬件开发、大数据、课程资源、音视频、网站开发等各种技术项目的源码。 包括STM32、ESP8266、PHP、QT、Linux、iOS、C++、Java、python...
它的作用是提供一种系统性的方法,以有效地应对挑战、优化流程或实现目标。以下是方案的主要作用: 问题解决: 方案的核心目标是解决问题。通过系统性的规划和执行,方案能够分析问题的根本原因,提供可行的解决...