从公共业务提取来看架构演进——功能设置篇

1.引言

上一篇文章我们以帐号权限的提取为例，介绍了当架构跟不上业务发展时及时调整架构的一种思路。这篇文章我们以功能设置为例，进一步讨论公共业务提取这个话题。

功能设置在本文中是指产品开放给企业和用户的一些功能设置项，以视频会议产品为例示意如下：

上面示意的只是一小部分，实际场景中长期需求迭代下来的设置项很多，并且不同产品中的设置项也有所不同，但形式基本一致。

就功能设置的理解达成一致后，接下来我们进入正文，讨论下这块业务在产品多元化的过程中出现的一些问题。

最开始，当只有一个产品时，功能设置可能是这样：

这时候挺清晰的，并没有什么明显的问题。

随着产品多元化的发展，企业又上线了一些其它产品系统，系统模型演变如下：

各个产品分别做自己的功能设置，这样带来的问题是：

那如何解决呢？

我们从功能设置的业务模型、管理中心、产品研发思路几个角度来谈谈如何演进。

同前文一样，我们一样可以用公共业务提取的思路来优化局部架构，思路描述如下：

逻辑和数据统一后，能方便业务需求的后续扩展，例如：

这些需求是不区分产品的，都可以分别抽象成一套逻辑或配置，并且各个产品包括客户端其实都不用关心，这样基本就解决了功能设置的数据隔裂和重复开发问题。

之前帐号权限和功能配置都割裂在不同的产品系统中，所以管理中心只能对接不同的产品系统来实现管理，也间接导致每个产品都做了一套自己的管理中心。

当我们把功能设置和前文中的帐号权限提取并统一后，可以做进一步的思考：多个产品的管理中心有没有可能合并成一套？

可以分析下管理中心的业务范围，大概就是：

这些业务有跨产品通用的，也有各个产品中独有的，并且每个产品多多少少有一些自己的特性。如果要合并就要从设计层面下一些功夫，比如能按模块和功能特性为各个产品作配置。

如果能按模块来设计，那管理中心基本就是把各个业务的数据管理组合到一起，类似下图所示：
“>

管理员进入时可能要允许选择产品，并在不同产品形态下呈现不同的业务模块，例如：

而这些功能模块的差异，就要区分产品做不同的可见范围配置来实现，也就是上图中比较基础的模块权限配置。

管理中心的统一，主要工作在于前端和产品交互层面的统一，这里只是讨论了一种思路，仅供参考。

最近在回顾公司做过的产品，有IM类的，有任务类的，有文档类的，有视频类的，有呼叫类的等等，总结下来失败的居多，成功的则偏少。所以这里想讨论的问题是：公司投入大量资源和时间来研发一款产品，如果这款产品没有成功，那么公司能从这款产品的研发过程中获得什么？

这是最近一直在思考的问题，做产品不应该是孤注一掷，一旦失败，就团队解散，产品下线，投入打水漂。不论产品成败，企业都应该要从产品的研发过程中获得一些东西，比如：

可能第一点大家都会做，第三点偏经验类，那第二点呢？

上面讨论的管理中心演进方向，应该是能带来一些启发和思考的，就是产品不应该是一座座孤岛，而应该是业务的组合体，就像下面图示一样。
“>

如果我们把每个产品的开发都当做独立的业务模块来做，那不论产品结局如何，我们都能沉淀出一些可以复用的功能模块和业务组件。这样在下一次产品的开发时，就有可能通过复用或扩展来大大降低二次投入的成本，甚至基于积累的业务组件快速组合出一个新的产品。

本文通过对功能设置的业务提取，讨论了一种局部架构的系统演进思路。与前文的帐号权限篇有相似之处（例如功能重复的提取），也有不同之处（如数据割裂问题的讨论），算是同类话题的深入和补充，并进一步讨论了多个产品的管理中心从项目上统一的可能性。

在本文最后，介绍了一种产研效能提升思路。一款产品的成功和失败我们是无法预言的，但能不能从一款产品的研发过程中有所沉淀和收获，以及能取得多大的收获，却是我们能做的，而且这里说的沉淀与收获基本与产品成败没有关系。

既然产品允许失败，并且失败的可能性还不小，那我们要思考的就不仅仅是怎么把产品做出来，而是如果产品失败我们能从中沉淀出哪些可复用的东西，以便下一个产品能在之前的基础上快速搭起来。

所以失败并不要紧，要紧的是能不能快速爬起来。