此为升级经验输出，主要针对于vuepress2.x集成algolia的过程。

背景

文档和官网是acp输出能力的体现之一，原基于vuepress版本为0.x版本，中间做了部分升级，也走了一些问题点，这里同步做个记录。

集成找到资料比较多的方式是按vuepress官网提的使用邮件发送，然后回复，但是经过几次之后，发现周期慢，而且貌似最后也没有见key和index发到邮箱里面。

考虑左右，使用api文档上传的方式，但是vuepress集成的时候，algolia提供了相应的配置，同时可以集成github action进行提交，集成效果如下：

升级集成的仓库地址如下：

https://github.com/alinesno-cloud/alinesno-cloud-platform-press

集成思路

这里自己三种方式集成，这里做一下记录，主要是：

• shell脚本集成
• github action集成

Shell脚本集成

shell脚本集成是比较快速的，这里主要几个步骤：

• 注册官网，获取到key和appid
• 获取docsearch，配置config.json
• vuepress集成验证

注册官网

官网地址是：https://www.algolia.com/ref/docsearch 按着步骤注册即可，同时生成应用和获取apikey，官网操作相对比较简单，这里就不过多阐述。

这里需要注意的一点是，index会自动生成，所以只需要key就可以（注意是admin-key）

获取docsearch配置

这里主要在linux上操作可能会比较简单，我这里是mac系统，windows的可以使用github action集成验证，这里是docsearch的下载地址：

https://github.com/algolia/docsearch-scraper

下载之后，生成config.json文件，注意新手尽量使用下面的config.json配置，之前也是验证了几个方式都不太顺利，如下：

{
  "index_name": "acp_linesno",
  "start_urls": [
    {
      "url": "http://alinesno-platform.linesno.com/",
      "selectors_key": "v2",
      "tags": [
        "v2"
      ]
    }
  ],
  "stop_urls": [],
  "selectors": {
    "v2": {
      "lvl0": {
        "selector": ".sidebar-heading.active",
        "global": true,
        "default_value": "Documentation"
      },
      "lvl1": ".theme-default-content h1",
      "lvl2": ".theme-default-content h2",
      "lvl3": ".theme-default-content h3",
      "lvl4": ".theme-default-content h4",
      "lvl5": ".theme-default-content h5",
      "text": ".theme-default-content p, .theme-default-content li",
      "lang": {
        "selector": "/html/@lang",
        "type": "xpath",
        "global": true
      }
    }
  },
  "scrape_start_urls": false,
  "strip_chars": " .,;:#",
  "custom_settings": {
    "attributesForFaceting": [
      "lang",
      "tags"
    ]
  }
}

其实algolia官网也有配置参考，上面是针对于v2版本做过调整，参考的config仓库是这个:

https://github.com/algolia/docsearch-configs

获取到配置之后，运行docsearch文件，第一次运行的时候，会提交让你填写appid和key，主要保存在.env文件里面，然后提交官网索引，生成效果如下：

./docsearch run ./config.json

生成之后，可以在官网的地址查看生成的索引情况，注意上面的应用选择和索引选择，如下：

官网提供了一个测试的办法，进行验证，如下：

./docsearch playground ./config.jso

会生成一个简单的测试界面，这里就不过多的粘贴。

vuepress集成验证

这里集成主要参考官网的链接就可，具体链接地址如下：

https://v2.vuepress.vuejs.org/zh/reference/plugin/docsearch.html

修改好apiid和key，下面是我的配置，也是参考vuepress2官方的：

appId: 'HAT6A1ER66',
apiKey: '1c5e0970f29dd7423d668b1fd245a7e2',
indexName: 'acp_linesno',
searchParameters: {
  facetFilters: ['tags:v2'],  # 注意这个地方
},

github action集成

这里主要参考基线的代码，这里就不做过多的阐述，主要集成的workflow.yaml文件可以从这里获取：

https://github.com/alinesno-cloud/alinesno-cloud-platform-press/blob/2.1.0/.github/workflows/docIndex.yaml

