前言
在2021年,我们团队踏上了中台架构的拆分与优化之旅。需要澄清的是,我们所说的中台并非简单的平台化或微服务化的堆砌,而是基于微服务架构的深入实践与创新。我们的起点是开源项目alinesno-cloud
,经过社区建议与企业内部三年的实践沉淀,我们决定在2021年进行中台架构的拆分与重构。这一过程中,我们秉持“轻中台,小前台,大平台”的指导思想,旨在打造更加灵活、高效且适应行业发展的中台模型。以下是我作为团队负责人,在中台拆分过程中的一些心得与体会,特别适用于3-100人规模的中小团队参考。
一、拆分前的反思与规划
-
明确拆分目的:在拆分前,我们深入分析了当前中台架构的痛点,如服务耦合度高、响应速度慢、维护成本上升等。明确拆分旨在提升系统的可扩展性、可维护性和响应速度。
-
梳理业务边界:通过业务梳理,我们明确了各个业务领域的边界,为后续的微服务划分提供了依据。同时,也识别了跨领域的共享服务,为构建可复用的中台组件打下基础。
-
制定拆分策略:基于业务边界和技术依赖关系,我们制定了详细的拆分策略,包括服务拆分粒度、接口设计原则、数据治理方案等。
二、拆分过程中的挑战与应对
-
技术选型与整合:在拆分过程中,我们面临了多种技术选型的挑战。通过评估团队能力、技术发展趋势和业务需求,我们选择了最适合当前场景的技术栈,并进行了有效的整合与优化。
-
接口管理与文档化:为了确保服务间的顺畅通信,我们加强了接口管理,制定了严格的接口规范,并使用Swagger等工具进行接口文档化。这不仅提高了开发效率,也降低了沟通成本。
-
数据一致性与同步:在微服务架构下,数据的一致性和同步成为了一个重要问题。我们采用了分布式事务、消息队列等多种机制来确保数据的一致性和实时性。
-
团队协作与沟通:拆分过程中,团队协作与沟通变得尤为重要。我们建立了跨部门的沟通机制,定期召开项目会议,确保信息的及时传递和问题的及时解决。
三、拆分后的成效与展望
-
系统性能提升:经过拆分与优化,系统的响应速度和吞吐量得到了显著提升,用户体验得到了明显改善。
-
维护成本降低:服务间的耦合度降低,使得单个服务的维护成本也随之降低。同时,由于采用了标准化的接口和文档化管理,团队协作变得更加高效。
-
灵活性与可扩展性增强:新的中台模型更加灵活和可扩展,能够快速响应业务需求的变化。同时,也为未来的技术升级和业务拓展打下了坚实的基础。
-
持续迭代与优化:我们认识到中台建设是一个持续迭代与优化的过程。未来,我们将继续关注行业动态和技术发展趋势,不断优化中台架构和技术选型,以更好地支撑企业的快速发展和数字化转型。
总之,中台拆分是一个复杂而充满挑战的过程,但只要我们明确目标、科学规划、勇于实践并持续优化,就一定能够打造出更加高效、灵活且适应行业发展的中台模型。
原中台架构是怎么样的
中台的概念很早接触,前期从企业上云,再到 DevOps,技术中台,研发中台还有业务中台的建设,中台原带有的架构设计概念,更偏向于企业可复用的组件,多个业务线共用的服务,结合主流的微服务技术,包括 dubbo/cloud 体系 /k8s 容器化一系列的业务实践,结合出来的中台架构,如下图:
建设思想基于大中台、小前台指导,上面的架构图也是目前行业最常见的,也是原中台的架构和设计参考,也是解决了过程中的一部分问题,但是也带来了新的问题产生,但总的来说,是进步的,解决了传统研发中的弊端,包括维护、升级、自动化、发布、版本更新、重复建设等等,对架构的重构,带来新的企业机遇点。以下从几个角度进行阐述:
- 沉淀几年过程中带来的问题
- 为什么一定要拆分重构
- 拆分过程是怎么升级处理
- 中台要拆成什么最终形态
沉淀几年过程中带来的问题
中台架构解决了很多以前传统项目开发的问题,使得研发过程整体变得自动化,中步也产生了一个新的问题:中台太重。
维护中台过程重
由于前期大量的微服务技术体系,多组件整合,架构体系相对于一般的中小团队来说,已经较为庞大,基于 gitlab 的管理,原有的业务组件不断的增加能力,同时组件不断增加,前期单一基线,源码包由原来的十几个工程,迅速变成上百个工程,几百个组件,而且每一个业务项目的建设,就会增加新的中台能力沉淀,当然,这也是前期的初衷,也达到这个期望。
中台越来越庞大,对于中台团队来说,带来另一个致命性的,组件的关联性。南宁本地团队有一定的特点,一个是流动性,另一个是人员的培养性,这几个带来的问题,就是除了中台小组的几个人,其它人很难维护中台,同时由于前期放在同一个基线,代码量巨大,增加和修改功能,都需要极度的小心和避免影响项目,新人更加无从下手。工作量立杆见影的往上提升,甚至后面有些组件基本上不沉淀了,太多了无法维护。项目组开发过程中,出一个简单的问题,找人找问题都很难,业务响应速度下降,项目组不满程度突显。
前期通过招人,培养,文档来解决,后来发现,这也是一个艰难的工作,特别是文档,几百个组件的文档,对应的文档同步工作量也是庞大的,有很多陈旧的文档跟新功能对不上,特意找了写文档的人,但是产出还是没有达到预期。
另一个包括多项目,多版本,新旧版本维护等,这些维护过程来说,积累多,量也大。过程中不断增加的中间件环境,整个中间件技术宽度就很大,技术链路越来越长。
基于以上种种,针对于中小团队来说,原来小组对中台的管理,每个组件的升级管理,维护中台过程较重。
团队成长技术债过重
中台从基础框架,技术平台,研发中台,数据中台,还包括后期的智能平台规划,整体平台的技术债过重。原有的技术体系超过 120 个技术框架或者工具,每一个技术点都要求研发人员拥有快速学习和掌握的能力,需要消耗大量的周期时间。
架构体系更新太重
技术中台和研发中台的搭建,到后期的业务中台整合,前期考虑到中小团队,形成统一技术路线,这相对来说是好的,同时也避免了各种框架的混乱。但是在后期,要升级的时候,这个问题就是另一个灾难了。
前期考虑多架构融合,业务可选,在调整升级几个版本之后,发现,新旧项目切合越来越难融合。
创新和升级受约束
中台立于同一个基线的管理,同时过大的关联性,在新的业务组件建设中,带着沉重的中台包袱,用还是不用中台就成了一个问题,甚至有一些感觉鸡肋。用了,后期在其它项目使用可能会带着一连串的中台组件,比如一个简单的业务新组件,后来带的是注册中心,消息中心,缓存中心,还有 n 个关联的中台组件,甚至有可能找不清,链路过程找不到,去掉,发现有些工程又跑不起来,不去掉,又太重。过程需要讨论,这过程无形中又消耗去时间。
另一个是单独升级的组件的,可能无形中又影响其它引用的服务,考虑加版本,但是你根本就不清楚到底有哪些接入,无法确定是否升级,然后又需要讨论,仅仅找到相应的负责人确定方向,过程中无形又消耗时间周期,更可怕的是,前期的负责人可能自己都会遗忘前期的设计思路,或者负责这块的人员已经离职了。
为什么一定要拆分重构
在长期的沉淀过程中,慢慢形成资产,但是也造成了隐形的约束。
产生强大的内耗
内耗跟消化过程有一定的区别,前期的团队的对中台的理解和运用,基本上已经很熟悉,新人进入,基本上一个星期内就可以了解熟悉接入项目过程,这里的内耗,指的更多的是团队对中台的管理,围绕中台问题和管理上的消耗,这些基本上是无形的,开始基本上无感。
无形中产生的错误的架构思维
中台架构的思维,无形中影响着很多项目开发人员,技术经理,基本上内部已经形成约定的规范,照着上面的思维整合项目,项目无形中,也同步形成了很多组件,形成组件虽然是对的,但是由于架构思维的偏差,形成的是大量重复的组件,这些组件的兼容性还有共性是比较大的,在进行多个项目之后,会发现可能形成多套服务架构。在这里多套也是没有问题,重点的问题,这几套的维护人员,支撑人员,还有管理人员等等都是分散的,业务也是分散的,这个一下就会形成无限的服务组件,甚至有可能是指数级的增长。
对于大型团队,比如上千人的团队来说,可能问题不大,但是对于中小团队来说,这几乎是灾难性的,外加上人员流动缘故,另一个是地方人才等问题,可能很快就会变成团队压力负担,最后产生一个疑问,还要不要使用这个技术中台。
制约企业战略规划
前期中台架构,过分依赖于技术组件的复用性,偏向于技术体系,没有能从解决方案思维架构上的整合,无法跟进当前行业的发展。
中台的建设,团队的消化,项目的接入,业务的维护过程,整个下来,中小团队少的可能 1 年,重的可能 3-5 年,这个过程基本上团队没有精力再思考其它,对一般的企业来说,有限的资源力量,就无形中成为一种制约。
拆分过程是怎么升级处理
拆分思维从大中台,小前台,转变成轻中台,小前台,大平台架构指导。
中台怎么拆
一个基线的拆分,每个组件针对颗粒度形成一个单独的管理基线,同时明确中台的管理边界,哪些可集成,哪些不可集成,哪些需要放弃,哪些需要重点建设,进行重点精度升级,在架构上形成边界。
明确中台版本的管理,稳定版本的管理,一定确定出稳定版,同时划分明确中台组基线的管理范围,中台组件范围,非团队或者企业核心组件,不做整合,做好分界线。
明确上下游关系,每个组件提供标准稳定接口,明确上下游组件,另一个是提取出核心业务领域,面向接口编程,如下图:
这样无论外围技术升级和划分,核心业务领域尽量少动,切换的是领域外围,形成稳定的企业核心资产和版本,同时避免技术升级带来的核心业务代码变动。
去掉非通用协议,当然,也可以不去掉,主要看技术债和团队问题,针对于我们团队,当时直接全量升级,从 RPC 协议调整成 Http 协议,如果是 cloud 技术,这个问题就可以免掉了。
后期怎么升级维护
基于中台服务的拆分,各个业务组件和服务,都有可能变成一个单独的业务线,在设计和方案,还有新技术的增加上面,新需求新市场变动变动上面,变得相当的轻量,不再需要关心过多的中台包袱,开发人员的思维和思绪更偏向于这个组件的完善上面。
每个服务的架构和变动上面,就会变得很轻量,升级维护可以根据每个组件和负责人不同方案,进行最合适的升级处理。需要添加的服务和模块,就不再是有累赘,过程的指导由中台运营手册去做管理指导,形成轻量级的公共组件和服务。
提供出来的接口和服务,在不影响其它人的引用即可,同时做好前后兼容即可,侧面增大了 k 中台服务组件的包容性,通过中台定制的管理运营规范,按一般的 java 项目管理维护即可,这里就不再过多阐述。
中台要拆成什么结果形态
这里的形态,整个过程由单体到服务化,再到微服务,大中台小前台,再到进一步升级的结果形态。
基于新中台模型架构
中台包括很多层面,不仅仅是技术,更多的是业务的挂钩,不仅仅是技术的改变,更多是模式的改变,比如规划、产品、沉淀、落地、资源整合等一套体系,而不是说,我们就做那么个框架或是技术平台,而是一个更高一层的思想架构提升,这里定义的新中台的模型包括以下几点:
- 产品:企业团队沉淀能力体现
- 解决方案:客户业务价值体现
- 组织架构:价值落地的保障体现
- 技术:技术是落地的直接能力输出
- 合作体系:业务发展能力体现
- 沉淀:发展和突破点积累体现
结合上面的新中台阐述落地体系,从几个角度思考愿景方向和发展走向形势参考,主要思考的几个点:
- 新解决方案:业务价值能力输出
- 新服务模式:客户业务价值输出
- 新发展模式:S2B 商业模式输出
从整体上表述新中台的模型和愿景方向,也是数字化社区的目标和愿景,整体愿景期望的已不仅仅是数字化,更多的是以数字化为基础,进行更好的发展方向。
行业产品形态能力输出
行业模式,不仅仅是目前的业务维护,更多的是基于新中台架构行业发展地位和企业发展的基础。
相应的市面上产品示例门户体现参考:
- 钉钉门户
- 金蝶云苍穹门户
总结
以上为中台拆分过程的一些过程和思路,每个架构师或者技术负责人有自己的思路,上面是自己在整合过程的总结。