系统架构:通俗易懂教你理解中台

架构,简单来理解,就是架设产品的结构。

架构,离不开4个关键字:效率、适用性、稳定性、可扩展性。

  1. 效率:好的架构提升迭代效率;
  2. 适用性:好的架构可以在小修小补之下适用各个业务需求;
  3. 稳定性:系统是高可用的;
  4. 可扩展性:无需改动底层;

B 端产品需要解决企业不断发展过程中遇到的各种问题,所以随着新的商业环境、新的业态、新的模式,必然伴随着催生出新的需求。

每家企业发展的方向不同、策略不同、组织不同,都会导致需求有很多变种,在这种情况下,如何能够通过一款产品满足各种数以万计的企业,就变得异常有挑战性。

没有一个好的产品架构,是无法做到这件事的。

产品架构不好,带来的很多问题,这里不再赘述,主要包括:一碰到新需求就要改底层;改动牵一发而动全身;一碰到新需求就要大改。

我们往往会看到那种结构图,分层分区块,不同层做不同的事,不同块承担不同的角色和职能。

我们要明白所有的架构,最终都为了提效,没能提效的都不是好的架构。

01 产品架构思维

这里引入 2 个思维:

阶段一:线性化思维

就是说比如一个用户进入一个电商网站,他找到一个商品,然后下单,支付,然后商家发货,用户确认收货,交易完成。

如果我们把这些环节都做到一个线性流里,是不是发现这个产品是单层的,所有功能都有序的杂糅其中。

这样一个产品、一套代码,一旦涉及其中一个环节的改动,就会动整个产品、整套代码。

所以开始有了模块的拆分,以及前后端分离。

模块的拆分,能够很好的划分边界,即把相同目标的一些场景功能集成在一起,把不同定位的场景功能排除在外。

那么后面假如只针对A模块进行业务迭代,毫无疑问降低了对整个产品的影响,且更加容易和高效。

模块作为业务层横向的拆分,将线性化的产品变成了离散型。

毫无疑问,线性一定比离散型更快,更高效,但是随着业务的诉求日益增长,任何的快都要建立在满足需求的前提下,否则效率无从谈起。

阶段二:模块化思维

模块化到底是怎么做的呢?

举个例子,从产品角度通俗易懂的讲,比如商品,那么商品中所有的底层数据、商品相关的各种能力(比如创建商品、商品类目管理、商品上下架管理等等)都会被囊括在商品模块(中心)中。模块对外就是提供各种商品相关的接口能力。

模块化还有个好处,就是降低了产品开发的边际成本,同样的商品创建,按照线性开发我肯定还要再做一遍;但是如果集成到一个模块中,我只需要让商品模块可以支撑起他业务的商品创建,做一些轻度扩展,即可满足。

模块化按照颗粒度还可以进行拆分,比如商品模块里面,还可以拆分商品基础信息模块、商品销售信息模块、商品活动信息模块等等。

这些都视业务发展的诉求而定,比如需要针对不同类型的活动,制定不同的商品信息策略,而且这类的业务需求又多又高频,那么是有必要抽出这个模块进行单独迭代的。

模块化有一点比较负责的就是定边界,哪些该放在业务侧,哪些该放在模块服务侧。

我的原则是:高度关联且具备一定通用性的放在模块服务侧,低关联且个性化的功能放在业务开发侧。

02 什么时候需要建立中台

上面讲的是单个业务线的模块化,但是随着企业发展,多条业务线并行其实是很正常的,这个时候,每个业务线都需要用到商品,比如一家公司既要发展电商业务,也要发展农产品业务,都会涉及到商品能力的搭建。

理论上来说,如果能用一套商品模块支持 2 个业务线的商品需求,是不是能让降低至少一半的开发成本?

那么问题来了,假如用一套商品模块来支持2个业务的商品需求,会带来什么样的问题呢?

比如电商商品是按照「件」来计算数量的,农产品商品是按照 kg/g 等重量来计算数量的,也就是说商品模块需要支持 kg、g、件等各种计量单位,这还不够,涉及到退货、出入库管理、物流配送费等,都需要做额外的方案兼容。