注意一点是，上面是创建了一个.algolia文件来进行配置。

其它

以下即集成algolia的教程，主要参考的资料地址如下：

• 文件配置：https://github.com/algolia/docsearch-configs
• 生成索引：https://github.com/algolia/docsearch-scraper
• 文档配置：https://docsearch.algolia.com/docs/legacy/run-your-own/

此为实战经验输出章节，重点在于自我的经验总结和实践经验记录，自己在整个过程角色是架构师和研发部门负责人角色，即设计和执行合一。

背景

开始介入的时候已经基本上完成一版本，部署和架构基于传统的服务化方案，进行RPC之间调用，服务器和监控的模式还是传统的虚拟机资源分配的形式，项目管理按传统的软件工程管理进行。项目的规模属于中型项目，政务民生类项目，用户规模大概在城市级百万级左右，每天涉及到资金交易在亿级别，项目周期大概是1年多，属于业务型服务。

以下阐述规避涉密因素不涉及相关单位和公司字眼。

概述

从传统业务架构的服务器发布，同时也包括项目管理开发流程（CMMI5结构），再到传统的项目管理运维等进行架构升级，升级的目标为业务中台架构，为下一步数据运营管理做好基础。升级过程从团队、专家、业务、架构等几个维护进行的调整，以适应当前IT行业的发展和数字化市场环境，在这个升级的过程不仅仅是技术项目的升级，更多的是组织架构，团队技能的升级，以消除前期传统模式留下的弊端。

升级过程阐述分三个维护，主要升级的成果点：

• 传统系统架构升级中台系统架构模式，即提取业务中台，大中台，小前台模式；
• 管理模式转换成中台组织架构模式，即中台专家支持，业务兵团走前端；
• 软件项目开发转换成行业产品型研发，即输出项目的同时输出中台产品型服务；
• 传统的运维模式升级成自动化运维模式，即全方面的运维监控体系，可自动化可预警；

按前期-中期-后期三个时间段时间编写，整个过程我有我思。

升级过程

这个过程无疑还是一个突出的问题：决心。中台型的转变需要整体团队的互相配合。每个节点做好自己的事情，需要上下一心的转变，领导层的意识和可行性的架构能力的支撑。

过程基本是老打法、老方式，而这也是最有效的。

前期

前期最主要的还是团队的意识，这里的团队包括的不仅仅是一个组，而是整个团队的上下意识，这个过程调整了组织结构，这基本上将原有的项目管理模式归由研发部进行整体指导，主要是：

• 调整组织结构，技术支撑下沉到研发部，由我这边进行统筹；
• 技术架构重构，进行二次架构的升级，形成全体升级转变的指导思想；
• 将升级战略上升到团队最高层面，思想意识统一；

以上两步基本上解决了执行的基础保障，也是中台架构的基础保障条件。

架构升级的前期遇到的最突出的问题，旧系统的切换，这是一个矛盾点，在不违背大家过大的意愿下，调整的架构设计，当中也做了很多妥协，另一个是牺牲一部分技术妥协团队的接受，一步步推进。从上而下的业务模式改变，主要包括几个点：

• 虚拟机转变成k8s容器化，升级虚拟机配置，减少服务器数量；
• 发布过程集成docker容器化，同时调整最小配置，减少大家的学习成本；
• 流量的切入转换成对外nodeport的形式（rpc协议），这是一个妥协点，主要还是考虑到技术的过度；
• 服务化设计保留原来的基础工程结构，保留前期的CICD还有服务调用模式。

上面几步基本上解决了基础层的问题点，还有过程持续构建的弊端点，资源不稳定点等。

中前期

基础层的解决和保障，最终还是回到业务建设上。

最可能出现问题的一点和沉淀能力的抽取考虑上，原业务架构，比如原来就没有考虑到这样的方式，进行的项目还有工程研发等，这个基本上最有可能导致后期上线不稳定的因素，做了几点：

