以前小的时候，看到父亲买两个音箱，初中那会放假的时候，见他一个人在自己房间里面听着他自己放到CD。当时老人也已经差不多35+，自己心里还有嫌弃着，为什么一个大人还这么不成熟，放CD，放大音箱。
等到自己到30岁的时候，自己才发现，有一种生活，叫那个时候。他往往包含着老人心里的一种孤独，无奈。为什么一个人，为什么放着自己的CD，因为我们并不是特别理解他，也并不是特别的让他体会到他所有的感受，也只能听着音乐，自我享受。
我把整个研发中台拆分过程的一些心得总结
背景在21年，中台拆分在21年，以下为中台拆分的过程心得，带有一定的主观，偏向于中小团队中台建设参考（这里的中小团队指3-100人的团队），对于大型团队不太适用，毕竟大型团队人中/技术充足。
前言
这里的中台架构不是平台，也不是微服务，使用的是微服务架构，这两个是不一样的概述。中台建设开源项目alinesno-cloud开始，社区建议沉淀和企业实践3年左右，于21年进行拆分，指导思想为轻中台，小前台，大平台，为了更适应行业发展，更好的企业落地，整合出新中台模型，每个企业中台建设不一，这里针对的是自己带队建设过程，我有我思。
原中台架构是怎么样的
中台的概念很早接触，前期从企业上云，再到DevOps，技术中台，研发中台还有业务中台的建设，中台原带有的架构设计概念，更偏向于企业可复用的组件，多个业务线共用的服务，结合主流的微服务技术，包括dubbo/cloud体系/k8s容器化一系列的业务实践，结合出来的中台架构，如下图：
建设思想基于大中台、小前台指导，上面的架构图也是目前行业最常见的，也是原中台的架构和设计参考，也是解决了过程中的一部分问题，但是也带来了新的问题产生，但总的来说，是进步的，解决了传统研发中的弊端，包括维护、升级、自动化、发布、版本更新、重复建设等等，对架构的重构，带来新的企业机遇点。以下从几个角度进行阐述：
- 沉淀几年过程中带来的问题
- 为什么一定要拆分重构
- 拆分过程是怎么升级处理
- 中台要拆成什么最终形态
沉淀几年过程中带来的问题
中台架构解决了很多以前传统项目开发的问题，使得研发过程整体变得自动化，中步也产生了一个新的问题：中台太重。
维护中台过程重
由于前期大量的微服务技术体系，多组件整合，架构体系相对于一般的中小团队来说，已经较为庞大，基于gitlab的管理，原有的业务组件不断的增加能力，同时组件不断增加，前期单一基线，源码包由原来的十几个工程，迅速变成上百个工程，几百个组件，而且每一个业务项目的建设，就会增加新的中台能力沉淀，当然，这也是前期的初衷，也达到这个期望。
中台越来越庞大，对于中台团队来说，带来另一个致命性的，组件的关联性。南宁本地团队有一定的特点，一个是流动性，另一个是人员的培养性，这几个带来的问题，就是除了中台小组的几个人，其它人很难维护中台，同时由于前期放在同一个基线，代码量巨大，增加和修改功能，都需要极度的小心和避免影响项目，新人更加无从下手。工作量立杆见影的往上提升，甚至后面有些组件基本上不沉淀了，太多了无法维护。项目组开发过程中，出一个简单的问题，找人找问题都很难，业务响应速度下降，项目组不满程度突显。
前期通过招人，培养，文档来解决，后来发现，这也是一个艰难的工作，特别是文档，几百个组件的文档，对应的文档同步工作量也是庞大的，有很多陈旧的文档跟新功能对不上，特意找了写文档的人，但是产出还是没有达到预期。
另一个包括多项目，多版本，新旧版本维护等，这些维护过程来说，积累多，量也大。过程中不断增加的中间件环境，整个中间件技术宽度就很大，技术链路越来越长。
基于以上种种，针对于中小团队来说，原来小组对中台的管理，每个组件的升级管理，维护中台过程较重。
团队成长技术债过重
中台从基础框架，技术平台，研发中台，数据中台，还包括后期的智能平台规划，整体平台的技术债过重。原有的技术体系超过120个技术框架或者工具，每一个技术点都要求研发人员拥有快速学习和掌握的能力，需要消耗大量的周期时间。
架构体系更新太重
技术中台和研发中台的搭建，到后期的业务中台整合，前期考虑到中小团队，形成统一技术路线，这相对来说是好的，同时也避免了各种框架的混乱。但是在后期，要升级的时候，这个问题就是另一个灾难了。
前期考虑多架构融合，业务可选，在调整升级几个版本之后，发现，新旧项目切合越来越难融合。
创新和升级受约束
中台立于同一个基线的管理，同时过大的关联性，在新的业务组件建设中，带着沉重的中台包袱，用还是不用中台就成了一个问题，甚至有一些感觉鸡肋。用了，后期在其它项目使用可能会带着一连串的中台组件，比如一个简单的业务新组件，后来带的是注册中心，消息中心，缓存中心，还有n个关联的中台组件，甚至有可能找不清，链路过程找不到，去掉，发现有些工程又跑不起来，不去掉，又太重。过程需要讨论，这过程无形中又消耗去时间。
另一个是单独升级的组件的，可能无形中又影响其它引用的服务，考虑加版本，但是你根本就不清楚到底有哪些接入，无法确定是否升级，然后又需要讨论，仅仅找到相应的负责人确定方向，过程中无形又消耗时间周期，更可怕的是，前期的负责人可能自己都会遗忘前期的设计思路，或者负责这块的人员已经离职了。
为什么一定要拆分重构
在长期的沉淀过程中，慢慢形成资产，但是也造成了隐形的约束。
产生强大的内耗
内耗跟消化过程有一定的区别，前期的团队的对中台的理解和运用，基本上已经很熟悉，新人进入，基本上一个星期内就可以了解熟悉接入项目过程，这里的内耗，指的更多的是团队对中台的管理，围绕中台问题和管理上的消耗，这些基本上是无形的，开始基本上无感。
无形中产生的错误的架构思维
中台架构的思维，无形中影响着很多项目开发人员，技术经理，基本上内部已经形成约定的规范，照着上面的思维整合项目，项目无形中，也同步形成了很多组件，形成组件虽然是对的，但是由于架构思维的偏差，形成的是大量重复的组件，这些组件的兼容性还有共性是比较大的，在进行多个项目之后，会发现可能形成多套服务架构。在这里多套也是没有问题，重点的问题，这几套的维护人员，支撑人员，还有管理人员等等都是分散的，业务也是分散的，这个一下就会形成无限的服务组件，甚至有可能是指数级的增长。
对于大型团队，比如上千人的团队来说，可能问题不大，但是对于中小团队来说，这几乎是灾难性的，外加上人员流动缘故，另一个是地方人才等问题，可能很快就会变成团队压力负担，最后产生一个疑问，还要不要使用这个技术中台。
制约企业战略规划
前期中台架构，过分依赖于技术组件的复用性，偏向于技术体系，没有能从解决方案思维架构上的整合，无法跟进当前行业的发展。
中台的建设，团队的消化，项目的接入，业务的维护过程，整个下来，中小团队少的可能1年，重的可能3-5年，这个过程基本上团队没有精力再思考其它，对一般的企业来说，有限的资源力量，就无形中成为一种制约。
拆分过程是怎么升级处理
拆分思维从大中台，小前台，转变成轻中台，小前台，大平台架构指导。
中台怎么拆
一个基线的拆分，每个组件针对颗粒度形成一个单独的管理基线，同时明确中台的管理边界，哪些可集成，哪些不可集成，哪些需要放弃，哪些需要重点建设，进行重点精度升级，在架构上形成边界。
明确中台版本的管理，稳定版本的管理，一定确定出稳定版，同时划分明确中台组基线的管理范围，中台组件范围，非团队或者企业核心组件，不做整合，做好分界线。
明确上下游关系，每个组件提供标准稳定接口，明确上下游组件，另一个是提取出核心业务领域，面向接口编程，如下图：
这样无论外围技术升级和划分，核心业务领域尽量少动，切换的是领域外围，形成稳定的企业核心资产和版本，同时避免技术升级带来的核心业务代码变动。
去掉非通用协议，当然，也可以不去掉，主要看技术债和团队问题，针对于我们团队，当时直接全量升级，从RPC协议调整成Http协议，如果是cloud技术，这个问题就可以免掉了。
后期怎么升级维护
基于中台服务的拆分，各个业务组件和服务，都有可能变成一个单独的业务线，在设计和方案，还有新技术的增加上面，新需求新市场变动变动上面，变得相当的轻量，不再需要关心过多的中台包袱，开发人员的思维和思绪更偏向于这个组件的完善上面。
每个服务的架构和变动上面，就会变得很轻量，升级维护可以根据每个组件和负责人不同方案，进行最合适的升级处理。需要添加的服务和模块，就不再是有累赘，过程的指导由中台运营手册去做管理指导，形成轻量级的公共组件和服务。
提供出来的接口和服务，在不影响其它人的引用即可，同时做好前后兼容即可，侧面增大了k 中台服务组件的包容性，通过中台定制的管理运营规范，按一般的java项目管理维护即可，这里就不再过多阐述。
中台要拆成什么结果形态
这里的形态，整个过程由单体到服务化，再到微服务，大中台小前台，再到进一步升级的结果形态。
基于新中台模型架构
中台包括很多层面，不仅仅是技术，更多的是业务的挂钩，不仅仅是技术的改变，更多是模式的改变，比如规划、产品、沉淀、落地、资源整合等一套体系，而不是说，我们就做那么个框架或是技术平台，而是一个更高一层的思想架构提升，这里定义的新中台的模型包括以下几点：
- 产品：企业团队沉淀能力体现
- 解决方案：客户业务价值体现
- 组织架构：价值落地的保障体现
- 技术：技术是落地的直接能力输出
- 合作体系：业务发展能力体现
- 沉淀：发展和突破点积累体现
结合上面的新中台阐述落地体系，从几个角度思考愿景方向和发展走向形势参考，主要思考的几个点：
- 新解决方案：业务价值能力输出
- 新服务模式：客户业务价值输出
- 新发展模式：S2B 商业模式输出
从整体上表述新中台的模型和愿景方向，也是数字化社区的目标和愿景，整体愿景期望的已不仅仅是数字化，更多的是以数字化为基础，进行更好的发展方向。
行业产品形态能力输出
行业模式，不仅仅是目前的业务维护，更多的是基于新中台架构行业发展地位和企业发展的基础。
相应的市面上产品示例门户体现参考：
- 钉钉门户
- 金蝶云苍穹门户
总结
以上为中台拆分过程的一些过程和思路，每个架构师或者技术负责人有自己的思路，上面是自己在整合过程的总结。
ACP社区版本初步讨论会议（一）
会议方式
线上腾讯会议，5月2日早上10点半
会议内容
- ACP中台版本的架构思路和发展愿景
- 旧中台版本与新中台版本的区别
- 社区版本的产品范围边界(业务整合)
- ACP中台和业务整合落地经验参考
- 中台架构的整体建设进度和计划
会议调研表
我对新中台模型的一些经验思考总结
前言
以下为自己的这几年关注发展的一些总结和思考，带有比较强烈的个人观点，在这里做一个简单的笔记。之前在新的章节里面提过，对中台的思考和理解，总结出来的一套新的中台框架和落地模型。
概述
新中台模型并不新，只是对中台的一个整体的模型更加明确的定义和思考，从另一个新的角度进行的思考整合，而不是以前的复用组件或是公共组件，这里阐述自己的思考点。新中台架构是行业的另一种变革，是一种新的标准，突破传统的研发模式，类似于云服务一样，突破传统服务器的行业模式，在这个模式下，提升企业的发展战略，跟进时代前进的步伐。
新中台模型
中台包括很多层面，不仅仅是技术，更多的是业务的挂钩，不仅仅是技术的改变，更多是模式的改变，比如规划、产品、沉淀、落地、资源整合等一套体系，而不是说，我们就做那么个框架或是技术平台，而是一个更高一层的思想架构提升，这里定义的新中台的模型包括以下几点：
- 产品：企业团队沉淀能力体现
- 解决方案：客户业务价值体现
- 组织架构：价值落地的保障体现
- 技术：技术是落地的直接能力输出
- 合作体系：业务发展能力体现
- 沉淀：发展和突破点积累体现
结合上面的新中台阐述落地体系，从几个角度思考愿景方向和发展走向形势参考，主要思考的几个点：
- 新解决方案：业务价值能力输出
- 新服务模式：客户业务价值输出
- 新发展模式：S2B商业模式输出
从整体上表述新中台的模型和愿景方向，也是数字化社区的目标和愿景，整体愿景期望的已不仅仅是数字化，更多的是以数字化为基础，进行更好的发展方向。
新中台模型阐述
新中台模型是企业能力输出的的最佳唤醒和集中力体现，解封自己的能力沉淀，通过新中台模型体现和输出。
产品
产品的作用是沉淀的体现。
这里的定义更多是复合复用组件的角度，主要目标是完成基础的建设目标，主要是解决人员，团队无法从繁重的开发中抽身的问题，从这个角度，跟前几年思考的中台思路是一致的，减少重复工作，解放开发和项目管理人员，提取出团队核心业务能力和业务价值，发挥团队的核心能力。
比如业务系统集成核心能力在业务上，形成自己新的业务角度，而技术能力集中在技术服务上，重点沉淀出技术方案，每一个层级的人员抽离，类似于前后端，做好自己等分工。 对于企业来说，核心能力基本上是前时间的积累，不管是方案、技术、经验、团队等，脱离大包大揽，把中台层打得更薄更轻量，发挥每个节点得核心作用和价值体现，业务的往业务专家方向，技术走技术专家路线，这些在企业内部基本上都是存在的，技术在小的团队，也有自己的能力，产品，更多是企业的沉淀体现。
解决方案
方案是新中台业务价值的最直接体现。
解决方案是业务价值的输出，主要是包括团队对业务的认知能力，经验能力的体现，也是核心能力的最佳输出实践。这些是企业和团队的业务壁垒，也是核心竞争力，别人无可替代的。 解决方案是跟产品一起匹配的，也是跟行业、政策、大环境等互相整合的，这部分体现的更多是文档的输出，形成自己的业务解决方案体系，形成自己的行业业务壁垒。
组织架构
组织架构是落地的保障和团队方向输出的提升。
传统的人才技术，是无法跟目前的行业发展相匹配的，或是很难，这个不仅仅是体现在上层战略和下层之间的大隔阂，战略发展的不稳定，更是业务的发展，组织架构的设计的调整，更多的是为后面打造出高层级团队，培养专家型人员作基础。
普通的帮带模式，在前期落地是存在一定困难的，他不能从根本上去打造团队成长的环境还有级别，组织架构的消化和适应，更多需要很长周期的消化，达到适配点，跟战略需求互相匹配点。 形成中台的人事综合，技术专家，业务专家，交付专家，行业布道师等形成一体化，达到中台各个节点的最优驱动力，达到中台的顺利交付落地。
技术
技术是落地的直接能力输出。
技术包括的不仅仅是微服务，devops，技术框架等，这里包含的是人才的培养，技术培训体系，入门体系，业务学习系统，成长体系等，在落地过程中，输出技术人才和促进组织架构的成长，人才能力的培养，专业成长的学院，文档的输出，技术学习提升的氛围，互相学习提升的机制等，进一步的保障基层的稳定和人才的培养、提拔等。
不管是那部还是外部，整体中台的落地，需要的集中更多的技术人才，业务人才集中起来，而技术环节的建设，为上层提高了落地的能力，也更加的明确出中台层级划分。
合作体系
合作是行业发展能力和资源的整合需求
合作共赢，形成生态体系，是中台的另一种输出方式体现。在快速的发展行情下，单独唯一的业务已经很难在目前的大环境下输出。有一定的业务场景，但是无法突破原有的业务能力。团队，资源，业务等限制，会把团队压在某个层级，无法也没有精力进行突破，卡在某个点上，无法进行更大发展点。合作体系的建设，isv的整合，产品能力的输出，更多的会提升行业竞争力，也同步提升产品的发展和整合的思维，进一步的提升业务能力输出和发展面积，推动中小型企业的行业地位和发展。
这里的合作包括且不仅是isv体系，外包体系，其它各个项目体系之类的，更多的是形成一套合作方式，进一步的进行资源整合，形成稳定的关系链路。
沉淀
沉淀是长期发展和成长突破的需求
产品和解决方案的整合，组织团队和技术的发展，这些过程的沉淀，会更多的积累到新中台架构，形成量级别的积累，同时也是创新能力的发展和积累，这里沉淀的不仅仅是技术，更多的是团队、思想、业务等，为企业和团队下一步发展打下基础，为跟进下一个技术或是业务产品打下基础。在这样的条件下，在合适的时期和环境下，这是为企业发展和突破做相应的准备。
行业落地模式
行业模式，不仅仅是目前的业务维护，更多的是基于新中台架构行业发展地位和企业发展的基础。
新解决方案
解决方案的积累和沉淀，在原有模式下，基于新中台模型，可以把前期资源抽出和节省，让团队有更多的发展思考时间，进行更多业务创新的突破。
新中台带来很多的思维和思考，带来更符合发展的团队能力，同时也带来更多的业务场景学习，在积累和沉淀下，整合出新的行业解决方案，进行业务和能力的突破。
新服务模式
在旧的模式中，服务模式的变更包括很多方面，原由的项目模式更多的进行进行能力输出的转变，包括业务模式的转变，产品模式的转变，不再是传统的研发服务，更切合的贴近于服务中小型企业的商业模式点，以前的服务模式可能类似于传统的软件服务，提供软件服务的一条龙形式，然后团队专注并且沉在这个里面，然后不断的投成本，投人力等，形成一个无法突破的闭环，无法产生新的思考点。
以客户服务第一的原则，利用自身业务沉淀的优势，整合出新的大中台能力，然后集成各类ISV模式，提供更优质和创新的服务能力，更好的业务体验和业务场景挖掘。
新发展模式
利用新中台巩固自己的发展壁垒
在新的服务模式里面，更多的是产品型的服务模式，形成合作生态，产生共赢，形成大家利益的最大化。利用新中台模型，产生出新的团队能力，更加专业于团队业务产品，提供更为专业的服务。而每个层级分得更加明显，产生出服务能力，专注于产品本身和用户本身，转向新的思考，融合多个团队，多个行业的发展，形成S2b的模式，带动行业的发展，整合各类资源，形成自己稳固的业务壁垒。
总结
新中台能力的建设和输出，可以更加的切合当前行业的发展和团队业务的发展，形成更大的价值，理论上应该可以做得在某个行业做得比较突出。
以上为自己对当前中台发展的一些思考，较为偏主观，主要是对自己提升另一个层级的思考点，也是自己在各个方面落地过程中的思考总结点。
从多城市落地中台的经验总结和标准化输出思考
接触到中台和微服务技术支持和落地的城市有多个，涵盖一二三线城市，以下为自己一些思路总结。
于2020年下半年，贵阳的一个项目二期整体上线，使用最新的AI技术路线，几乎都是新的试点尝试，完全互联网思维落地政务项目，快速交付，快速落地，又是完全另一种打法。
从二线城市项目技术支持和规划过程中，联想其它城市项目技术支持过程中的一些中台经验总结，我有我思。
一、关于中台落地项目建设的情况：
针对于多个城市的情况，每个项目基本上都带有较为完整的业务体系。
1、有基础软件平台的体系雏形：
中台建议从技术引入、试点、建设、运维，整个结构有了软件平台的原型，从操作系统、控件、第三方、中间件、技术、基础组件、知识积累等都有较为完善的体系，包括目前多团队接触，消化的情况都较为良好，市场教育和人才培养基本上都有基础；
2、有大量的基础包：
从每个项目建设到现在，积累了很多的基础控件，基础控件指的是常用的基础包、工具、统一变量等，以前的，包括现在的项目都积累很多的基础包和工程，而这些工程包又有很多是重复的，同样的；
3、有较为完善的基础组件体系：
从业务组件的规划过程中，有较为完善的基础组件，公共组件，公共服务，业务组件，同时存在很多的业务组件，重复的基础工程组件，比如短信、ORC、打印、公共、统一桌面，这些基础组件体系都存在，且具有成熟性（并涉及多个业务场景，多个项目场景，并不代表没有bug），但是一样存在重复的，不可共用的情况；
4、有较为完善的业务组件体系：
从几个城市项目工程，每个行业项目基本上都积累了较为完善的业务组件体系， 成百上千的业务组件，上万的外部接口 ，信息管理类项目（如管理系统、OA），这些组件都包含有业务性，涉及和比较完整的政务行业业务，甚至可以理解（可能自己业务理解不够深入的理解）成较为完善的政务行业信息体系模型；
二、不足之处及问题反思：
正是以上的情况，才导致引出问题点所在。
1、微服务规划的缺陷和技术债问题：
异常化项目规划有太多的服务，而服务之间不能通用，导致产生重复的服务规划而不能共用，而产生很多的重复技术债问题（这点在开发人员在过程是比较难有体会，比如开发某模块出问题了就调试，精力都会往调试技术比例加重，业务调试比重降低），服务规划之间并不能完全符合我们目前团队场景和业务场景而进行共用（比如一个实际场景：多城市、多项目、多团队、跨地域开发）。
基本上都是沟通相当难，而且过程支持也不容易，特别是跨地域，跨团队
2、没有明确的里程碑目标和稳定版：
一直在微服务，总是在微服务。
这个问题最明显，同样也是最实际，很多好的的工程或者服务，组件也好一直是快照版，至今没有基础稳定版，这个问题会导致一个很明显的问题，开发一更新就有可能出错，即使之前的项目已经上线稳定。有一个稳定版，开发在使用的调用的时候，开发就会用这个版本或者加强，而不是多个城市或者项目的复制，在团队资源有限的情况下，很难消化每一次“复制”带来的几十个工程的维护，甚至有些苦涩。
3、原架构设计存在缺陷：
原单个项目的技术架构设计或者整个平台架构设计，组件规划，在单个项目，或者在小型项目上，具体一定的先进性，但是在与我们实际团队与项目中时，出现水土不服或者说是未能达到预期效果，甚至可能出现部分不理想效果，比如硬件、软件、技术债上都比较难消化 ，架构师的设计，包括网上（互联网）存在一定的先入为主，很多原接触的名词未必符合我们的场景，如高并发，高可用，微服务，多服务，分布式。
4、平台体系不完善：
体现在没有合理的基础环境建设，比如租户隔离，环境隔离，容易产生互相影响问题。缺少技术上（而非业务）自动化运维建设，服务的检测、发布和监控，还是较为被动的接受，而多数是人工很难做到这步，技术运维和业务运维两个比重权衡考虑。
三、中台标准化建设思路 ：
提取出业务核心元素，整体低阶业务平台，推进形成行业业务标准化。
1、调整平台架构设计，重点往业务SaaS建设：
业务和平台架构设计使用的是着重于业务架构建设，提升稳定性，维护性，快速迭代性，在基础组件和控件完善的条件下，调整原有的平台架构规划和组件规划，往业务组件建设，基础组件，基础控件与开发人员做一定的隔离（另一个词叫透明）。 在目前的完善的业务组件体系下，提取业务组件的核心业务元素，重点在业务的SaaS建设，减少业务切入成本（如新人学习业务成本，调用api即可，不符合再继承单独实现），减少技术债成本（如业务api，维护提取的只维护SaaS），减少运维风险成本（即稳定版和快照版的问题）。
在看微服务架构和中台架构时，工程有这样的设计趋势，但是在对于差异化业务服务时，但是没有将原设计精华提取，消化并整合到整体架构设计中。
2、制定稳定版本，调整服务规划为API规划：
一个明显且事实的现象：在我们的业务场景里，每个城市业务规划的服务在多城市之间，多项目之间是不能共用的，都是复制。
设计规划往上再进行一层抽象，调整服务规划转变成API规划，项目在SaaS的API上层改造，而不是在服务上进行改造，服务只是依赖api。比如业务系统系统api，新的项目只是在业务系统的api上层改造，而不是复制整个业务工程，api有版本号，而不是一直是快照版，有快照版的应该是工程，而不是api。减少工程泛滥的情况，同时减少组件维护成本。至于服务规划，只是在项目时再做规划即可，与很多规划无差异。
3、完善运维体系和建设目标：
建议尝试试点使用云基础环境方案，市面上已经有很多成熟的云基础方案，比如CloudStack、Kubernetes、OpenStack等，解决资源的不合理使用问题和租户问题。自动化运维建议尝试使用能用的检测方案，如批脚本监控，自动检测端口，常规自动巡检等。
四、总结
从多城市技术支持过程中联想到的平台的经验总结和一些建议，包含有一定的主观和客观，请参考和了解 。