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

这篇具有很好参考价值的文章主要介绍了从公共业务提取来看架构演进——功能设置篇。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1.引言

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

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

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

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

2. 问题

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

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

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

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

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

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

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

那如何解决呢?

3. 优化思路

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

3.1 业务模型演进

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

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

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

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

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

3.2 管理中心演进

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

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

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

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

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

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

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

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

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

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

3.3 产品开发模式演进

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

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

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

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

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

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

小结

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

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

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

所以失败并不要紧,要紧的是能不能快速爬起来。文章来源地址https://www.toymoban.com/news/detail-745469.html

延伸阅读

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

到了这里,关于从公共业务提取来看架构演进——功能设置篇的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 架构演进及常用架构

          部署 CDN 节点: 用户访问量的增加意味着用户地域的分散请求,如果所有请求都直接发送中心服务器的话,距离越远,响应速度越差,这时就需要用到 CDN 技术,通过 CDN 加速,保证用户访问每次都从最近的服务器获取数据.  分布式数据库: 分布式数据库是网站数据库

    2024年02月12日
    浏览(35)
  • 技术架构的演进-八大架构

    目录: 常见概念 评价指标 单机架构 应用数据分离架构 应用服务集群架构 读写分离 / 主从分离架构 引入缓存 —— 冷热分离架构 垂直分库 业务拆分 —— 微服务 容器化引入——容器编排架构 总结 1.常见概念: 应用(Application) / 系统(System) :为了完成一整套服务的一个

    2024年02月15日
    浏览(46)
  • 使用Mybatis自定义插件实现不侵入业务的公共参数自动追加

    后台业务开发的过程中,往往会遇到这种场景:需要记录每条记录产生时间、修改时间、修改人及添加人,在查询时查询出来。 以往的做法通常是手动在每个业务逻辑里耦合上这么一块代码,也有更优雅一点的做法是写一个拦截器,然后在Mybatis拦截器中为实体对象中的公共

    2024年02月04日
    浏览(41)
  • 【架构师】零基础到精通——架构演进

    博客昵称:架构师Cool 最喜欢的座右铭:一以贯之的努力,不得懈怠的人生。 作者简介:一名Coder,软件设计师/鸿蒙高级工程师认证,在备战高级架构师/系统分析师,欢迎关注小弟! 博主小留言:哈喽!各位CSDN的uu们,我是你的小弟Cool,希望我的文章可以给您带来一定的帮

    2024年02月02日
    浏览(87)
  • 《凤凰架构》第一章——服务架构演进史

    前言 刚开始决定弄懂文中所提到的所有东西,就像我写ByteByteGo呢几篇文章一样,把每一句话都弄懂。但是对于《凤凰架构》来说,这有点太费时间了,并且没有必要,有些东西可能永远都不会用到,但文章为了全面的介绍一个内容,会提到那些东西。所以我还是针对一些自

    2024年02月14日
    浏览(45)
  • 【架构】互联网应用开发架构演进历程

    首先我们了解下计算机软件的发展历史,大概总结概括,分为c/s时代,web1.0时代和web2.0时代。 c/s时代:富客户端方案。卖软件可赚钱。​例如 qq、影音、游戏。 1.0时代:主要是单向信息的发布,即信息门户—广大浏览器客户端​ ,互联网内容是由少数编辑人员(或站长)定制的

    2023年04月26日
    浏览(63)
  • 架构的演进

    单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式。 存在的问题: 代码耦合:模块的边界模糊、依赖关系不清晰,整个项目非常复杂,每次修改代码都心惊胆战 迭代困难:每次功能的变更或bug的修复都会导致重新

    2024年01月20日
    浏览(31)
  • 电商系统架构演进

    具体以电子商务网站为例, 展示web应用的架构演变过程。 这个时候是一个web项目里包含了所有的模块,一个数据库里包含了所需要的所有表,这时候网站访问量增加时,首先遇到瓶颈的是应用服务器连接数,比如tomcat连接数不能无限增加,线程数上限受进程内存大小、CPU内

    2024年02月08日
    浏览(34)
  • 八种架构演进

    日升时奋斗,日落时自省 目录 1、单机架构 2、应用数据分离架构 3、应用服务集群架构 4、读写分离/主从分离架构 5、冷热分离架构 6、垂直分库架构 7、微服务架构 8、容器编排架构 9、小结 特征:应用服务和数据库服务器公用一台服务器 出现场景:访问量较小,单机可以满

    2024年02月12日
    浏览(31)
  • 开放网关架构演进

    作者:庄文弘(弘智) 淘宝开放平台是阿里与外部生态互联互通的重要开放途径,通过开放的产品技术把阿里经济体一系列基础服务,像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴,推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。

    2024年02月12日
    浏览(32)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包