• 培养和完善手册，还有培训机制，将各个责任点下放；
• 保留原服务工程的调用机制，尽量在k8s上进行妥协和解决问题，实在不行的再调整业务代码；
• 完善运维机制和监控机制，原有的业务排查方式和发布式的转变；
• 多层面上进行运维角度的整合，包括系统、日志、链路、流量、灰度等多个层面的保障；
• 去掉一些不可控的业务节点，保留原运行模式，规避各类安全策略的问题，这也是一个妥协点。
• 业务服务抽取可形成产品模块，此从业务层面进行妥协，调整代码和项目结构；
• 多处运用消息机制，进行业务模块的解耦和可产品化调整，此也从业务层面上进行妥协。

基于以上多种结构的调整，基本上业务中台架构的雏形很快体现，这个过程消耗了差不多几个月的时间，基本上还是符合预期点，在有项目的推进下，其实各个部门还有项目组基本上感知性还有排斥性没有多大的体现，在研发和技术的支撑上，转变过程基本上无感知。

中期

这是一个问题暴露阶段，这个过程需要的全员的配合，这也是为什么在前期下放责任和思想 统一的原因点，一个架构师，一个部门是无法支撑起团队能力的。

过程问题最突出的一个体现：信心问题。这个是前期自己的问题点，当然，这也是在自己把控范围内的一点，也是必然会出现的一个情况，这个跟以前转型（自己在多家大中型团队做过转型）基本上是一模一样的问题体现，有的时候，在理论上是可避免的，但是在操作上却是不可避免的。

初期的验证和转换调整操作，基本上觉得没什么问题，但现实是不可预知的，在综合业务场景上并不等同于互联网型的通用项目，行业软件存在很多不一样的因素，它里面包含了很多复杂的业务逻辑，类似于银行系统，并不是那么敢轻易换掉oracle一样。当前项目也涉及到大量的资金交易也较大。在上线暴露问题点的同时，很多找到的解决方案都没有涉及到，这步让团队在切入过程中，心态上比较紧张，对新架构的信心程度还有各个节点的支撑人员也头疼。

一个场景是在前期基本上按k8s服务之间调用方式来进行的，但是在内外网络隔离，还有外围服务的时候，IP判断的问题，还有各种第三方插件的问题等，还有各个使用群体（比如银行）上相应表现不佳。沟通协调，排查困难程度较大，单个层面无法解决，最终是上下层统一协调解决点。

类似于上面的场景，并不是说有多大困难，而是部分场景下没有思路，各种条件下问题比较隐性。这个过程是团队会面对的问题，在最终解决下，会更进一步的提升团队的能力点，最终达到内部接受到自然状态。

另一个是一些操作的不成熟，还有验证性，需要大量的生产和测试验证，以确保可行性和后期的稳定性，这些前期验证环境有操作，但是也有很多未知，这些都是要面对克服的问题，这个过程几乎都是熬夜过来（几乎每次转型都遇到类似），同样需要整体团队的解决能力。

后期

这里针对的是在架构设计层支撑和中台研发团队架构的支撑上的后期。

到这一步的时候，业务中台架构基本上便向于稳定，由原来的中台架构雏形，转变成业务中台架构。不管是技术、团队、业务、专家还有各个场景下的沉淀都已经有了沉淀能力，包括解决方案等，形成一套业务中台能力点，主要包括以下几个点：

• 团队组织能力，形成中台组织架构保障，研发层和业务层；
• 技术沉淀能力，形成技术中台和研发支撑层；
• 产品输出能力，形成行业产品沉淀，形成基础的行业标准产品组件；
• 解决方案能力，在行业软件中形成一套可行的解决方案；
• 中台业务能力，业务大中台产出，小前台业务建设的综合能力。

余下的，更多的是架构设计的前期问题梳理和进一步的优化，各个管理功能的完善和进一步沉淀产品能力，集成到中台管理平台上，同时在各个团队和小组之间进行经验分享和总结。同时为下一个业务场景进行梳理。

其它

