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

1.引言

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

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

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

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

2. 问题

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

• 产品有自己的管理中心，负责管理产品下的相关设置项；
• 具体的设置项存放在产品自己的系统中；
• 客户端访问产品系统来操作功能设置项；
  

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

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

• 每个产品维护一个功能设置模块，并存储自己产品范围内的设置数据；
• 每个产品开发一套管理中心，来管理自己产品范围内的功能设置项；
• 客户端访问用户的设置项，需要跨越多个产品系统，才能拼凑出一份完整的数据；
  

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

• 各产品研发团队在功能设置上做的工作是相似又重复的；
• 不同产品间功能设置数据隔裂，访问和修改数据都平添了多次网络IO，同时也给维护带来了很多不便；
• 数据分散在各个产品中，管理中心也只能跟着做多套，给管理中心的统一带来障碍；

那如何解决呢？

3. 优化思路

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

3.1 业务模型演进

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

• 所有产品的设置数据都提取到一个服务，暂且称为统一权限配置服务；
• 设置项的增删改查维护工作只做一遍，不再区分产品；
• 客户端直接访问统一权限配置服务，一次IO就能访问和操作用户所有设置数据；
  

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

• 企业级设置和用户级设置需要做的合并工作；
• 产品要强制开关某些功能的需求；
• 设置项要受帐号权限控制的需求；
• 功能试用要联动设置项的需求；
• ……

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

3.2 管理中心演进

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

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

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

• 管理用户帐号；
• 管理功能配置；
• 管理各种业务功能数据，像会议、直播、会议室、白名单之类的；
• 管理各种使用统计数据，像会议统计、观众参会统计之类；

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

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

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

• 云会议管理中心，可能呈现的是会议、会议室、会议统计；
• 云直播管理中心，可能呈现的是直播、白名单、观众统计；
• 各个产品都有的是帐号权限和产品功能设置，但不同产品呈现的配置项可能有所不同；

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

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

3.3 产品开发模式演进

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

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

1. 相关业务领域的技术研究和文档积累；
2. 独立可复用的业务模块和组件；
3. 这个产品研发过程中，走错了哪些方向，做错了哪些事情，能获得什么教训；

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

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

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

小结

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

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

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

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

延伸阅读

• 从帐号权限提取来看架构如何演进：https://blog.csdn.net/xiaojia1001/article/details/134147088
• 一个功能试用模块的抽取案例：https://blog.csdn.net/xiaojia1001/article/details/132959395