系统组件化架构设计

目录

一、组件化与“大中台”建设

二、“组件化”与项目“微服务化”

三、“组件化”与“前端”

四、项目“组件化”改造案例

 

前言

 

最近在做一个项目，项目的名称里挂了“组件化”三个字，项目目标是整合业务逻辑、调整系统架构 最终实现一套代码多国复用，降低维护成本。单从这个项目目标来看，这跟“组件化”一点关系都没有，准确的说这个项目应该叫“国际化”改造项目。

 

“组件化”的结果就是把系统作为一个个“组件”独立部署并对外服务，我理解的系统“组件化”，其实是对系统 “服务化”或 “微服务化”的另一种称呼罢了。区别在于“组件”是对外的“服务”，有些“服务”是私有的不能对外。

 
<!--[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、如果要新增一个业务，只需开发私有的少量逻辑即可，其他通用逻辑直接复用。

 

 

对系统组件化架构设计的理论分析就到这里，以上仅代表个人观点，如有不同意见 欢迎留言讨论，谢谢！

 

转正请注明出处：

http://moon-walker.iteye.com/blog/2393310