按目前的行业发展来看，当前AI、物联网等智能化的发展迅速，在进一步待场景和人才，目前也在整合这些能力点，在业务中台化建设的后期，同样会在中台化的基础上融入AI、物联网的基础产品能力范围，在行业中台上面进一步的升级业务中台大脑。

主要升级计划周期为5个月（研发3个月/测试2个月），升级目标为一键数字中台化，过程当中维护2.1.2-RC版本为主（后期推出Release版本输出）

研发中台

主要用于升级优先，跟进行业主流技术框架

• 升级vue2转成vue3，升级element-ui转成element-plus
• 升级springboot到2.7.x版本，jdk支持11以上
• 数据中台输出文档vuepress主题由0.x升级为2.x版本
• 本地开发环境，可以不使用sso登陆集成，到生产发布再集成sso，达到可配置
• 代码生成器多种关系库的代码生成器，主要Oracle数据库/国产品数据库等支持
• 代码生成器集成多语言支持，当前集成quarkus语言开发模板
• 资源引擎平台可选择应用模板，快速创建一个应用，包括菜单，权限，账户，代码等
• 平台中获取用户通过 @CurrentAccount 方法注解获取
• 集成jeninsfile快速部署，并集成一键部署能力，包括k8s/docker/fastjar
• 集成明道云前端界面和低代码框架，集成无代码开发能力，后台使用acp管理功能
• 优化和完善工作流引擎
• 数据库统一升级到8.0，平台数据库新版本不再使用5.7版本

数据中台

数据治理产品主要针对通用型的业务场景，部分可采用开源解决的则不再产品型开发，比如元数据管理，报表等。

• 数据采集平台推出RC版本，面向开发人员和非研发型人员，数据仓库升级为数据湖；
• 数据目录平台推出RC版本，重点在于数据的梳理分类，数据的共享下载
• 优化和完善数据数据融合平台，提供专业型人员的数据采集能力（此为工具，非产品型）
• 数据开发集成dolphinscheduler，整合数据中台统一认证服务，定义数据开发流程标准
• 主数据平台推出RC版本，重点在于数据的标准定义
• 数据中台推出用户画像产品，并集成研发中台会员管理服务推出Beta版本

其它

版本升级以实际情况为主，社区团队会尽量偏向于计划时间升级输出。

此为产品输出章节，中台是数字化的最佳实践，ACP是针对于中小型团队，全新一代企业级标准的数字化中台底座

此文档针对于白皮书场景的产品介绍方案参考

中台产品概述

数据中台是ACP能力的一部分，利用业务+数据的能力，推进企业快速数字化进度和上道，先发制人。针对于中小型企业数据管理，数据治理的场景，同时对外输出数据治理和运营能力，形成业务和数据的闭环操作，这里针对的是中小型的基础数据管理能力，并非针对于大而全的数据场景，整体数据治理的业务架构如下：

从底层的业务治理和管理，梳理业务运营管理，包括多方面的数据采集管理分析，采集数字运营数据中心，形成统一的数据治理服务平台，通过数据分析集成，提供数字化运营大脑。

数据中台能力

• 数据的抽取和采集能力
• 数据的清洗能力
• 主数据的标准定义
• 数据的离线计算和实时计算能力
• 数据服务提供能力

解决团队数据场景

• 数据中台基础架构原型
• 数据的管控和采集治理
• 业务和数据的运营管理

ACP数据中台能力

数据抽取和采集

数据采集上报服务，主要针对于政务、个人、单位等通用型的通用数据采集上报平台，用于数据入湖的方式之一。 此处主要包括非结构化数据和半结构化数据、结构化数据等场景，同时便于收集多种数据来源，同时包含有 资源目录的规划和划分功能，是数字化平台的前置应用。

架构描述:

• 非结构化数据采集上报针对于非业务性人员，同时提供数据共享和分享服务
• 半结构化数据数据采集来自第三方梳理和采集管理
• 数据源采集通过 etl 和数据同步等方式进行数据的传输梳理

数据治理过滤

主数据标准定义

