研发中台拆分过程的一些心得总结

背景在 21 年，中台拆分在 21 年，以下为中台拆分的过程心得，带有一定的主观，偏向于中小团队中台建设参考（这里的中小团队指 3-100 人的团队），对于大型团队不太适用，毕竟大型团队人中 / 技术充足。

前言

这里的中台架构不是平台，也不是微服务，使用的是微服务架构，这两个是不一样的概述。中台建设开源项目 alinesno-cloud 开始，社区建议沉淀和企业实践 3 年左右，于 21 年进行拆分，指导思想为轻中台，小前台，大平台，为了更适应行业发展，更好的企业落地，整合出新中台模型，每个企业中台建设不一，这里针对的是自己带队建设过程，我有我思。

原中台架构是怎么样的

中台的概念很早接触，前期从企业上云，再到 DevOps，技术中台，研发中台还有业务中台的建设，中台原带有的架构设计概念，更偏向于企业可复用的组件，多个业务线共用的服务，结合主流的微服务技术，包括 dubbo/cloud 体系 /k8s 容器化一系列的业务实践，结合出来的中台架构，如下图：

建设思想基于大中台、小前台指导，上面的架构图也是目前行业最常见的，也是原中台的架构和设计参考，也是解决了过程中的一部分问题，但是也带来了新的问题产生，但总的来说，是进步的，解决了传统研发中的弊端，包括维护、升级、自动化、发布、版本更新、重复建设等等，对架构的重构，带来新的企业机遇点。以下从几个角度进行阐述：

• 沉淀几年过程中带来的问题
• 为什么一定要拆分重构
• 拆分过程是怎么升级处理
• 中台要拆成什么最终形态

沉淀几年过程中带来的问题

中台架构解决了很多以前传统项目开发的问题，使得研发过程整体变得自动化，中步也产生了一个新的问题：中台太重。

维护中台过程重

由于前期大量的微服务技术体系，多组件整合，架构体系相对于一般的中小团队来说，已经较为庞大，基于 gitlab 的管理，原有的业务组件不断的增加能力，同时组件不断增加，前期单一基线，源码包由原来的十几个工程，迅速变成上百个工程，几百个组件，而且每一个业务项目的建设，就会增加新的中台能力沉淀，当然，这也是前期的初衷，也达到这个期望。

中台越来越庞大，对于中台团队来说，带来另一个致命性的，组件的关联性。南宁本地团队有一定的特点，一个是流动性，另一个是人员的培养性，这几个带来的问题，就是除了中台小组的几个人，其它人很难维护中台，同时由于前期放在同一个基线，代码量巨大，增加和修改功能，都需要极度的小心和避免影响项目，新人更加无从下手。工作量立杆见影的往上提升，甚至后面有些组件基本上不沉淀了，太多了无法维护。项目组开发过程中，出一个简单的问题，找人找问题都很难，业务响应速度下降，项目组不满程度突显。

前期通过招人，培养，文档来解决，后来发现，这也是一个艰难的工作，特别是文档，几百个组件的文档，对应的文档同步工作量也是庞大的，有很多陈旧的文档跟新功能对不上，特意找了写文档的人，但是产出还是没有达到预期。

另一个包括多项目，多版本，新旧版本维护等，这些维护过程来说，积累多，量也大。过程中不断增加的中间件环境，整个中间件技术宽度就很大，技术链路越来越长。

基于以上种种，针对于中小团队来说，原来小组对中台的管理，每个组件的升级管理，维护中台过程较重。

团队成长技术债过重

中台从基础框架，技术平台，研发中台，数据中台，还包括后期的智能平台规划，整体平台的技术债过重。原有的技术体系超过 120 个技术框架或者工具，每一个技术点都要求研发人员拥有快速学习和掌握的能力，需要消耗大量的周期时间。

架构体系更新太重

技术中台和研发中台的搭建，到后期的业务中台整合，前期考虑到中小团队，形成统一技术路线，这相对来说是好的，同时也避免了各种框架的混乱。但是在后期，要升级的时候，这个问题就是另一个灾难了。

前期考虑多架构融合，业务可选，在调整升级几个版本之后，发现，新旧项目切合越来越难融合。

创新和升级受约束

中台立于同一个基线的管理，同时过大的关联性，在新的业务组件建设中，带着沉重的中台包袱，用还是不用中台就成了一个问题，甚至有一些感觉鸡肋。用了，后期在其它项目使用可能会带着一连串的中台组件，比如一个简单的业务新组件，后来带的是注册中心，消息中心，缓存中心，还有 n 个关联的中台组件，甚至有可能找不清，链路过程找不到，去掉，发现有些工程又跑不起来，不去掉，又太重。过程需要讨论，这过程无形中又消耗去时间。

另一个是单独升级的组件的，可能无形中又影响其它引用的服务，考虑加版本，但是你根本就不清楚到底有哪些接入，无法确定是否升级，然后又需要讨论，仅仅找到相应的负责人确定方向，过程中无形又消耗时间周期，更可怕的是，前期的负责人可能自己都会遗忘前期的设计思路，或者负责这块的人员已经离职了。

为什么一定要拆分重构

在长期的沉淀过程中，慢慢形成资产，但是也造成了隐形的约束。

