系统融合(三)--组件化

现有案例分析

 

系统融合,简单的说就是把多个系统合并成一个系统。组件化,是在服务化的拆分基础上,提取可独立部署和多次服用的部分。一个是合并,一个拆分,看似矛盾,但两者却可以同时使用,相得益彰。

 

笔者在前面总结过“适配器模式和“迭代器模式在系统融合过程中的运用,并以两个公司合并进行系统融合为例讲解具体的使用方式。在实际项目中,两个公司合并的场景毕竟是少数,但在同一个公司中其实有很多类似的软件系统,也是需要融合的。为什么在同一个公司中会存在很多类似的软件系统呢?个人觉得这是“以业务驱动”的公司的通病,尤其是以“以业务驱动”的大公司的通病。当然这不能把所有的责任都推给公司的“业务人员”,主要问题还在技术架构的设计上。下面来看一个案例:

 

现在的大型电商网站的入口页面 几乎都是由首页、频道页、活动页、店铺页、商品页等组成。由于网站的各种不同促销几乎无时不刻都在进行,在这一刻看到页面内容主题背景是红色、页面上有10个商品,在下一刻就有可能背景就换成了黑色、页面上的商品换成另外的15个商品。对于不了解电商网站系统架构的朋友来说,你可能觉得这个网站是不是通过不停的修改代码,重启系统实现,但又会觉得如此频繁的上线重启系统肯定不现实。

 

真实的做法是,这些页面都是通过在线编辑系统生成的(用过QQ的人,应该都装修过自己的QQ空间;在iteye上发布自己的博客也是一个道理),“业务人员”只需要在这个称为“装修后台”的系统里调整页面的样式、以及页面上的商品,然后执行发布操作就可以生成最新的页面内容。外部用户在访问网站时就可以及时的看到页面内容的变化。这种方式可以满足业务人员和商家的快速业务变化的需求。

 

在“业务驱动”下,首页、频道页、活动页、店铺页、商品页等系统的架构,会按照各个业务线搭建各自的业务系统,整体流程和思路很清晰。如果我们把整个架构画出来,就会发现问题:

 

 

 

 

 

业务确实比较清晰和并且各个系统相互独立,一个系统出现故障不影响其他系统。但这里却存在大量重复功能,每个系统里都有一套自己的 装修工具、权限管理、页面浏览、页面渲染。这里势必会有大量的重复代码,研发人力投入成倍增加;研发人员疲于各种业务开发(很有可能每套系统都会开发一次),整天忙于开发各种业务功能,无力投入人员进行系统优化,然后各个系统继续招人。最后发现,招了一大批人来做重复的事,技术又得不到提升,进入很危险的恶性循环。

 

组件化

 

如果任由上述案例中的问题发展下去,后果是非常严重的,会直接影响整个公司技术发展的未来。出现这个现象也有一些客观的原因,比如业务方太强势、业务发展太快等等。但出现问题就要思考怎么去解决问题,“组件化”就是解决上述案例中的利器。

 

文章开头已经提到:“组件化”的前提是“服务化”,首先来看下使用组件化的思想来解决上述案例中的复用性问题:

 

 

 

可以看到,上述案例中每个业务系统中都需要重复建设的功能,被提取成公共组件,每个组件由独立的研发团队复杂开发、优化和维护。与具体业务相关的逻辑被剥离到前台系统中,可以利用现有的组件库 通过搭积木的方式快速响应“业务方”的需求。

 

通过上述架构上的调整,现在有部分研发人员可以安心的做各个“组件”的优化工作了:如果应用服务器扛不住,就拆分应用;如果数据库扛不住,就进行垂直拆分或者水平拆分,其中又包含数据库中间件建设;通过前两步拆分之后,就会形成多个“微服务”,这些服务之间的通讯又会用到“消息队列Mq”以及RPC框架来实现同步或异步的方法调用和消息传递。

 

研发团队还可以根据业务需要,创建其他新的组件,利用“技术”反向驱动业务的发展。至此 公司的整个体术体系进入良性循环:进入“技术”和“业务”双驱动阶段。

 

待这些基础组件成熟后,还可以把它们部署到云上,为其他公司提供可插拔的服务(SAAS平台)。结合云计算 为公司带来另一个利益增长点。

 

系统融合

 

这里提到的“系统融合”,其实是把各个业务相似的独立系统,融合成一个“看似相同”的同一个系统。比如前文提到的“店铺系统”,在业务发展前期可能又会被分为两个系统:pc店铺系统(电脑版)、m店铺系统(移动端)。通过进一步的分析,我们可以发现pc店铺和m店铺的商家属性、商品列表、商品库存等等其实都是一样的,唯一不同的只有页面展示不同,一个是在电脑上展示、一个是在手机端展示。这时其实就可以把这两个系统的公共部分融合成多个“公共组件”,共两个前台系统使用,这两个前台系统主要职责就是负责页面效果展示。

 

通过这个案例可以发现,“系统融合”和“组件化”拆分,这两个看似矛盾的概念,在架构设计上有时候却会同时出现。

 

有朋友会说前面讲的内容已经到了公司整体的技术架构的层级,距离我们一个小团队太遥远。其实这种“组件化”的思想 同样适用于各个小团队。仔细梳理下自己团队里的系统:你所在的团队是不是有多个项目,每个项目负责一套系统开发;是不是每个系统都有一套自己的“权限管理体系”;是不是每个系统都有自己的“worker”定时器;是不是每个系统都自己实现了一个“分布式任务调度”;是不是每个系统都有自己的一套“实时数据计算”子系统 等等。如果你的回答是,那就可以把他们都独立出来,形成自己团队内部的公共组件,由指定研发小组去把他维护到极致。

 

通过上述梳理,会发现你的团队会建立起自己的前、中台技术体系。在人效最大化的同时,团队的整体技术水平也会上升一个台阶,因为每个项目再也不用来回的copy代码做重复的事情。

 

猜你喜欢

转载自moon-walker.iteye.com/blog/2403850