数据离线和实时计算

数据服务提供能力

解决团队数据场景

数据中台基础架构

针对的业务进行的实施方案，针对于不同的层级提供不同的技术解决方案，进行智慧业务系统的建设

业务架构从业务层数据分析采集管理，数据上报到大数据平台，同时包含多种数据资源的管理和数据目录的分析管理等，形成一套数字管理平台。针对于多种业务数据场景的数据分析，结合业务中台的，形成一套数据中台，对外输出数据服务和网关数据服务。

数据的管控和采集

业务和数据运营管理

总结

其它

• 无

此为产品输出章节，中台是数字化的最佳实践，ACP是针对于中小型团队，全新一代企业级标准的数字化中台底座

此文档针对于白皮书场景的产品介绍方案参考

中台产品概述

企业级研发中台服务 ACP（Alinesno Cloud Platform）是业务应用生命周期管理和监控的新一代中台， 针对于大中小型团队合适的开发平台，支持微服务化、中台化、统一权限和基础能力管理，数据采集、计算、数据运营输出， 统一业务规范，集成 DevOps 自动化流程，为业务上层研发提供基础的 研发环境，规范化的开发，为后期业务的沉淀 形成基础，为数据治理形成基础，更好的沉淀企业业务资产和数据资产,业务架构师的规划， 进行核心业务的改造和各个业务线的整合，形成行业的业 务标准和 一套解决方案，形成自己的核心竞争力。

ACP主要针对的是中小型团队的场景，包括企业研发部门，外包，行业中小型软件公司，甚至是1-3个人的技术组。

整体ACP产品思路通过两个维度多个产品点介绍，大纲如下：

数字中台的基础能力

• 标准的数字中台产品基底，完善的中台管理体系
• 标准的中台体系，包括技术/框架/产品/中台/团队/交付/输出等，完善的应用周期管理
• 适配多行业的业务中台建设，支撑行业软件快速中台化，数字化，迅速升级
• 完善的SaaS应用周期管理，包括新应用的沉淀/行业输出管理等
• 基于容器化微服务/分布式/容器化等天然集成，标准的规范和可定制化
• 轻量级的中台化管理和最小资源配置，针对于中小团队的最快速中台化产品

数字中台的解决场景

• 消除基础平台中的不统一不规范，为业务中台数字化做基础
• 消除多团队多项目信息孤岛场景，解决数字化场景
• 兼容多云平台，PaaS+中台底座一体化集成，解决团队效能问题
• 消除中台化过程中的坑点，功能完善的微服务/容器化/业务集成化等可视化组件
• 快速解决团队中台化平台化的问题，快速统一标准

ACP中台能力

标准的数字中台产品基底，完善的中台管理体系

中台模型并不新，只是对中台的一个整体的模型更加明确的定义和思考，从另一个新的角度进行的思考整合，而不是以前的复用组件或是公共组件。中台架构是数字化行业的另一种体现，是一种新的标准，突破传统服务器的行业模式，在这个模式下，提升企业的发展战略，

这里中台的模型包括以下几点：

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

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

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

从整体上表述中台的模型，也是数字化社区的目标和愿景，整体已不仅仅是数字化，更多的是以数字化为基础，进行更好的发展方向，是企业能力输出的的最佳唤醒和集中力体现，通过中台模型体现和输出。

标准的中台产品体系，包括技术/框架/产品/团队/交付/输出等，完善的应用周期管理

中台产品体系，从技术/构架/产品/团队/交付/输出流程，形成标准化的中台流程，基于中台的管理，集成业务中台的应用周期管理和集成，多解决方案的整合。

开箱即用的研发中台体系，快速实现研发中台和业务集成，覆盖了项目应用管理、代码仓库管理、有效提高企业的管理、研发、过程自动化流水，研发中台和团队组快速结合：

主要包括以下模块：

• 基础技术框架
• 数字中台产品
• 微服务技术
• 容器化管理
• 面向接口和领域研发
• 团队成长输出
• 应用周期管理

