在从事IT行业以来，在业务建设过程中，一直无法规避的问题，就是基础层建设，建设消耗的人力物力极大，在做架构带团队的时候，这个更加体现。

此文档为ACP能力输出方向和解决方案之一。

概述

国产化的趋势是方向，更多的业务建设还有数字化整合国产化，安全化的要求，比如国密要求，数据上链（区块链）等，同时也产生出新的行业问题体现。ACP中台的解决和规避数字化建设的相关问题，这些由中台层进行完善和考虑，整体架构如下：

方案描述：

• 利用中台的优势，进行多方和各种基础层的规避，做好角色责任划分；
• 利用中台的优势解决国产化、数字化、安全化的问题；
• 让数字业务建设过程中，对相应的基础层建设透明化。

常见基础层问题

当前行业发展和国家的战略要求，在数字经验上，提到自主可控，国产化等要求，这几块上，国产化的建设当前涌出很多，特别明显的芯片、数据库、操作系统等，这几块对数字经验，数字业务上提了进一步的要求点，列了以下几点：

• 网络安全和各种加密的问题
• 云平台兼容适配的问题
• 多国产化数据库的兼容
• 国产品系统和前端兼容的问题
• 数字建设第三方问题
• 新技术框架的整合和融入
• 新旧技术衔接问题
• 数据采集成本的问题
• 数据抽取存储，治理运营的问题
• 自动化运维监控的问题
• 自动化版本管理业务集成的问题

问题描述：

• 网络安全和各种加密的问题，包括Xss、国密、SQL注入等问题，国家安全数据规范的问题，第三方接口数据安全的问题
• 数字建设第三方问题，包括常见的安全问题，比如信息泄漏、SQL注入、数据加密、逻辑漏洞、各个框架安全问题（比如log4j）、数据安全、文件上传等
• 新技术框架的整合和融入，新技术的升级问题，兼容问题，新旧升级过渡问题，升级成本的问题考虑等
• 云平台兼容适配的问题，包括国产操作系统、第三方云平台、私有云、IDC问题，CPU问题等
• 前端兼容的问题，包括新前端兼容，浏览器兼容，移动端的兼容，接口的兼容问题，接口规范定义的问题
• 数据库的兼容，包括国产数据库不同版本，数据库迁移的问题，第三方数据库，缓存的兼容问题，后期数据标准的问题
• 新旧技术衔接问题，包括人员学习成本，学习案例成本，文档梳理成本，业务升级投入成本的问题
• 数据采集成本的问题，包括业务数据来源的问题，数据规范不统一的问题，数据质量的问题，数据源不一致的问题，数据沉淀的问题
• 数据与业务打通的问题，包括数据整合梳理提交流程，数据上传流程，业务数据共享的问题
• 数据运营的问题，数据与业务整合计算的问题，数据反馈协助业务运营的问题，数据标准和资产管理问题
• 运维监控的问题，这部分主要包括传统手工化运维、日志监控采集、，日志数据安全保留周期、异常信息预警、运行监控等；
• 自动化版本管理业务集成的问题，这部分主要包括数据安全的处理、备份、定时巡检的处理、结果预警、自动扫描、安全巡检等。
• …..

使用中台解决方案

这里主要考虑的是几部分，从封装，规避，服务几个角度进行阐述，大的指导方向是中台层建设封装，业务技术的卡点规避，中台层提供的服务，从职责上进去划分，主要包括如下：

中台层的封装

中台层的封装主要是规避底层的技术能力和内部的衔接，这里包括多个层面的基础层建设，这里使用了中台层的技术架构工具实现，输出成为基础的公用业务建设平台层能力，通用型的业务建设能力，规避和上一层能力的重复性。

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

研发中台产品架构图，结合团队/组织架构/数据/应用/运营整体体系的产品规划，整体产品架构图，这里主要输出的能力方向如下：

业务建设卡点的规避

中台层服务能力

这里服务能力包括几个方面，这里常见的列了几个常见的点，主要几个点：

• 团队组织的服务能力，过程的建设指导能力
• 过程中台能力的支撑解决服务能力
• 技术架构的设计和业务整合的服务能力
• 业务建设过程的文档输出和示例输出的服务能力

上面基本上是基础的团队型服务能力，这些基础的能力，解决了支撑体系的问题，但是在基础层输出另一层，即是实际的输出表现，这里主要体现的是产品能力：

• 研发文档型的输出，这个是最直观性的
• 接口和数据共享型的的输出，这个是直接的基础中台层能力
• 工具型的可视化输出，这个是基础中台层的过程能力

在服务体系和直接产品型为基础提供了落地的保障，使更加站在业务型建设上进行的规划和思。基于以上的服务，进一步的推动业务建设，主要体现几个点：

• 让业务建设专家专注于业务架构的输出
• 业务团队专注于业务的建设和思考，更多的时间周期在业务的问题上
• 提高业务创新水平和服务水平，提供业务质量水平
• 更多的加强在客户关系维护和需求分析和落实上，提供更优质的客户服务
• 更好的业务产品体验，在商务和市场上更高的抽取出来
• 高层级的人员和管理者可以抽取，进行更多战略型的思考和发展

其它

• 暂无

此文章为技术输出章节，为中台技术支持体系的基础支撑架构方案和思路，主要面向中小型团队的支撑架构，大型或者超大型团队建议自建

概述

近几年常见的主流技术名词很多，主流新的方向也很多，比如DataOps、GitOps，DevOps、Scrum（敏捷）、ChatOps、PaaS、CloudNative（云原生）等多个主流的名词，当然还有其它领域的，比如GIS、SmaryCity（智慧城市）、元宇宙、数据中台等，这些主要听起来很高大上，确实很高大上，但是回到实际团队，这些又解决了我们什么痛点，价值性对自己有何作用点，体现在哪儿。

接触过一些团队，都有这些规划，也有这些实施的方向，走向也很明确，但是操作起来可能是另一回事。

基础能力

建设过程

后期扩展

其它

此为升级经验输出，主要针对于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版本

其它

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