系统融合（三）--组件化

现有案例分析

 

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

 

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

 

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

 

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

 

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

 

 

 

 

 

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

 

组件化

 

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

 

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

 

 

 

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

 

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

 

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

 

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

 

系统融合

 

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

 

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

 

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

 

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