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