适配多行业的业务中台建设，支撑行业软件快速中台化，数字化，迅速升级

数字中台提取出公共的业务服务，封闭统一的业务接口，为业务上层的集成，提供基础能力，让业务中台建设和业务组件集成，不需要再考虑底层的技术偏差问题，同时提供出源码型的交付，业务针对于自身的情况，提供出基础的中台服务。

研发中台产品架构图，结合团队/组织架构/数据/应用/运营整体体系的产品规划，整体产品架构图如下

主要包括以下模块：

技术中台

• 技术研发体系：中台底层服务，解决管理流程和PaaS平台，多云平台管理；
• 微服务研发引擎：中台底层服务，公共的核心包，规避技术难点，统一技术版本和规范；
• 代码生成器服务：中台底层服务，规避技术问题，统一技术的可视化管理工具

研发中台

• 权限资源引擎服务：基础中台服务，解决多应用，多部门权限资源管理问题；
• 云门户管理服务：中台管理服务，解决中台应用生命周期和管理；
• 通知管理服务：基础中台组件，处理多通知渠道服务，规避多通知平台；
• 分布式事务消息服务：基础中台服务，处理消息管理和分布式事务问题；
• 支付管理服务：基础中台服务，解决聚合支付问题，规避多支付平台；
• 存储管理服务：基础中台服务，解决分布式存储问题，规避多存储平台；
• 工作流管理服务：基础中台服务，解决工作流在线管理和流程配置；
• 网关管理服务：基础中台服务，解决在线网关配置和接口权限管理；
• 开放平台服务：中台输出服务，解决第三方，外包，中台能力输出出口；
• 单点登陆管理服务：中台基础服务，解决多应用整合和各个接口权限认证；

基础业务中台

• 内容管理服务：基础业务中台服务，处理多媒体和内容管理服务；
• 会员管理服务：基础业务中台服务，处理业务会员管理和会员相关服务（电商）；
• 电商基础服务：基础业务中台服务，处理电商平台的基础功能管理；

数据中台

• 数据中台管理体系：数据管理体系，解决数据中台输出能力的问题
• 数据上报服务：数据管理服务，解决数据集成和数据采集流程问题
• 主数据管理服务：数据管理服务，解决数据标准统一和业务元素管理
• 数据集成服务：数据管理服务，针对复杂场景下数据抽取问题

运维中台

• 自动化运维体系：中台管理服务，解决过程问题产生和运维体系架构
• 应用监控预警服务：中台管理服务，解决过程中问题发现和通知到人
• Ansible自动化操作服务：中台管理服务，自动化操作，解决运维解放人力
• 审计日志监控服务：中台管理服务，跟进日志追踪和异常问题发现

完善的SaaS应用周期管理，包括新应用的沉淀/行业输出管理等

统一的中台管理门户，集成中台解决方案管理，业务产品管理，通过单点登陆集成，集成统一的管理门户，便于多种业务的管理集成，提供内部研发人员成长的入口，形成团队统一的管理平台，同时提供门户管理平台，便于集成中台对外门户，建立团队自己的能力门面，业务产品门户等，整体架构如下：

通过统一集成管理界面，更好的进行平台化的配置管理和内部团队产品沉淀管理，同时形成统一的解决方案和业务能力输出，类似的产品形态如钉钉。

基于容器化微服务/分布式/容器化等天然集成，标准的规范和可定制化

完善的微服务体系，集成Dubbo和Cloud等多种微服务能力，结合K8S容器化管理，集成CICD平台，应用一键容器化管理，天然集成分布式管理能力。提供完善的微服务能力集成，包括nacos/zookeeper等，基于基础平台的管理和技术屏蔽，对于新来无感知，更好的切入到容器化中。

工程依赖于六边型思想，整合当前的项目工程结构特点，进行的规划和划分，以下为整体工程的规划架构：

提供基于DDD架构和领域模型编程，更好的统一规范，结合代码生成器，自动生成基于前后端的服务，自动结合gitlab/gitee/gitea等，合适中小团队的版本管理平台，一键集成。

团队基于 spring boot 孵化了一套 alinesno-init 脚手架，可以快速完成新服务代码框架的搭建。目的是让项目平台所有创建的服务都是基于同一套框架和代码结构，统一风格和技术路线，避免后期升级等困难，代码生成器提供如下能力：

• 通过 alinesno-init 脚手架生成的项目代码，能帮开发者准备好开发的前期工作；
• 让开发更加迅速，不用在前期配置上花费时间，降低框架学习成本；
• 默认生成的代码配置，在线代码生成管理，让开发者更加专注于业务逻辑开发；
• 通过集成基础平台组件以及数据支撑类组件，为应用的开发提供底座能力赋能；
• 低代码生成器通过使用自动化生成的平台，集成多种环境配置，简化研发过程；
• 构建针对于微服务平台框架，进行整体的说明，自动生成集成容器配置；
• 自动生成容器化配置，避免繁琐的容器配置，形成统一的规范；

标准的工程结构和代码生成结构，为后期升级管理提升更好的规范，提供无感知的技术服务管理，低成本的技术切换和跟进。

轻量级的中台化管理最小成本整合，针对于中小团队的最快速中台化产品

相对于大中台，大平台来说，ACP基于多组件化，统一门户管理的配置，按需配置中台，针对于较小的团队来说，并不需要一上来就一整套服务化，一整套的配置，而是按需求获取，整体不同的能力，根据不同的团队配置，搭配不同的业务场景，甚至包括1个人项目的场景，整体输出能力如下：

整体架构设计说明：

• 针对于不同的场景，按需求配置不同的服务；
• 通过可配置的网关和开放平台，对业务提供公共的API接口，体现中台的能力之一；
• 结合新旧系统的优势，最小的调整的集成旧业务能力进行平台，形成统一业务中台；
• 在线多团队，SaaS化的管理，为多团队管理形成服务，形成团队统一的规范；

解决能力

消除基础平台中的不统一不规范，为业务中台数字化做基础

技术不统一，不规范，接口各异等问题，为中小团队长久形成无底洞的弊端，系统维护成本增加，基础技术建设意义难合，内部沟通困难，无法形成统一意见，难以开展各个组之间的工作，面临的问题冲突：

• 新老项目的升级问题，业务线技术规范不统一，系统维护成本和人员维护成本高；
• 基础技术建设无法整合开展，业务和技术组件无法复用，一个技术方案多版本实现；
• 团队管理难，各自为政，新人切入和培训成本高，团队学习成本大；
• 业务培训和切入业务难度大，团队效率在无形中内耗，研发难以抽出上层安排困难；

ACP中台解决技术架构如下：

ACP中台是从大的方向上进行了统一，但是在细的技术把控上，会给团队及项目组一定的空间，避免架构过度封装的问题。

解决过程中技术不统一的问题，统一规范和统一团队，统一技术选型，降低学习成本和完善内部技术生态，达到技术方案和组件的复用，专注于业务本身需求，提升业务团队的效率。

消除多团队多项目信息孤岛场景，解决数字化场景

传统的研发平台基于一套代码一个平台，形成多套系统多套基础平台，形成各自孤立的数据孤岛，针对不同的业务，单独维护一套，浪费开发资源而且维护困难，不利于数据的收集与分析，信息孤岛很明显，各个数据难对接抽取，无法或者较难抽取元数据。

针对于上，形成各个部门或者应用形成孤立的一面，更加上外包团队的加入，更加难以统一管理。ACP数字中台，天生的中台架构能力，提取出基础的组件元数据和数据元数据，抽取成中台服务，为业务提供标准的数据接口能力。

整体架构图说明：

• 传统的开发框架体系不管是技术沉淀和管理模式上，无法避免信息各异的产生。
• ACP数据中台的研发模式基于沉淀的方式，形成信息和数据职责分层 ；
• 中台本身架构，抽取出元数据和主数据元素，沉淀到中台服务，形成数据层；

