1

中台 2023

 1 year ago
source link: https://xargin.com/complete-deah-for-middleplatform/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

中台 2023

Apr 24, 2023 8 min read

眼看他起高楼,眼看他宴宾客,眼看他楼塌了。

AI 浪潮之下,人的思考渐渐连机器都比不上,这些一直存在脑子里的知识应该都放出来也没什么关系了。

我在 2019 年在某司从业期间,曾经写过一篇《中台的末路》,从一线工程师和架构师的视角来思考当前大公司内部的中台架构到底会碰到什么样的问题。在我离职之前,有一些问题已经有了明确的答案。有一些还没有,后续加入猫厂下公司也是为了验证我的困惑,在另外一个环境下看是否已经有人铺好前路,搭好路灯,为后来人指出了方向。

业界一般把中台分为两个类型,数据中台和业务中台,前者主要指大数据、实时计算的技术栈封装,以及公司内的数据资产沉淀、管理和治理。这其中的数据治理需要与公司的业务场景结合进行设计,但数据中台中 80% 的技术其实和业务本身关联性没有那么大,目前各家公司的数据中台建设往往也都比较成功,将普通数据研发从复杂的数据基础设施复杂性中解放了出来,在《One SQL to Rule Them All》论文出现之后,经过了两三年的发展,实时计算在 90% 的场景不需要去了解底层技术栈了(优化除外)。对于数据平台的用户来说,研发就是写 SQL 和 udf 而已。

业务中台就不一样了,这也是这些大公司混日子的架构师们有意云遮雾罩,含糊其辞,导致后来人要浪费无数时间去研究甚至走弯路的领域。如果他们讲的太清楚,咨询费就不能要太多了吧。

在某司工作期间,我们实际建设的大多数中台系统就只是公用 API 而已,只用简单的 OOP 知识就可以拆分出来,连 DDD 都不需要。

近距离在猫厂内部观察之后,业务中台其实并不需要那么多名词和概念就可以说清楚,本质就是可视化工作流,工作流编辑平台和无处不在的规则引擎。

这些公司的架构师经常会把他们的中台提供的产品叫作“商业能力”,名词分量真是给够了。

商业能力本质上只是固化的流程和扩展点而已,以下图为例:

image.png

左边表示流程,右边表示扩展点。因为猫厂业务中台用 java 实现,工作流本身有不少现成的工具,右边的扩展点即提供给用户复用时的修改点,可以通过简单的注解来 override 掉原函数,替换为自己的实现。比如你的业务要复用中台的组件,但商品校验这里有一些你自己的定制逻辑,那么你只需要:

@injectpoint("商品校验")
public bool checkProduct() {
	// 你的逻辑
}

并不是很困难,对吧。有了这套系统之后,整个平台的能力,和不同业务场景(比如tmal、taobao)分别对哪些扩展点做了修改,可以直接通过代码扫描,汇总到平台上来,即使是产品经理和不写代码的老板也能看得见摸得着电商的流程到底都是在做什么。

业务系统本身就是流程,商业能力就是固化的流程,再将这些商业能力即固化流程组合起来,就是一个子领域,子领域再向上组合成为业务领域,最终成为完整的电商业务中台,逻辑上并不难理解,细节就不展开了。。。感兴趣的可以来找我私聊。

当然,我们也不能否认电商中台的业务复杂性,我所能看到的已经是划分好的领域和抽象完毕的结果,当初能够把这些电商业务划分清楚,拆分合适,并最终将其流程全部可视化的人水平还是很高的。

但从技术上来讲,基于工作流、扩展点的系统并不是近些年才有的,我之前写的 《righting software》一书笔记里也总结过,那位作者告诉我们业务本身就是工作流和局部规则,所以即使包装得再天花乱坠,从技术角度来看,这也不是什么创新。客观来讲,这样的业务技术形态确实在国内互联网公司是顶尖的,比其它连一个后台管理系统都设计不明白的所谓互联网大厂强多了。

但是我不知道某些技术公众号为什么天天在那吹这是创新,还扼腕这样好的技术既然没有作为我国互联网技术创新输出到国外。那我们来看看别人的总结:

image-1.png

上面这张图讲的是 mecha 架构,这些 dapr 的作者对于未来后端应用的畅想,工作流和应用状态管理是左边 state 管理的一部分,只要你能弄清目前业务中台的技术到底是在干什么事情,那孰优孰劣也自然能做到心里有数。

但是为什么看起来很合理的系统,最终却走上了末路了呢?

其实本质上还是中台本身做得不够好,我们可以从另一位曾经在猫厂业务部门工作过的人的文章中窥见一二:

0?wx_fmt=jpeg

为了服务业务的复杂性,这套中台做得越来越复杂,对于新人来说,想要熟悉他的流程和开发就要花上不少时间,因为本身商业能力是固化的流程,新接入的初创业务只是希望能复用某一个非常小的节点,却要拉家带口把全中台都接进来,坊间曾经传言考拉被收购之后接中台接了整整一年。而 lazada 被收购之后加班加点也花了半年时间才完成了接入和重构。

但是对于工程师红利充裕的地区来说,去复用一套极复杂的系统,还不如让大家 996 两个月重新写一套来得更快。

在前面我们说,中台架构师吹嘘的“商业能力”是固化的流程,这个业务中台发展赖以维系的前提,在 pdd 崛起之后基本就被完全打破了,我们和几个朋友曾经一起讨论过,为什么这么大一个公司,人员又如此冗余,连一个 pdd 的流程都做不出来?

后来发现也不用我们操心了,淘bao特价版不再要求接入之前的业务中台了。

尾声:也许有人要问,那连猫厂自己都否定了曾经的中台战略,对于小公司来说,还有必要参考吗?

别太看得起自己吧,小公司的中台也就只是人力外包资源池而已。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK