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

1.引言

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

功能设置在本文中是指产品开放给企业和用户的一些功能设置项,以视频会议产品为例示意如下:
从公共业务提取来看架构演进——功能设置篇_第1张图片

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

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

2. 问题

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

  • 产品有自己的管理中心,负责管理产品下的相关设置项;
  • 具体的设置项存放在产品自己的系统中;
  • 客户端访问产品系统来操作功能设置项;
    从公共业务提取来看架构演进——功能设置篇_第2张图片

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

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

  • 每个产品维护一个功能设置模块,并存储自己产品范围内的设置数据;
  • 每个产品开发一套管理中心,来管理自己产品范围内的功能设置项;
  • 客户端访问用户的设置项,需要跨越多个产品系统,才能拼凑出一份完整的数据;
    从公共业务提取来看架构演进——功能设置篇_第3张图片

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

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

那如何解决呢?

3. 优化思路

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

3.1 业务模型演进

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

  • 所有产品的设置数据都提取到一个服务,暂且称为统一权限配置服务
  • 设置项的增删改查维护工作只做一遍,不再区分产品;
  • 客户端直接访问统一权限配置服务,一次IO就能访问和操作用户所有设置数据;
    从公共业务提取来看架构演进——功能设置篇_第4张图片

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

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

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

3.2 管理中心演进

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

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

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

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

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

如果能按模块来设计,那管理中心基本就是把各个业务的数据管理组合到一起,类似下图所示:
从公共业务提取来看架构演进——功能设置篇_第5张图片

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

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

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

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

3.3 产品开发模式演进

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

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

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

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

上面讨论的管理中心演进方向,应该是能带来一些启发和思考的,就是产品不应该是一座座孤岛,而应该是业务的组合体,就像下面图示一样。
从公共业务提取来看架构演进——功能设置篇_第6张图片

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

小结

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

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

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

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

延伸阅读

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

你可能感兴趣的:(实践案例,架构,后端)