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

司马特小分队 2023-07-29 02:33:02

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

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

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

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

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

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

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

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

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

01 产品架构思维

这里引入 2 个思维：

阶段一：线性化思维

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

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

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

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

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

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

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

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

阶段二：模块化思维

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

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

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

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

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

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

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

02 什么时候需要建立中台

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

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

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

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

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

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

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

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

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

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

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

03 中台要做什么？

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

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

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

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

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

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

中台进阶：

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

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

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

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

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

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

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

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