请教中台项目的一些问题？

[godleon]

前言

没有接触过中台项目，不太能理解这个东西落地以后到底是个什么流程或者起到什么作用！

查了很多的资料，但是就是没有办法带入自己的实际需求中来！

举例

目前公司有 3 个落地的平台，A,B,C ， 现在要从这三个平台切入做数据中台 业务中台，并且为以后开发的平台能提供支持，实现的整体思路应该是什么？

我查的资料理解的，中台是把各个平台重复的东西抽出来，统一提供支持，比如用户服务 等... 如果带入到上面的需求，这个中台落地以后是不是把 A,B,C 三个公用的数据，公共的业务 抽出来然后让中台来提供接口返回

希望大佬们能给普及一下该怎么入手去做，万分感谢！

[johnsona]

人家都拆了 你还搞 傻

[xuanbg]

数据中台可以搞。业务中台就算了，这个完全是给自己制造麻烦。
不过我建议你可以把 3 个平台中的组织机构、用户、角色这些拆出来，做一个用户中台。如果有支付结算功能，也可以拆出来做个结算中台。还可以把发短信、发邮件、推送消息、站内信等都做成消息中台。

[yogogo]

@xuanbg #2 在我理解里，你这些不就微服务相关的吗？

[xuanbg]

@yogogo 微服务不一定是中台，但中台肯定是微服务。我的用户中台分了 6 个服务。

[godleon]

@xuanbg 说的我大概明白，但是这样搞得话，最终落地以后，想组织机构 用户 角色 菜单这些，不都是会统一入口了嘛，这样相当于你的中台有个独立的前端去展示这些 组织机构 角色 菜单。

[Pantheoon]

举个例子，你们有一条业务线做在线教育的，这个功能有用户登录，上课，下单等功能，刚开始只有一条业务线，你们任务来了就开发，好不快活，过了两年，又新建了一条业务线，也是做教育的，但是是做的成人教育，同样也有用户登录，上课，下单等功能，这个时候为了快速迭代，他们就自己搞了，任务来了就开发，也好不快活。又过了两年，某个大佬觉得相似的业务功能为什么要两个团队单独维护，于是抽出几个团队，专门做登录，上课，订单等内容，你们和成人教育团队把需要的数据传过去就行了，这个时候来了任务你们要拉上多端一起协作，事情变的痛苦起来，哪怕一个小小地变动，都要拉扯进一堆的开发，所以，你看，要做的功能没少，要写的代码也没少，但是牵扯的人多了，这个就是中台模式

[xuanbg]

@godleon 中台只是能力，体现这个能力还得是前端。后端无论怎么拆分服务，前端可以不拆分啊。而且即使不拆分，多个项目的前端也可以有部分代码复用的吧。

[xuanbg]

@Pantheoon 所以中台只适合搞一些固定不变的，订单这种业务搞中台，我觉得不是疯了就是飘了。

[securityCoding]

裁员裁的最狠的就是中台

[yinzhili]

对于很多中小公司来说，这种东西做出来上线稳定后，你就没价值了

[opengps]

中台这个词，是前台后台之外多出来的一层。可见中台是第三方平台才有的需求，BS 下，既要给客户 B 一个后台,又要给 C 一个后台，其实 B 不是顶级后台，所以称为 SaaS 平台下的 B 为中台

[Eins]

最好先看业务流程，从业务流程里面拆共性的环节，然后把现有的平台 ABC 的能力打散，根据共性流程组装，至于数据中台、业务中台要做哪个，我建议是看有多少人力，中台还是个比较吃资源的平台，人力不多的情况下先做业务中台，和业务一起拿到结果再去做一些阶段性汇报拿更多 HC

[greatxin]

上家是一个集团公司，落地了很多很多中台，多到还有专门的系统来展示这些中台系统。当然后来这些大部分系统基本废弃不用，还在坚挺的就那么几个，而且由于中台人员大批的经常换人，导致很多系统也没人也没法维护。
印象中，用的比较多的有
1. abtest 系统，各个 app 集成后可以统一用集团的测试系统看 ab 结果数据
2. 数据中心，统一埋点上报，最主要的是要与集团 app 的账号打通，方便看内部引流情况
3. 发布系统，统一云服务权限，整合好 build 和 deploy 的环境

比较诟病的是，ab 经常挂，然后全公司的 app 跟着一起挂。还有个安卓的 sdk ，因为版本老旧，有的部门比较新潮就会出现不兼容，维护方也不愿意升级。

中台整体感觉远景非常好，但是各个业务线情况太多了，中台根本照顾不到。现在想起来还不如把各个中台系统做成内部开源系统，支持 docker 一键部署，哪个业务团队想用就自己部署好了。

期望做的大而全，让各个业务方集成的结果就是，专门要有人教学，还得搞权限分配，管理员审批，分开计算成本。

[litchinn]

中台能带来看的见的好处：
1. 引用 6 楼 `某个大佬觉得相似的业务功能为什么要两个团队单独维护`,同样功能的代码只写一次并由同一个团队维护
2. 针对公司的编码规范可以出台对应的编码方案，以 spring 为例，rest 接口的请求参数、返回对象和异常码返回等可以通过提供 starter 的方式统一起来，当公司内部人员发生调动时，能快速适应代码
中台的困难：
1. 很多功能可能广泛存在于不同系统，例如用户管理等，但具体到每个不同系统中他们可能又有些许差异，而中台在编码时不可能完全考虑到所有情况，而业务侧一旦产生需求，可能没有时间等待中台去做升级
2. 中台对于企业有个很严重的问题就是产出很难量化，即使你做了很多工作但是没办法表示你的产出，做的再好业务端没有产出也没用，当业务端有产出时也很难量化中台在其中的作用，因此对于大多数公司而言中台是一个纯投入型的项目
针对困难 1 ，比较好的方式是，中台在提供功能时同时提供扩展性，例如使用 SPI 或 spring factory 这种机制，业务侧在对现有功能提出需求时，优先向中台发起请求，中台评估该新功能或增强是否应该由中台完成，以及给出相应时间计划，时间不允许的情况下，业务侧再自行完成需求，后续看情况将代码合进中台。
显然这种方式也会带来困难 2 ，业务侧觉得，功能都是我提交上去的，我做了中台的事，要你中台干嘛，在特别极端的情况下甚至会出现由于某个项目的领域特别新，使用的技术要求较高，一段时间内长期向中台提供内容而并未从中台获利，从公司整体而言这部分功能只要有其他业务也在使用当然是赚的，但对于这个项目组而言就不一样了。
中台的管理问题更大于技术问题。

[DogDoor]

其实很简单啊，你把你们的服务能力，包装起来，为别人能够提供一键式的傻瓜触发能力(同时满足你们本身的通用性)，你就可以称之为中台。

[AyaseEri]

中台是一个水到渠成的事情，如果意识不到他的好处，那就是没必要。

[cmai]

@johnsona 不敢苟同，拆中台是他们的业务发展到一定程度了，更需要创新而不是快速启动业务，企业信息化每一个阶段有不同的建设的方案，不是人家拆了就代表这件事一定是错的，架构是演进的。

[johnsona]

@cmai 傻冒 别人随口一提的概念 你跟着起劲

[cmai]

@johnsona 掀起一阵风潮的叫别人随口一提的概念 字节、阿里、腾讯都是你眼里的傻冒，你挺可怜的，恼羞成怒然后言语攻击，block 了，