最后整个商品模块会变得很重,任何不同业务的商品需求都会被迭代到这个商品模块中,成了一个商品中心。

如果同时有 4,5 条线在跑,且他们对商品的需求又各有差异,那么商品中心就会变的很重,这种【重】甚至会反过来影响各个业务线的商品功能,使其变得很难用。

随着越来越【重】,任何一条业务线的商品需求的变更、新增,都会带来成几倍的开发难度和工作量,因为任何一次变更、新增都要基于之前【厚重】的商品模块的产品逻辑来考虑。

这个时候中台的概念应运而生,中台某种意义上来讲,和开放平台非常相似,就是对外提供底层能力。

我们换个思路,假如,每个业务都能自己建立自己的商品中心,不用受其他业务线的商品功能的影响,是不是会更加舒服呢?

但是像前面说的,从 0 到 1 自己再建个商品中心太麻烦了,那能不能复用一些已有的能力呢?但是又可以抛弃掉一些不需要的功能。

这个时候我们就抽离出技术中台这一层概念。

03 中台要做什么?

技术中台就是对各个商品中心进行能力的抽象,为各业务线提供底层的商品能力。

而各业务线就是基于这些基础能力,去搭建自己的商品中心,做更上层的商品相关的产品功能。

这样每个业务的商品中心都只服务于自己,更加完美的契合业务需求,使用也更高效,同时基于中台能力的商品中心搭建起来也更加便捷和迅速。

所以对于中台来说,如何避免弱抽象,又不过度抽象,就变得非常有难度了。

弱抽象,就意味着有很多业务的东西夹杂其中,每次迭代都可能涉及到中台能力和接口的改动。

过度抽象,就会导致中台体现不出价值,业务开发工作依然繁重,甚至因为新增对接中台而加大工作量。

中台进阶:

那么是否这样就是一个最终形态了?并不是。

假如中台对外提供的是最基础的能力,那么对业务来说,他需要花费很多时间通过这些基础能力接口去做上层的业务拼装,并引入基础能力之外的业务逻辑,而这些业务逻辑可以由中台提供,也可以由业务自己来实现。

那么考虑到让业务效率最大化,最好的方式是什么呢?提供基础能力,其实是相对简单的,工作量的大头其实是业务。

那么假如中台能够以一种通用性的方式,帮助业务完成一部分业务需求,何乐而不为呢?

很多书中都在告诉大家,中台就只做抽象,只提供基础能力,虽然前提是对的,但是忽略了很重要的一点,中台的第一目的就是帮助业务减负,最大化业务效率。

如果做不到这点,中台再强调抽象,再强调低耦合,都对企业的发展没有太大帮助。

所以换个思路来讲,比如业务中,做营销活动的时候,不同类型的营销活动对用户参与门槛都有不同的限制,类似这样的限制规则其实非常多,10 个活动都要用到这样的限制规则,且这些规则离不开类似(是否新用户、是否用户等级大于 XX、是否活跃用户等等),既然如此,为何不为业务去提供一套整合的规则池,并提供一套门槛校验能力,进一步帮助业务减负?

这样的例子有很多。可以说这样的规则池也是一种抽象,但其实更像是枚举,因为每一个规则都可能完全不同,需要一个个建立起来。

04 技术中台的坑

中台化的能力,帮助业务减负的基础上,进一步收拢了数据,和模块化的统一管理,从逻辑上来讲,一定能够帮助企业大幅提升效率。

但是真正执行中,往往效果没有达到预期,一般主要由以下几个原因导致:

1)业务理解深度不够

没有对业务进行深度调研,导致设计的中台,业务不可用,或者难用,满足不了需求,这必然导致中台能力应用的推进难度增加,有些业务甚至脱离中台自建底层能力。

2)技术对接沟通不充分

在对接过程中,没有做好充分的技术对接沟通,导致业务开发觉得中台提供的少,中台觉得业务开发不懂中台,没有形成合作共识。

3)中台能力过于散装

上游业务组装依然复杂、需要耗费大量精力,体现不出效率的提升。

未完,实战内容待续。

#作者#

司马特小分队,公众号:司马特小分队。8年+互联网资深产品经验,多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验;主要教授产业互联网产品相关的硬核知识点。

本文

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部