目录
一、组件化与“大中台”建设
二、“组件化”与项目“微服务化”
三、“组件化”与“前端”
四、项目“组件化”改造案例
前言
最近在做一个项目,项目的名称里挂了“组件化”三个字,项目目标是整合业务逻辑、调整系统架构 最终实现一套代码多国复用,降低维护成本。单从这个项目目标来看,这跟“组件化”一点关系都没有,准确的说这个项目应该叫“国际化”改造项目。
“组件化”的结果就是把系统作为一个个“组件”独立部署并对外服务,我理解的系统“组件化”,其实是对系统 “服务化”或 “微服务化”的另一种称呼罢了。区别在于“组件”是对外的“服务”,有些“服务”是私有的不能对外。
<!--[endif]--><!--[if gte mso 9]><xml> <o:OLEObject Type="Embed" ProgID="Visio.Drawing.11" ShapeID="_x0000_i1025" DrawAspect="Content" ObjectID="_1566924396"> </o:OLEObject> </xml><![endif]-->
这里封装了一个组件名称为“组件1”,包含3个子服务系统,其中A服务对外开放,B、C服务是为了支持对外的A服务而存在的,但不对外开放。这里采用了“微服务”的思想把“组件1”拆分为三个子系统,有点类似java里的public方法和private方法,A系统对应public方法可以对外服务,B、C系统对应private方法只能在“组件1”内部被调用。这里所谓的服务都是通过RPC框架搭建的子系统,本质上是通过RPC框架(比如淘宝的Dubbo)的权限验证体系来实现是否对外服务。
一、组件化与“大中台”建设
现在一些主要的互联网公司都在推进“前中台拆分”,大力推进“中台系统建设”。 本节主要聊下中台建设与组件化的关系,以下都是个人见解。
“中台系统”(个人理解):就是由无数个通用“组件”组成,这些通用的“组件”为“前台系统”提供服务。就是所谓的各种“积木”
“前台系统”(个人理解):就是各个具体的业务线条对应的业务系统,这些系统会根据具体业务需要调用“中台系统”中各个“组件”提供的服务。简单示意图如下:
<!--[endif]--><!--[if gte mso 9]><xml> <o:OLEObject Type="Embed" ProgID="Visio.Drawing.11" ShapeID="_x0000_i1026" DrawAspect="Content" ObjectID="_1566924398"> </o:OLEObject> </xml><![endif]-->
通过这个图,可以看出:新增一个“前台业务”,只要“中台系统”足够强大,新业务可以通过调用各个公共的“组件”采用类似搭“积木”的方式,快速完成一个新业务系统开发。这应该就是阿里所谓的“小前台”、“大中台”理论基础。
好处就是快速上线、快速试错,“前台系统”只需要投入少量人力成本,就可以快速完成新产品的研发和上线,根据市场的反应再做调整。最近几天大佬们讨论亚马逊的“飞轮理论”+“两个披萨”大概也就是这个意思。
二、“组件化”与项目“微服务化”
前面提到的“前中台系统”建设,是站在公司组织架构层面来划分的。个人认为 在各自所在的项目组,也可以采用这种“组件化”的思路来进行子系统拆分,在项目组内有自己的“前中台”子系统,不管这个项目是否在组织架构上属于“前台”还是“后台”。在具体项目内部进行“前中台”子系统拆分,其实有点类似“微服务化”拆分:
上图中的“jsf服务子工程集”中的每个子工程都可以作为“组件”来看待(只是这个组件只有1个工程,但根据业务需要对每工程还可以继续模块化拆分),属于“中台系统”。
上图中的“web服务子工程集”其实就对应各种业务系统,通过调用各种基础服务堆积而成,属于轻量化的“前台”系统。只要“jsf服务子工程集”中的“组件化”做得足够强大,我们就可以在项目组最大化的复用这些公共组件,更少的人力投入,快速的实现业务开发。
通过上述讲解,得出三点结论:
1、公司层级的“前中台”组织架构调整,是广义上的“前中台”,“前台”系统更面向业务,“中台”系统跟偏向于通用的“组件化”,对内(或者对外)附能。
2、具体到项目组内部,也可以采用“微服务化”的思想把系统拆分为自己的“前中台”系统,建立属于项目自己的“大中台”子系统(对应多个组件),同样可以对内(或者对外)附能。
3、项目组内部的“前台系统”优先选择使用外部公共“组件”(为公司省钱),如果没有则在内部“中台系统”中创建自己的“组件”,时机成熟后可以把该“组件”对外服务。
三、“组件化”与“前端”
上述讲解都是围绕“后端”进行的,其实前端js、css等开发也可以按照“组件化”的思想进行拆分、独立部署 多处复用。前端开发的发展大致上分为三个阶段(站在后端的角度):
1、耦合阶段:前后端代码耦合在同一个代码工程,部署也是合并作一起部署。开发模式 一般是前端研发先构建静态页面,后端研发再根据这些构建的静态页面套到页面模板里(比如velocity、freemaker等模板)。缺点很明显,同一个页面需要开发两次,前端构建一次 后端套模板一次。
2、前后端分离阶段:前端独立开发和部署页面、js、css等,后端只提供数据接口。这样的好处是页面开发全部有前端控制,后端只需关注业务逻辑即可。但缺点也很明显,前端工作量急剧增加。另外由于数据是异步从后端获取,前端渲染页面会有闪动的情况,可以根据情况部分页面走后端渲染,只是渲染需要js、css都是从独立的静态服务器获取。
3、前端“组件化”阶段:在第二阶段我们已经把前端相关代码独立进行部署,但这无疑大大增加了前端工作量。这时我们就需要在前端进行“组件化”建设,在团队内部构建一系列自己的前端组件,其他系统可以直接使用这些组件,而不需要再次开发和部署。如下图所示:
讲到这里,也许你已经注意到所谓的“组件化”、“微服务化”、“大中台建设”都有类似的一面,只是运用的层级不同,这种提高复用性的思想可以在各个层面进行实施。
四、项目“组件化”架构案例
这里以一个非真实的项目为例(类似笔者最近做的一个项目),在这个项目“组件化”之前,是按照业务对系统进行划分,分为pc店铺、pc活动、m店铺、m活动,系统划分如下:
可能大家已经发现问题了,这里的4个业务系统很类似,但开发人员每个系统都需要独立维护一套代码:前端、装修、渲染、浏览。缺点显而易见:
1、研发资源投入多,新功能开发或修改,工作量X4;
2、相似或相同的逻辑维护4套,没有任何复用性;
3、疲于各种业务处理,没有更多的研发资源投入到新项目开发以及项目性能优化;
4、如果有一天需要新增一个业务,又需要从头到尾再开发一套。。。。;
下面我们采用组件化的思想对系统架构进行改造,分别对前、后端都进行“组件化”提取,把公共的功能模块提取为“组件”单独部署。具体的业务系统调用这些公共组件达到复用的目的。改造后的系统架构如下:
经过上图技术架构改造,项目中会提炼出一些通用的“组件”(前后端都有)。同时业务系统更加轻量化,复杂而且通用的逻辑处理直接调用通用的“组件”即可实现。我们来看下“组件化”后的优点:
1、通用的“组件”只需开发一套,可以减少研发投入;
2、通用的“组件” 可以被多个业务复用,减少维护成本;
3、节省下来的研发资源,可以投入到组件的深度优化和新业务开发,进入良性循环(亚马逊“飞轮理论”);
4、如果要新增一个业务,只需开发私有的少量逻辑即可,其他通用逻辑直接复用。
对系统组件化架构设计的理论分析就到这里,以上仅代表个人观点,如有不同意见 欢迎留言讨论,谢谢!
转正请注明出处:
相关推荐
在Android应用开发中,组件化是一种常见的架构设计方式,它将复杂的系统拆分成多个独立的模块,每个模块负责特定的功能,提高代码复用性和可维护性。本篇将深入探讨“安卓组件化开发架构,设计思路,代码大全”,并...
组件化平台架构是一种现代软件设计方法,旨在提高软件系统的灵活性、可扩展性和可维护性。本篇内容将围绕“详细的组件化平台架构”这一主题展开,详细介绍其核心概念、设计理念以及实现方式。 #### 二、组件化设计...
根据提供的文件信息,我们可以总结出关于“移动端组件化架构”的一系列关键知识点,这些知识点主要围绕移动端组件化的概念、实现方式以及具体的案例展开。 ### 移动端组件化架构概述 移动应用开发过程中,随着功能...
根据提供的信息,我们可以推断这份文档“系统架构设计师教程.pdf”是关于系统架构设计方面的教程。由于提供的部分内容仅包含重复的网址(www.TopSage.com),我们无法从中直接获取具体的教学内容。因此,我们将基于...
组件化是一种将复杂系统分解为独立、可重用和可组合的组件的软件设计方法。在Android Studio中实现项目组件化,可以极大地提高开发效率,降低维护成本,同时便于团队成员并行工作。 首先,让我们详细了解一下组件化...
2. 系统设计方法:这涉及到架构设计的方法学,比如结构化设计方法、面向对象设计方法、面向服务设计方法等。这些方法论指导架构师如何从宏观角度对系统进行设计。 3. 设计模式:设计模式是软件工程领域的一种经验...
软件架构设计是软件开发过程中的关键环节,它决定了软件系统的整体结构、组件及其相互关系,以及如何满足功能需求和非功能需求(如性能、安全性、可维护性等)。良好的软件架构设计能够确保系统在面对未来变化时具有...
《系统架构设计师教程-第4版》是一本深入探讨系统架构设计的专业教程,适用于准备进行系统架构设计学习或备考系统架构设计师资格认证的读者。本书全面涵盖了系统架构设计的基础理论、核心概念、最佳实践以及最新技术...
嵌入式系统的软件架构设计是开发过程中的关键环节,它决定了系统的整体结构和组件间的交互方式。随着技术的发展,嵌入式系统的应用领域越来越广泛,从消费电子到工业自动化,再到医疗设备,都离不开良好的软件架构...
数字化转型企业架构设计手册 本资源是关于数字化转型企业架构设计手册的详细介绍。企业架构是一项复杂的系统性工程,旨在帮助企业实现数字化转型。该手册涵盖了企业架构的总体框架、业务架构、数据架构、技术架构、...
系统架构设计师在进行架构设计时,往往需要运用多种思维工具和方法,如使用思维导图来可视化架构组件和它们之间的关系,从而更有效地沟通和协调设计决策。思维导图的优点在于其直观性和层次性,通过图形化的方式,...
统一的开发标准和自动化测试工具,如Jest和Enzyme,可以提高代码质量和检测速度,确保组件化架构的稳定性和可靠性。 总结,组件化WEB前端架构设计是应对日益复杂和多变的前端需求的有效策略。它通过模块化、低耦合...
分布式存储系统拟态化架构设计与实现 摘要:本文提出了一种分布式存储系统的拟态化架构设计与实现,以解决现有的分布式存储系统中的数据安全问题。该架构设计基于大数据Hadoop分布式文件系统,通过构建元数据异构...
系统架构设计是现代软件开发中的核心环节之一,它关乎整个系统的稳定性和可扩展性,对项目的成功至关重要。本文将深入探讨“系统架构方法”这一主题,解析系统架构设计师的角色与职责,并详细介绍几种主流的系统架构...
《2022年系统架构设计师考试:深度解析与备考指南》 系统架构设计师考试是一项针对信息技术专业人士的重要认证,旨在评估和验证考生在设计、构建和优化复杂系统架构方面的技能和知识。2022年的考试无疑是对考生们...
软件系统架构设计说明书是指导软件开发过程中的重要文档,旨在明确系统的整体结构、组件间的相互关系以及设计原则。本文档由科技有限公司XX编写,旨在为项目团队提供清晰的架构蓝图,确保系统的设计符合业务需求和...
系统架构设计的基本概念包括需求调研、需求分析、用户体验设计、系统总体框架设计、系统组件视图设计、系统数据视图设计、系统集成视图设计、系统部署视图设计、系统环境视图设计和系统安全视图设计等。 系统架构...
6. **单元测试与集成测试**:由于组件化架构的低耦合特性,每个模块都更容易进行单元测试。同时,可以设计合适的测试用例进行集成测试,确保整体架构的稳定性。 7. **持续集成与持续部署(CI/CD)**:配合Git工作流,...
3. 模块化与组件化:讨论如何将大型系统划分为可复用的模块和组件,以降低复杂性和提高代码质量。 4. 数据库设计:涉及关系型数据库、非关系型数据库(NoSQL)的选择,以及数据建模和索引优化等概念。 5. 性能优化...
软考系统架构设计师-论云原生架构及其应用范文 云原生架构是指基于微服务和容器技术的架构设计原则,它有四类设计原则:服务化、强韧性、可观测性和自动化。云原生架构可以将应用分解为多个服务,每个服务可以选择...