不管是在物理上，还有逻辑上进行数据拆分 ，统一部门和团队的数据规范和方法，对不同的数据整合，形成统一的规范，利用中台架构，从根本上解决系统建设和业务建设上数据孤岛的问题。

兼容多云平台，PaaS+中台底座一体化集成，解决团队效能问题

对于不同的PaaS平台，多云平台，提供兼容性，包括阿里云、华为云、腾讯云等，提供私有部署的兼容方案，解决云平台配置的问题，基于K8S服务的配置，搭建属于团队自己的容器云管理平台。针对于以上，技术研发体系，针对于中小团队，低成本，快速的整合PaaS平台，如下图：

在统一的流程上，结合中台一体化，形成团队特色的中台服务，解决技术统一问题的同时，更加解决团队效能问题，管理发布升级等问题，多环境（开发/测试/生产/客户）的整合问题，让团队更专注于业务需求的建设，规避技术的坑点。

消除中台化过程中的坑点，功能完善的微服务/容器化/业务集成化等可视化组件

自从微服务和中台化的落地以来，基本上都是基于培训和各个初级的入门培训，由于技术框架的快速迭代，市场教育和培养的周期较难沉淀一套完整的解决方案，形成的是零散的场景解决方案，但是真正在落地中，遇到的问题远不止看到，这里列出部分最常见的：

• 微服务框架的整合是否必须是一整套（是否一定要上微服务）；
• 服务之间怎么划分，划分的颗粒度怎么确定，是否有一定的标准；
• 事务消息中，消息的丢失还有消息的管理怎么整合，业务场景怎么消费；
• 多系统接入过程中，是否一定需要配置中心（难道一定需要的么？）
• 多城市场景下，不能满足怎么改造，架构的限制在哪里；
• …..

基于以下种种场景下，ACP数字中台整合建设过程中的问题点，规避过程的复杂性，经历从0到1，大中小项目的整合，多城市多团队，跨部门等经验结合，为团队提供相对的技术方案

通过容器化，可视化的组件管理配置，屏蔽中台建设落地的复杂性和产品化，在开发、服务、数据、运行、运维等多个层面进行了能力聚合，真正让分布式应用的开发做到架构分布、体验聚合。

快速解决团队中台化平台化的问题，低成本快速统一团队标准落地

团队中台化建设和平台化建设，需要投入成本巨大，消耗周期长，团队切入成本高，在这样的高投入情况下，甚至还有可能会失败，形成不了了之的收尾场景，常见的建设面临的困难点：

• 人才招聘难，需要有一定经验的架构师和强有力的落地执行能力；
• 需要解决团队人心的问题，在没有见到结果的情况下，信心很难建立；
• 建设周期长，不同的团队或者大一点的团队，需要解决团队人员培养的问题；
• 不同的地区，不同的背景，在培养完成周期之后，同步要考虑人才流失的问题；
• 在完成一版本之后，问题多无法在团队内部真正用起来，最后形成鸡肋；
• 在没有充分的场景验证下，开发、商务信心和公司信心，各自担忧的问题；

针对于以上种种，ACP平台建设在架构初期，针对于不同的团队，场景进行梳理，形成统一的中台底座，让团队专注于本身的业务需求场景规划和建设上，更专业于本身团队的发展：

形成丰富的文档和开发示例，输出新人入门文档，解决团队人员成长和切入的过程，梳理出团队成长的体系做为参考，为团队的培养做基础。可以在现有团队的情况下，针对高工（非一定架构师）进行业务二次的调整改造指导和承接，提供专业的技术专家进行过程指导，提供建设咨询和经验分享，解决落地的问题；

中台产品

我们针对的是中小型团队，快速实现中台化和平台化场景，达到团队可控，可管理，为后期业务的沉淀 形成基础，更好的沉淀团队资产，形成团队行业的业务标准和一套解决方案，形成自己的核心竞争力

ACP数字化中台官网：http://alinesno-platform.linesno.com

其它

• 无