产生强大的内耗

内耗跟消化过程有一定的区别，前期的团队的对中台的理解和运用，基本上已经很熟悉，新人进入，基本上一个星期内就可以了解熟悉接入项目过程，这里的内耗，指的更多的是团队对中台的管理，围绕中台问题和管理上的消耗，这些基本上是无形的，开始基本上无感。

无形中产生的错误的架构思维

中台架构的思维，无形中影响着很多项目开发人员，技术经理，基本上内部已经形成约定的规范，照着上面的思维整合项目，项目无形中，也同步形成了很多组件，形成组件虽然是对的，但是由于架构思维的偏差，形成的是大量重复的组件，这些组件的兼容性还有共性是比较大的，在进行多个项目之后，会发现可能形成多套服务架构。在这里多套也是没有问题，重点的问题，这几套的维护人员，支撑人员，还有管理人员等等都是分散的，业务也是分散的，这个一下就会形成无限的服务组件，甚至有可能是指数级的增长。

对于大型团队，比如上千人的团队来说，可能问题不大，但是对于中小团队来说，这几乎是灾难性的，外加上人员流动缘故，另一个是地方人才等问题，可能很快就会变成团队压力负担，最后产生一个疑问，还要不要使用这个技术中台。

制约企业战略规划

前期中台架构，过分依赖于技术组件的复用性，偏向于技术体系，没有能从解决方案思维架构上的整合，无法跟进当前行业的发展。

中台的建设，团队的消化，项目的接入，业务的维护过程，整个下来，中小团队少的可能 1 年，重的可能 3-5 年，这个过程基本上团队没有精力再思考其它，对一般的企业来说，有限的资源力量，就无形中成为一种制约。

拆分过程是怎么升级处理

拆分思维从大中台，小前台，转变成轻中台，小前台，大平台架构指导。

中台怎么拆

一个基线的拆分，每个组件针对颗粒度形成一个单独的管理基线，同时明确中台的管理边界，哪些可集成，哪些不可集成，哪些需要放弃，哪些需要重点建设，进行重点精度升级，在架构上形成边界。

明确中台版本的管理，稳定版本的管理，一定确定出稳定版，同时划分明确中台组基线的管理范围，中台组件范围，非团队或者企业核心组件，不做整合，做好分界线。

明确上下游关系，每个组件提供标准稳定接口，明确上下游组件，另一个是提取出核心业务领域，面向接口编程，如下图：

这样无论外围技术升级和划分，核心业务领域尽量少动，切换的是领域外围，形成稳定的企业核心资产和版本，同时避免技术升级带来的核心业务代码变动。

去掉非通用协议，当然，也可以不去掉，主要看技术债和团队问题，针对于我们团队，当时直接全量升级，从 RPC 协议调整成 Http 协议，如果是 cloud 技术，这个问题就可以免掉了。

后期怎么升级维护

基于中台服务的拆分，各个业务组件和服务，都有可能变成一个单独的业务线，在设计和方案，还有新技术的增加上面，新需求新市场变动变动上面，变得相当的轻量，不再需要关心过多的中台包袱，开发人员的思维和思绪更偏向于这个组件的完善上面。

每个服务的架构和变动上面，就会变得很轻量，升级维护可以根据每个组件和负责人不同方案，进行最合适的升级处理。需要添加的服务和模块，就不再是有累赘，过程的指导由中台运营手册去做管理指导，形成轻量级的公共组件和服务。

提供出来的接口和服务，在不影响其它人的引用即可，同时做好前后兼容即可，侧面增大了 k 中台服务组件的包容性，通过中台定制的管理运营规范，按一般的 java 项目管理维护即可，这里就不再过多阐述。

中台要拆成什么结果形态

这里的形态，整个过程由单体到服务化，再到微服务，大中台小前台，再到进一步升级的结果形态。

基于新中台模型架构

中台包括很多层面，不仅仅是技术，更多的是业务的挂钩，不仅仅是技术的改变，更多是模式的改变，比如规划、产品、沉淀、落地、资源整合等一套体系，而不是说，我们就做那么个框架或是技术平台，而是一个更高一层的思想架构提升，这里定义的新中台的模型包括以下几点：

• 产品：企业团队沉淀能力体现
• 解决方案：客户业务价值体现
• 组织架构：价值落地的保障体现
• 技术：技术是落地的直接能力输出
• 合作体系：业务发展能力体现
• 沉淀：发展和突破点积累体现

结合上面的新中台阐述落地体系，从几个角度思考愿景方向和发展走向形势参考，主要思考的几个点：

• 新解决方案：业务价值能力输出
• 新服务模式：客户业务价值输出
• 新发展模式：S2B 商业模式输出

从整体上表述新中台的模型和愿景方向，也是数字化社区的目标和愿景，整体愿景期望的已不仅仅是数字化，更多的是以数字化为基础，进行更好的发展方向。

行业产品形态能力输出

行业模式，不仅仅是目前的业务维护，更多的是基于新中台架构行业发展地位和企业发展的基础。

相应的市面上产品示例门户体现参考：

• 钉钉门户
• 金蝶云苍穹门户

总结

以上为中台拆分过程的一些过程和思路，每个架构师或者技术负责人有自己的思路，上面是自己在整合过程的总结。