中小团队数字中台,基于ACP的轻量级数据中台解决方案

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

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

中台产品概述

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

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

数据中台能力

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

解决团队数据场景

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

ACP数据中台能力

数据抽取和采集

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

架构描述:

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

数据治理过滤

主数据标准定义

数据离线和实时计算

数据服务提供能力

解决团队数据场景

数据中台基础架构

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

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

数据的管控和采集

业务和数据运营管理

总结

其它

企业级ACP数字中台,新一代标准中台产品基座

此为产品输出章节,中台是数字化的最佳实践,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

其它

基于新中台模型设计的数字中台产品架构

快速低成本的切入和落地中小企业数字中台化

概述

企业级研发中台服务 ACP , 研发中台产品体系架构规划和设计,为完成整体的中台产品进行的架构和产品的整体规划。

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

可以帮助我做什么

  • 开箱即用的技术中台体系
  • 快速实现研发中台和业务集成
  • 研发中台和团队组快速结合

产品主要功能

  • 一套技术 DevOps 研发体系,持续集成平台
  • 技术、研发中台和数据中台底座,快速集成业务中台
  • 统一的前端框架和微服务研发引擎,k8S 容器化支持
  • 集成权限/用户/认证/授权/支付/通知/内容管理等基础组件
  • 成熟的研发组件,多团队多部门开发

产品列表

这里列出原规划的版本,实际以演示版本为主

数字中台产品构架图

中台新中台模型的建设规划,研发中台产品架构图,结合团队/组织架构/数据/应用/运营整体体系的产品规划,整体产品架构图如下:

注:这里一定要注意,上面是针对中小团队可支撑范围,大型数字中台需要一定量的人员支撑,人员投入方向是支撑的业务线多

产品架构图片说明:

  • 虚线部分为业务线的建设,非虚线部分为数字中台产品边界和范围
  • 针对于不同的数据的适配,不同的团队组织线建设有不同的业务建设方式
  • 多团队共用新中台架构,包括组织架构、运营、技术方案等,形成统一的中台体系(可兼容不同技术)
  • 研发中台和基础业务中台,提取出公共的元数据和主数据能力,从根本建设上解决应用数据孤岛的问题
  • 结合数据整合模块,进行数据元数据和主数据的抽取上报,集中到数据仓库和数据湖,形成数据资产能力
  • 中台能力和业务架构的体现从开放平台和新中台对外门户,形成行业业务沉淀,形成核心业务能力资产

相应的市面上产品示例门户体现示例:

产品工程规划列表

最终效果以中台演示为主,针对于中小团队有限的能力进行的建设,架构规划上需要进行一定的边界和制约。

序号业务线产品状态地址备注
1技术中台技术研发体系文档
2微服务研发引擎alinesno-cloud-core
1运维中台自动化运维体系文档
2应用监控预警服务
3审计日志监控服务alinesno-cloud-logger
4Ansible 自动化操作服务alinesno-cloud-operation
1研发中台基础权限管理服务alinesno-cloud-authority
2云门户管理服务alinesno-cloud-platform
2会员管理服务alinesno-cloud-member
3通知管理服务alinesno-cloud-base-notice
4支付管理服务alinesno-cloud-base-pay
5文档打印管理服务alinesno-cloud-base-print
6存储管理服务alinesno-cloud-base-storage
7工作流管理服务alinesno-cloud-base-workflow
8网关管理服务alinesno-cloud-gateway
8中台连接器服务alinesno-cloud-open
8分布式定时任务服务alinesno-cloud-scheduler
11单点登陆管理服务alinesno-cloud-platform-cas
13CMS 内容管理服务alinesno-cloud-cms
1数据中台数据仓库体系文档
2元数据管理服务alinesno-cloud-data-metadata
2主数据管理服务alinesno-cloud-data-master
2数据集成服务alinesno-cloud-data-etl
2数据开放服务alinesno-cloud-data-open
2数据开发服务alinesno-cloud-data-develop
3数据分析展示服务alinesno-cloud-data-display
1物联网中台网关服务服务
2物联网后台服务
7
8业务服务低代码快速开发服务alinesno-cloud-lowcode
9代码生成器服务alinesno-cloud-initializr-admin
10

我把开源项目alinesno-cloud-service关闭了

项目开始大概是18年初自己便于学习立项的,原为了便于学习而做的技术分享,这里只是阐述自己团队整合过程的总结参考。

概述

经过这几年的实践和项目迭代,经验总结,还有过程中的各种坑点总结,包括企业走向,团队整合等,发现基线存在大量的设计问题(这里指的问题并不是技术,而是设计)。

后期团队的不断丰富完善,形成了一大型项目仓库,整个仓库已经变得非常的庞大,同时子目录下面集成多个工程和组件,近乎上百个maven工程,如图:

关闭原因

容易让企业和团队走极端路线,而产生大量的内耗,而产生这一过程的问题,要回头,少则2年,多则需要3-5年的时间。

当然,另一种办法是过程中架构师的不断重构,这是可行的,但是针对于中小团队来说,重构和架构师的成本,还有周期成本都非常大,特别是切换架构师或者核心人员的情况,除非能完全掌握整个设计思想。

但即使是这样,新旧项目的迭代,还有维护,也会消耗至少超过半年以上的内部资源,新旧项目迁移,特别是上生产的项目。

针对于企业和团队来说,1-3年是发展的周期,产生的内耗,这里的内耗不仅仅是项目的内耗,还有团队,方向,公司,战略等,后期进一步发展容易掉队,特别是在当前数字化快速的情况下。

保留原因

为了更方向的学习和参考,因为原设计文档还存在,相对于文档和代码的对照来说,可以进一步的学习,对新人是有一定的帮助,但是切入实际的项目并不太建议。

同时也考虑通过设计文档和相关的资料,可以在后期自己方便的时候,直接搜索获取,同时在过程中有一个历史记录的意义存在。同时是gitee的GVP项目,原来并不了解开源项目的运营规则,关闭过一段时间,对相关关注的用户和学习中的用户,还有gitee平台的影响未深入考虑。

其它

针对于中台库的不断变大,同时也体现出中台库的历史包袱也变得沉重,于21年的时候,为了更好的切入数字化建设和跟进行业的发展,进行的中台拆分,由原来的大中台,小前台,变成了轻中台,小前台,大平台的架构思想调整。

待梳理文档:我把整个研发中台拆分过程的一些心得总结

原项目地址(建议学习使用) :https://gitee.com/landonniao/linesno-cloud-service

一些企业变革总结

在总结博客 一直以来做的都是企业变革 :-)
16年两广国企平台化改造负责
19年互联网协助企业数字化改造
20年国企平台化改造负责
21年团队中台产品化打造负责
22年国企事业部业务中台改造架构负责