锐客网

  1. 首页 > 睿知 > >

如何介绍系统架构 什么是系统架构

生活知识睿知

编辑导语:做产品之前必不可少的一步就是设置好产品的系统架构 。产品在运营过程中，会不断有不同程度的需求更新，所以前期搭建好架构是非常有必要的；笔者分享了产品体系架构的构建 。让我们来看看 。
架构，简单理解就是一个产品的结构 。
架构离不开四个关键词:效率、适用性、稳定性、可扩展性 。
效率：好的架构提升迭代效率；适用性：好的架构可以在小修小补之下适用各个业务需求；稳定性：系统是高可用的；可扩展性：无需改动底层；
b端产品需要解决企业不断发展中遇到的各种问题，所以随着新的商业环境、新的业态、新的模式，必然会诞生新的需求 。
每个企业的发展方向、战略和组织都会导致多种多样的需求 。在这种情况下，如何通过一款产品让上万家企业满意，变得极具挑战性 。
没有好的产品架构，你做不到这一点 。
很多产品架构不好导致的问题这里就不赘述了，主要包括:一有新需求就改底层；改变全身；当你满足新的需求时，你必须做出重大改变 。
我们经常看到那种结构图，分层分块 。不同的层做不同的事情，不同的块承担不同的角色和功能 。
我们要明白，所有的架构最终都是为了提高效率，不能提高效率的都不是好架构 。
01产品架构思维这里引入两个想法:
阶段1:线性化思维
也就是说，比如用户进入一个电商网站，找到一个商品，然后下单，付款，然后商家发货 。用户确认接收，交易完成 。
如果把这些环节都放到一个线性流程中，我们是否发现这个产品是单层的，所有功能都是有序混合的？
这样一个产品，一套代码，一旦涉及到一个环节的变动，就会动整个产品，动整套代码 。
于是开始有了模块的拆分和前后端的分离 。
模块的拆分可以很好的划分界限，就是把同一目标的一些场景功能整合在一起，把不同位置的场景功能排除在外 。
那么，如果以后只针对模块A进行业务迭代，无疑会减少对整个产品的影响，而且会更加轻松高效 。
随着业务层的横向划分，线性产品变成了离散产品 。
毋庸置疑，线性比离散更快更高效，但随着业务需求的不断增加，任何速度都必须建立在满足需求的前提下，否则效率无从谈起 。
第二阶段:模块化思维
模块化到底是怎么做到的？
比如从商品的角度来看，很容易理解，比如商品，那么商品中所有的底层数据以及各种商品相关的能力(比如商品创建、商品类目管理、商品货架管理等 。)将包含在商品模块(中心)中 。外部模块提供与各种商品相关的接口能力 。
模块化的另一个优点是它降低了产品开发的边际成本 。同样的产品创作，我一定会按照线性开发再做一遍 。但是如果集成到一个模块里，我只需要让商品模块支持他业务的商品创建，稍微做一些扩展就可以满足了 。
按照模块化的粒度，还可以进行拆分，如商品模块、商品基本信息模块、商品销售信息模块、商品活动信息模块等 。
这些都取决于业务发展的需求 。比如需要针对不同类型的活动制定不同的商品信息策略，而这样的业务需求数量多、频率高，就需要拿出这个模块单独迭代 。
对模块化更负责的一点是定义边界，边界应该放在业务端，应该放在模块服务端 。
我的原则是:相关性高、通用性强的功能放在模块服务端，相关性低、个性化强的功能放在业务开发端 。
02什么时候需要设置中间站？以上讲的是单个业务线的模块化，但是随着企业的发展，多个业务线并行其实也很正常 。这时候各个业务线都需要用到商品 。例如，一个既想发展电子商务业务又想发展农产品业务的公司，都会涉及到商品能力的建设 。
理论上，如果一套商品模块可以支撑两个业务线的商品需求，是否可以降低至少一半的开发成本？
那么问题来了 。如果用一套商品模块来支撑两个商家的商品需求，会带来什么样的问题？
比如电商商品的数量是按照“件”来计算的，农产品的数量是按照公斤/克的重量来计算的，这就意味着商品模块需要支持公斤、克、件等多种计量单位 。，这还不够 。涉及退货、仓储管理、物流配送费用等 。，并且它们都需要额外的方案兼容性 。
最后整个商品模块会变得很重，任何不同业务的商品需求都会迭代到这个商品模块中，成为一个商品中心 。
如果有4、5条线同时运行，他们对商品的需求不一样，那么商品中心就会变得非常沉重，而这种[沉重]甚至会反过来影响各业务线的商品功能，难以使用 。
随着越来越“重”，任何一个业务线的商品需求的改变和添加都会带来数倍的开发难度和工作量，因为任何改变或添加都必须基于之前“重”商品模块的产品逻辑来考虑 。
这时，中台的概念就产生了 。某种意义上，中台很像开放平台，就是对外提供底层能力 。
我们换个思路吧 。如果每个业务都能成立自己的商品中心，不受其他业务线商品功能的影响，会不会更舒服？
但是前面说了，从0到1再建一个商品中心太麻烦了 。能否重用一些现有的功能？但是一些不必要的功能可以舍弃 。
这个时候我们就把技术上的中间阶段这个概念拉出来 。
03中间站要做什么？技术中心是对各个商品中心的能力进行抽象，为各个业务线提供底层的商品能力 。
而每个业务线都是基于这些基础能力来建立自己的商品中心，做更高层次的商品相关产品功能 。
这样各商家的商品中心只为自己服务，更完美的满足了商家需求，使用也更有效率 。同时，基于中台能力的商品中心建立起来更加方便快捷 。
所以中台很难避免弱抽象而不过度抽象 。
弱抽象意味着有很多业务的东西混在里面，每一次迭代都可能涉及到中间站的能力和接口的变化 。
过度抽象会导致中台无法发挥价值，业务拓展工作依然繁重，甚至因为新对接中台而增加工作量 。
中级高级:
那么这是最终形式吗？不完全是 。
如果中台对外提供最基础的能力，业务需要花费大量的时间通过这些基础能力接口组装上层业务，引入基础能力之外的业务逻辑，可以由中台提供，也可以由业务自己实现 。
那么最大化商业效率的最佳方式是什么呢？提供基础能力其实相对简单，工作量的大头其实是业务 。
那么，如果中台湾可以帮助企业以通用的方式满足一些业务需求，为什么不呢？
很多书告诉你，中国中台只做抽象，只提供基础能力 。虽然前提是对的，但是忽略了很重要的一点 。中国中台的第一个目的是帮助减轻业务负担，最大限度地提高业务效率 。
如果做不到这一点，中台之间强调抽象和低耦合，对企业的发展帮助不大 。
所以换个思路说，比如在商业中，做营销活动的时候，不同类型的营销活动对用户的参与门槛有不同的限制 。其实这样的限制很多 。10个活动都要用到这样的限制，这些规则都离不开相似性(无论是新用户、级别大于XX的用户、活跃用户等 。).在这种情况下，为什么不为业务提供集成的规则池和阈值检查功能呢？
这样的例子很多 。可以说这样的规则池也是一种抽象，但实际上更像是枚举，因为每个规则可能是完全不同的，需要一一建立 。
04技术中期的坑在帮助业务减负的基础上，台湾的集中化能力进一步巩固了数据，模块化的统一管理必将帮助企业大幅提升效率 。
但在实际执行中，结果往往达不到预期，一般由以下原因造成:
1)业务理解不足 。
没有对业务进行深入的研究，导致中间平台的设计，使得业务无法使用或难以使用，无法满足需求 。这必然导致中间平台的能力应用推广困难，部分商家甚至脱离中间平台自建底层能力 。
2)技术对接沟通不够 。
在对接过程中，技术对接沟通不够，导致业务发展感觉中台提供较少 。中国和台湾觉得业务发展不了解中国和台湾，没有形成合作共识 。
3)中间平台容量过于宽松 。
上游业务组装依然复杂，需要耗费大量精力，并没有体现出效率的提升 。
未完，实战内容未完待续 。
#专栏作家#Simate团队，微信官方账号:Simate团队，人人都是产品经理专栏作家 。8年互联网资深产品经验，多年B端产品管理经验 。有多个大型B端产品从0到1的孵化、重构、迭代经验；讲授各大行业互联网产品相关的硬核知识点 。
本文由人人作为产品经理原创发布，未经允许禁止转载 。
【如何介绍系统架构 什么是系统架构】题目来自Unsplash，基于CC0协议 。

    推荐阅读


    上一篇：cpi是反映什么的指标 什么是cpi指数

    下一篇：简单的立体折纸贺卡 一打开就是立体的贺卡