这是一个创建于 681 天前的主题，其中的信息可能已经有所发展或是发生改变。
前言
没有接触过中台项目，不太能理解这个东西落地以后到底是个什么流程或者起到什么作用！
查了很多的资料，但是就是没有办法带入自己的实际需求中来！
举例
目前公司有 3 个落地的平台，A,B,C ， 现在要从这三个平台切入做数据中台 业务中台，并且为以后开发的平台能提供支持，实现的整体思路应该是什么？
我查的资料理解的，中台是把各个平台重复的东西抽出来，统一提供支持，比如用户服务 等... 如果带入到上面的需求，这个中台落地以后是不是把 A,B,C 三个公用的数据，公共的业务 抽出来然后让中台来提供接口返回
希望大佬们能给普及一下该怎么入手去做，万分感谢！
 |
1
johnsona 2022-12-25 17:46:58 +08:00
人家都拆了 你还搞 傻
|
 |
2
xuanbg 2022-12-25 18:09:01 +08:00
数据中台可以搞。业务中台就算了，这个完全是给自己制造麻烦。
不过我建议你可以把 3 个平台中的组织机构、用户、角色这些拆出来，做一个用户中台。如果有支付结算功能，也可以拆出来做个结算中台。还可以把发短信、发邮件、推送消息、站内信等都做成消息中台。 |
 |
5
godleon OP @xuanbg 说的我大概明白，但是这样搞得话，最终落地以后，想组织机构 用户 角色 菜单这些，不都是会统一入口了嘛，这样相当于你的中台有个独立的前端去展示这些 组织机构 角色 菜单。
|
 |
6
Pantheoon 2022-12-25 22:21:36 +08:00  4
举个例子，你们有一条业务线做在线教育的，这个功能有用户登录，上课，下单等功能，刚开始只有一条业务线，你们任务来了就开发，好不快活，过了两年，又新建了一条业务线，也是做教育的，但是是做的成人教育，同样也有用户登录，上课，下单等功能，这个时候为了快速迭代，他们就自己搞了，任务来了就开发，也好不快活。又过了两年，某个大佬觉得相似的业务功能为什么要两个团队单独维护，于是抽出几个团队，专门做登录，上课，订单等内容，你们和成人教育团队把需要的数据传过去就行了，这个时候来了任务你们要拉上多端一起协作，事情变的痛苦起来，哪怕一个小小地变动，都要拉扯进一堆的开发，所以，你看，要做的功能没少，要写的代码也没少，但是牵扯的人多了，这个就是中台模式
|
|
7
xuanbg 2022-12-25 22:25:05 +08:00
@godleon 中台只是能力，体现这个能力还得是前端。后端无论怎么拆分服务，前端可以不拆分啊。而且即使不拆分，多个项目的前端也可以有部分代码复用的吧。
|
 |
9
securityCoding 2022-12-25 22:43:50 +08:00 via Android
裁员裁的最狠的就是中台
|
 |
10
yinzhili 2022-12-26 10:00:10 +08:00
对于很多中小公司来说，这种东西做出来上线稳定后，你就没价值了
|
 |
11
opengps 2022-12-26 11:42:54 +08:00
中台这个词，是前台后台之外多出来的一层。可见中台是第三方平台才有的需求，BS 下，既要给客户 B 一个后台,又要给 C 一个后台，其实 B 不是顶级后台，所以称为 SaaS 平台下的 B 为中台
|
 |
12
Eins 2022-12-26 14:34:20 +08:00
最好先看业务流程，从业务流程里面拆共性的环节，然后把现有的平台 ABC 的能力打散，根据共性流程组装，至于数据中台、业务中台要做哪个，我建议是看有多少人力，中台还是个比较吃资源的平台，人力不多的情况下先做业务中台，和业务一起拿到结果再去做一些阶段性汇报拿更多 HC
|
 |
13
greatxin 2022-12-26 14:57:09 +08:00
上家是一个集团公司，落地了很多很多中台，多到还有专门的系统来展示这些中台系统。当然后来这些大部分系统基本废弃不用，还在坚挺的就那么几个，而且由于中台人员大批的经常换人，导致很多系统也没人也没法维护。
印象中，用的比较多的有 1. abtest 系统，各个 app 集成后可以统一用集团的测试系统看 ab 结果数据 2. 数据中心，统一埋点上报，最主要的是要与集团 app 的账号打通，方便看内部引流情况 3. 发布系统，统一云服务权限，整合好 build 和 deploy 的环境 比较诟病的是，ab 经常挂，然后全公司的 app 跟着一起挂。还有个安卓的 sdk ，因为版本老旧，有的部门比较新潮就会出现不兼容，维护方也不愿意升级。 中台整体感觉远景非常好，但是各个业务线情况太多了，中台根本照顾不到。现在想起来还不如把各个中台系统做成内部开源系统，支持 docker 一键部署，哪个业务团队想用就自己部署好了。 期望做的大而全，让各个业务方集成的结果就是，专门要有人教学，还得搞权限分配，管理员审批，分开计算成本。 |
 |
14
litchinn 2022-12-27 09:09:50 +08:00
中台能带来看的见的好处：
1. 引用 6 楼 `某个大佬觉得相似的业务功能为什么要两个团队单独维护`,同样功能的代码只写一次并由同一个团队维护 2. 针对公司的编码规范可以出台对应的编码方案，以 spring 为例，rest 接口的请求参数、返回对象和异常码返回等可以通过提供 starter 的方式统一起来，当公司内部人员发生调动时，能快速适应代码 中台的困难： 1. 很多功能可能广泛存在于不同系统，例如用户管理等，但具体到每个不同系统中他们可能又有些许差异，而中台在编码时不可能完全考虑到所有情况，而业务侧一旦产生需求，可能没有时间等待中台去做升级 2. 中台对于企业有个很严重的问题就是产出很难量化，即使你做了很多工作但是没办法表示你的产出，做的再好业务端没有产出也没用，当业务端有产出时也很难量化中台在其中的作用，因此对于大多数公司而言中台是一个纯投入型的项目 针对困难 1 ，比较好的方式是，中台在提供功能时同时提供扩展性，例如使用 SPI 或 spring factory 这种机制，业务侧在对现有功能提出需求时，优先向中台发起请求，中台评估该新功能或增强是否应该由中台完成，以及给出相应时间计划，时间不允许的情况下，业务侧再自行完成需求，后续看情况将代码合进中台。 显然这种方式也会带来困难 2 ，业务侧觉得，功能都是我提交上去的，我做了中台的事，要你中台干嘛，在特别极端的情况下甚至会出现由于某个项目的领域特别新，使用的技术要求较高，一段时间内长期向中台提供内容而并未从中台获利，从公司整体而言这部分功能只要有其他业务也在使用当然是赚的，但对于这个项目组而言就不一样了。 中台的管理问题更大于技术问题。 |
 |
15
DogDoor 2022-12-27 10:58:09 +08:00
其实很简单啊，你把你们的服务能力，包装起来，为别人能够提供一键式的傻瓜触发能力(同时满足你们本身的通用性)，你就可以称之为中台。
|
 |
16
AyaseEri 2022-12-27 14:56:19 +08:00
中台是一个水到渠成的事情，如果意识不到他的好处，那就是没必要。
|
Select Language