📚 课程目录第2章平台核心要素拆解

2. 平台核心要素拆解：技术底座、业务中台、数据中台、AI中台的定义与边界

很多团队在搭建平台时，上来就喊「我们要建中台」。结果呢？业务中台、数据中台、AI中台混成一锅粥，技术底座更是被当成「服务器采购清单」。我见过不止一个项目，花了半年把数据中台搭起来，结果发现业务系统根本接不进去——因为连统一身份认证都没做。

这一节，咱们把四个核心要素拆开揉碎。说白了，就是搞清楚：谁该干什么，谁不该干什么。

2.1 技术底座：平台的「地基」

技术底座不是一堆中间件的名字，而是支撑上层所有能力的通用基础设施。我个人习惯把它分成四层：

层级	核心组件	典型选型
资源层	计算、存储、网络	Kubernetes、Ceph、Calico
服务层	注册发现、配置中心、网关	Nacos、Apollo、Kong
可观测层	日志、监控、链路追踪	ELK、Prometheus、Jaeger
安全层	认证、授权、审计	Keycloak、OAuth2、RBAC

这里有个坑：技术底座最怕「过度设计」。我曾经在一个日活不到10万的系统里，看到团队上了全套Service Mesh + 分布式事务 + 多活架构。结果光运维这些基础设施就占了一半人力。你想想看，业务还没跑起来，底座先把自己压垮了。

避坑指南：技术底座的建设原则是「够用就好，按需演进」。初期优先搞定服务层和可观测层，安全层用现成的云服务兜底。等业务规模上来了，再逐步替换自建组件。

2.2 业务中台：把「重复造轮子」变成「乐高积木」

业务中台的核心价值就一句话：把多个业务线共用的能力抽出来，统一管理。比如用户中心、订单中心、支付中心、商品中心——这些几乎每个业务都需要，没必要每个团队各写一套。

我参与过一个电商平台的改造。原来三个事业部各自维护一套用户系统，连登录接口都不一样。后来我们统一做了用户中台，把注册、登录、权限、实名认证全部收拢。效果很明显：新业务上线时间从2周缩短到3天。

但业务中台的边界很容易模糊。我见过最典型的错误是：把「通用能力」和「业务特性」混在一起。比如订单中台，如果硬要把「秒杀订单」和「普通订单」的逻辑揉在一个服务里，那这个中台迟早会变成「大泥球」。

我的经验：业务中台的粒度要控制在「业务对象」级别。一个中台只负责一个核心业务对象的生命周期管理。比如订单中台只管订单的创建、流转、完成，至于订单怎么营销、怎么推荐，那是上层业务系统的事。

2.3 数据中台：从「数据孤岛」到「数据资产」

数据中台不是大数据平台，也不是数据仓库。它的本质是一套让数据「可复用、可治理、可服务」的机制。

我习惯把数据中台的能力分成三个层次：

数据采集与存储层：统一采集业务日志、埋点数据、DB变更流，存到ODS层。
数据治理与建模层：做数据清洗、标准化、构建主题模型（比如用户画像、商品标签）。
数据服务层：通过API或数据同步，把加工好的数据输出给业务系统。

这里有个容易踩的坑：数据中台不等于「把所有数据都搬过来」。我曾经见过一个团队，把全公司200多个系统的原始数据全部同步到数据中台，结果存储成本暴涨，但真正被使用的数据不到10%。

  核心原则：数据中台只管理「被多次消费的数据」。一次性的报表查询、临时性的数据分析，不应该走数据中台。否则中台会变成「数据垃圾桶」。

2.4 AI中台：让算法工程师「少搬砖」

AI中台是最近两年才被频繁提起的概念。说白了，它解决的是算法模型从训练到上线的「最后一公里」问题。

我接触过不少AI团队，他们的工作流是这样的：算法工程师在Jupyter Notebook里调参，调好了把模型文件丢给工程团队，工程团队再手动写推理服务、配置GPU资源、对接业务接口。整个过程至少一周，而且每次模型更新都要重复一遍。

AI中台要做的就是把这些流程自动化：

特征平台：统一管理特征工程，避免每个模型重复写特征提取逻辑。
模型训练平台：提供分布式训练、超参搜索、实验管理能力。
模型推理平台：一键部署模型为RESTful API，支持A/B测试和灰度发布。
模型监控：实时监控模型效果，检测数据漂移和模型退化。

注意：AI中台不是「万能炼丹炉」。它只适合那些需要频繁迭代模型、有多个模型同时在线服务的场景。如果你的业务只有一两个模型，半年才更新一次，那用现成的MLflow或Kubeflow就够了，没必要自建AI中台。

2.5 四个要素的边界与协作关系

这四个要素不是孤立的，它们之间有清晰的层级关系：

技术底座在最底层，为所有中台提供基础设施。
业务中台和数据中台是平级的，一个管「业务逻辑」，一个管「数据资产」。
AI中台通常依赖数据中台提供的特征数据，同时通过业务中台暴露的接口来输出推理结果。

我画了一张图，帮你直观理解它们的关系：

从图上可以看得很清楚：AI中台是「吃数据、吐业务」的中间层。它从数据中台拿特征，训练出模型后，通过业务中台暴露的接口来服务最终用户。而技术底座，则是所有这一切的「土壤」。

2.6 边界划分的实战建议

最后，我总结几条实战中容易踩的边界问题：

常见问题	错误做法	正确做法
技术底座与业务中台混淆	在技术底座里写业务逻辑	技术底座只提供通用能力，业务逻辑全部放在中台
业务中台与数据中台重叠	业务中台自己维护数据仓库	业务中台只负责业务状态，数据加工交给数据中台
AI中台与数据中台耦合过紧	AI中台直接读取原始数据	AI中台通过数据中台的标准API获取特征
所有中台共用同一套数据库	业务中台直接查询数据中台的表	每个中台有独立的数据库，通过API交互

一个小技巧：在项目初期，可以用「职责矩阵」来明确每个中台的边界。比如：用户注册 → 业务中台；用户行为分析 → 数据中台；用户推荐模型 → AI中台。谁做什么，一目了然。

嗯，这四个要素的拆解就到这里。记住一句话：技术底座是「路」，业务中台是「车」，数据中台是「油」，AI中台是「自动驾驶」。路修好了，车才能跑；油加对了，车才有动力；自动驾驶装上了，车才能跑得更聪明。但千万别在只有一辆自行车的时候，就想着修高速公路。