软件工程师罗小东，多年平台架构和落地经验，在与社区团队研究超自动化方面的设计和产品方向。

背景

以下是针对超化管理超化的设计，因此会偏向技术方向的阐述。

目前对于超化的关注点似乎更多集中在方法论方面，而较少关注具体实现，目前仍处于探索阶段。我们的编码工作目前在 Github 上进行，以便与对这个领域感兴趣的同学进行更好的交流。

在进行超自动化研究的过程中，我们遇到了数据采集的问题。在上层自动化过程中，需要大量的数据支持，因此需要采集大量内容。由于缺乏业务场景，我们在这方面的研究考虑是先使用超自动化来管理超自动化（即自己管理自己）。这里主要针对日志采集设计。

概述

我们原来的整体设计方向是朝着数据支持方面发展的。根据一定的规则和判断条件，结合 AGI（人工通用智能）的推理判断，形成智能化的操作。在日志的采集和管理方面，我们需要采集完整的数据链，进行判断、管理和预测。在确定采集哪些数据时，我们参考了许多开源项目，但也发现了一些问题。各个开源项目过于分散，无法形成组合，数据分离也比较麻烦。另外，技术迭代速度较快，有些项目没有很好地跟进。综合考虑后，我们需要进行部分重写和整合。这里主要采集的内容包括：

• 前端日志：包括 UI 事件、访问日志、操作日志、热点日志和 IO 日志等。
• 自动化日志：镜像日志、构建日志、过程日志和操作日志。
• 安全日志：代码、质量、版本、漏洞安全、容器漏洞、密钥日志和 Git 提交日志等。
• 应用日志：运行日志、运行状态、请求日志、运行情况和链路情况等。
• 系统日志：操作日志、历史日志、IO 日志、网络日志、请求情况和运行情况等。
• 操作日志：操作记录、SQL 操作和审计操作等。
• 登录日志：登录的所有信息和请求，例如 IP、地点、位置和账号等。
• 项目日志：任务操作日志、变更日志、审计日志、人员变动和状态变更等。
• 链路追踪：请求链路、操作链路、日志链路、SQL 链路和阶段链路等。
• …

这只是初步设计，后期还会继续添加。目前按照上述设计进行集成，采集回来的数据使用流水线方式进行判断和处理。在这个过程中，我们主要使用了 GPT 的推理结果作为推理能力的基础。当前的原则是尽量使用流水线和自动化，在特定阶段使用 GPT 的能力作为辅助，以提高过程的稳定性。实现的超化能力演化效果类似于以下示例：

• 在云服务器准备到期时，自动采购或续费。
• 当功能准备延期时，自动通知并向指定人员提供合理建议的方案。
• 每月或每周自动生成报告结果，并给出合理的建议。
• 自动检测和构建验证过程中的漏洞，并生成分支。
• …

在这些过程中，我们使用规则和推理能力进行简单的判断，协调这些自动化流水线，类似于自动驾驶，但也有辅助驾驶，推理能力就是这个协调的大脑。为了实现更便捷的操作，我们还添加了语音交互，以便更好地进行操作，并将结果通过 SSE 推送到系统界面或进行语音播报。

下面是当前设计的整合思路，这仅涉及日志采集方面的设计，其他自动化内容不包含在其中，我有自己的思路。

过程设计

相对而言，采集的设计是相对简单的。目前有许多开源工具可用，但搭建起来可能需要较长时间。然而，由于 AIGC（人工智能生成代码）的能力，我们可以使用生成式代码和单元测试，效果还是不错的。

采集工具

我们的采集工具主要使用了一些开源工具，并结合了 Maven、Shell 和自研的流水线进行改进。在选择工具时，我们考虑了定制化的需求，并综合考虑后决定自行开发。下面是我们主要使用的采集技术：

• 前端采集：log.js、filebeat 和 nginx。
• 自动化采集：Python + shell，并将数据发送到 Webhook。
• 安全日志采集：Trivy、Checkstyle、Murphysec、SpotBugs、Gitleaks 等工具。
• 应用日志采集：自定义的 logback、OpenTelemetry、AOP、Nginx 等。
• 系统日志采集：Ansible、Shell、Python，定时采集结果并结合 node-exporter 返回。
• 操作日志采集：AOP 和自定义的 logback，自定义的 MDC 参数。
• 登录日志采集：Nginx、AOP 等。
• 项目日志采集：通过调用 API 进行定时采集，并有一些会接收推送结果（例如禅道）。
• 链路追踪采集：OpenTelemetry 和 agent 的方式。

对于数据量较大的情况，我们使用 Kafka 作为数据缓冲。为了方便交互和安全性，我们在 Kafka 前面加了一层控制器层，提供了 HTTP 接口，并使用自定义的令牌进行拦截。目前还在研究过程中，尚未添加 HTTPS。

有些 Webhook 提供的是一个前端系统，例如 Spring Boot 应用或 gRPC 应用，它们接收数据后将其输入到数据仓库中。我们使用 ClickHouse 作为数据仓库，因为它能够保存多种数据结构。一些日志会在实时计算后保存到数据仓库中，另一部分会使用数据进行离线计算。我们对 ds 的 2.0 版本进行了二次开发，以适应当前的工程结构并更好地维护。

维护平台

采集之后，并不仅仅是结束了。我们还设计了几个平台来管理数据，以应对不同的应用场景。这些平台类似于数据的前端和展示，便于管理过程流程跟进，并提供更好的可视化。我们基于 Ruoyi-Plus 进行了改造，主要产出了以下平台，便于维护管理，比如自动操作服务、安全感知服务、持续集成服务、日志审计服务、容器管理服务、监控预警服务、链路追踪服务等。

这些服务功能主要是在数据上展示和管理，便于超自动化的管理。一些数据来源于 ODS 层和 ADS 层，目前的流水线集成还在 GitHub Actions 上，但数据应该已经采集到了。后续需要进行验证，并进行多个自动化流水线的验证处理。这个过程可能需要进行调试，当前的功能点已经规划和编码产出。

总结

以上是我们在研究超自动化过程中关于日志处理的思路和结构。目前还在进行调试和验证。除了日志的自动化处理，还有其他方面需要结合超自动化，例如项目管理、产品市场营销、流水线自动生成等。希望对从事这方面的同学提供一些经验参考。

鸣谢

在处理日志的过程中，我们参考了一些产品，主要包括以下内容：

• GitHub Security 服务
• 阿里云分布式链路
• AnsibleTower 自动化操作
• ELK 套件
• PlumeLog 开源日志工具

软件工程师罗小东，多年平台架构和落地经验，大模型的出现让通用型AI成为一种可能，针对数字化和平台化的结合一直在考虑整合点，让超级自动化方面落地更成为可能。

注意这里假设部分材料可以公开，数据隐私性不强的情况下的设计运用，比如规范

概念

相关数字中台概念，可以参考我为什么觉得数字中台是团队的新型基础设施，这里不做过多阐述。

背景

整个研究的目标点是为了针对于数字中台层级的超级自动化，这个是在继Ops架构体系之后的一个突破点，前两年在Ops架构突发和成熟，比如DevOps/GitOps/DataOps/AIOps等体系（这里不涉及AIOps架构)，在某个方面已经具备一定的自动能力，进而发展出数字中台的基础设施能力。

研究超级自动化的时间应该是在20年左右，前期在Ops上已经实践多年，一直想找更优的突破点，而且Ops模型体系也已经有了标准和完善，不管在微服务、中台技术、运维、数据治理上，这些都已经集成了自动化和流水线的能力，开源的产品也比较多，但是在超级自动化和数字中台整合方面上，目前市场和概念的意识还不够成熟。前期也研究过一段时间AI能力融入，但是多方面的限制，始终无法得到比较好的效果，而大模型(GPT)的出现，貌似把这超级自动化都变成了可能。

这里主要以落地结合实际为参考，基于数字中台基础设施上的进一步架构设计，从能力提升过程为维度进行阐述：

• 微服务和DevOps架构能力提升
• 数据治理能力的能力提升
• 服务治理和运维架构能力的提升

结合起来的建设的思路依然是大平台、轻中台、小前台，整合思路设计思路如下:

• 建立完整的规范文档，自定义大量的prompt前置库
• PromptOps(参考Ops)流水线体系的建设
• 结合数字中台多产品线的融入和落地

这里的大平台进一步的下沉和强化新型基础设施的概念和能力，更为突出层级的划分和固化，这个是以GPT模型为能力设计，整体设计是基于有完善的数字中台基础设施的能力上进行，这里主要给出参考，这里只是针对问题和解决问题思路来进行说明，也是后期落地和建设的方面，经验不一，我有我思。

过程问题

这也是结合使用过程发现的一个特别大的问题点，规范化和完善基础设施是条件之一，而利用GPT的结合推荐，Prompt生成的整合，也是基于这个规范和基础设计为主，而更好的结合实际，而不是仅仅参考，更多的是运用，这个主要会更利于人员的成长和往更高一层的思考，将人的精力和学习能力更加的提升，这对于很多中小团队来说是致命的成本硬伤，以下是AIGC和数字中台结合的整体架构：

目前主要设计到的超级自动化上构建专家体系、自动化体系等。

微服务和DevOps架构能力提升

有工具和会用是另一回事，在成熟的前提上更进一步提升

这个可能是一个老生的话题，在过去的实践中还有目前行业的发展中，这个是工程结构的基础，也是面对于解决系统和架构问题的进一步架构提升，在业务和各个组件能力上，规范上，还有基础技术上的统一化和规范化等。解决这部分的能力，主要是在于后期服务治理能力、业务工程结构能力、还有自定义业务创新（或者说自研）业务上提供一定的保障。

前期在这块上体现可提升或者进一步需要优化的部分，过程遇到的体现在几个方面：

• 工程结构的规范、编码能力、基础编码优化等，比如针对于几百个规范和文档编写；
• 技术债成本高，涉及过多的概述和技术，比如往往需要多方面人才的指导才可以完整走下；
• 多组件沟通困难，针对于大量的组件和技术整合架构不够明确，比如场景无法更好的结合组件做架构
• 结合解决方案困难，无法针对现有的能力，更好的组合出更好的解决方案，比如往往会出现很多轮子
• 技术问题解决思路，这个成本较高，比如一般初中级工程师无法提出针对性的技术思路
• 产品和市场信息产生偏差，无法形成合力，比如你做你的方案，我找我找方案
• ……

针对于以上种种，可能临时可以解决或者”总会找到人”，但是这个如果项目PM在工时和项目经验上，做过精打细算经验的会发现，会有一种温水煮青蛙的感觉，无形中流失很多时间和问题在非业务功能需求上，虽然说在前期的基础架构上这些问题好像已经有规划和处理，但是在很多时候，自己一直得不到满意的效果（即使管理流程和组织架构上做优化），还是感觉这一步是可以进一步优化。

主要是构建专家体系、文档体系、规范体系、学习体系，而原来的组织结构会进一步调整和优化，从而更专注于业务场景需求和创新方面，培养业务专家体系(当然业务专家也可以结合，这里不做阐述)，集中精力在更具备价值的地方，在多个方面更好的实现业务能力和创新。

数据治理能力的能力提升

数据分析和挖掘会更一步精简化，更专注于数据运营效果

在应用采集的数据挖掘能力上，GPT基本上比较容易整合，对于数据多层级的划分，如ODS/DWD/APS等这些在前期使用过程中，基本上针对于系统会针对性的出一版本，这部分的处理一些方案和方向上已经达到，这里不做过多的阐述，得益于SQL规范上，指定一定的指标分析过程，只需要更好的结构好模型，做出模型投喂等，出来的指标一般来极具参数性的，这类型的可以参考Chat2DB，PhotoShop等，这部分的数据分析可能正向推、或者反向推都可以。

前期在这块上体现的一些问题点：

• 数据维度分析、指标分析，这块上需要较长的周期，无法快速给出参考，需要投入特定人员，比如一些初级的分析
• 数据计算上SQL编写，无法和现有模型较好的整合，有一定的技术复杂度，比如kafka/flink/hive/clickhouse等
• 人员培训成本上，技术和数据概述有差异，过程需要特定的数据人员指导全程指导
• 技术债成本高，涉及过多的概述和技术，业务、技术和数据的结合沟通成本上较高，比如数据总线概念和消息概念不一样，但是技术操作上可能是一样；
• ……

另一个是在数据生成API上，也一样针对于第一章节提到的规范可以进一步推出。比如一个简单的实时例子，在维度分析和指标分析上，会结合模型自动生成，同时另一个是也会输出FlinkSQL，这个往数据开发工具上复制和调试即可（目前是这么处理）。

主要是构建专家体系、文档体系、规范体系、学习体系，从而更专注于数据挖掘场景需求和创新方面，在多个方面更好的实现业务能力和创新。

另一个是数据分级、元数据、主数据的分析的抽取上，数据清洗、元数据管理、数据模型管理等流程化的工作，这些都有比较好的能力整合，结合模型训练基本上会更合适（如基础的数据模型算法）。

注意数据涉密的问题，这里只做模型提交处理，而且需要客户沟通

新一代的AI技术，让此类工作门槛大幅降低，数据分析不再成为一个难点，针对一般型的项目基本上是可以直接套过来，通过自然语言快速建表，包括自动生成维度表、建立范式模型和星型模型、自动分析表之间的逻辑关系、甚至提供建模建议，生成一定的SQL和脚本，更快的进行数据采集分析。

服务治理和运维架构能力的提升

自动运维能力的提升，更快速提供服务运维质量和范围

这里的运维包括监控、管理、安全、自动化等，自己一直在研究和运用的更多的是ChatOPS，以钉钉一类为代表的工具，一个是信息的交互，另一个是主动推送信息，这部分在某种模型上，会比较成熟，不过在运用上还是比较不得意，大部分是集成中通知和互相上，集成起来的能力点是极度有限的，是在现有的工具模型上做的API，然后结合各个服务能力进行一个窗口型的交互。

出于几方面的处理，很多方面是webhook/定时/api几个方面的能力结合，而这些操作过于通用而带来一定的限制，主要在几个方面：

• webhook能力有限，需要定制很多api来结合，机器人的结合，缺少推理的能力，在这块上学习成本和场景上依然会有很大的限制
• 技术债成本高，涉及过多的概述和技术，业务、技术和数据的结合沟通成本上较高，学习成本很高；
• 技术问题解决思路，这个成本较高，比如一般初中级工程师有些可能根本无法接过自动化运维这个内容
• 运维和数据挖掘的结合目前缺少一定的方案，技术方案突破存在一定的瓶颈，需要研究的成本很大
• 问题解决过程需要关联大量的基础设施信息，这个结合的成本需要特别熟悉的工程师才可以处理
• 问题分析模型创建困难，在海量的运维数据中，需要高级算法工程师和计算人员才可以，中小团队招人成本极高
• 运维/技术/数据整合起来困难，无法形成一体化的结合的能力，形成运维/技术/数据各个层级孤岛
• 相关过程问题沉淀效果不理想，重复问题参考效果未必能达到预期
• ……

前期一直有计划结合AI能力来处理这个，需要突破很多限制和成本，这对于中小团队来说，不管是精力还是人才，基本上会有很难的实现，特别是需要特别资深的工程师，而且甚至有可能做到半效果不理解，然后走到黑或者走到放弃的层面。

同样是构建专家体系、文档体系、规范体系、客服体系，在处理上更专注于稳定性和健壮性，提升问题预知和安全感知能力，促进业务的稳定性。确保系统、设备、应用程序等IT资源运转正常，并维护它们的高可用性和可靠性。运维人员通过对软件、硬件、网络等的监控、维护、检修、升级等工作来保证系统的稳定性和完整性。

整合思路

这里能这么做的主要利益于数字中台的规范性和完整的基础设施能力提供，稳定和成熟的中台体系。这个是针对原有的平台化的升级优化，而不是重构或者重建之类的，这个过程是没有必要的，应该来说以适当当前的任务平台或者业务系统。

建立完整的规范文档，自定义大量的prompt前置库

建立专属的Prompt库，指令会有一定的字符限制

根据自己在接触的平台的这几年，有一些经验和材料的沉淀，不管是文档和脚本库等，都有上千份，进行进一步的梳理和建立更好的资料库，服务系统之前标准API的提取和标准的定义，更加明确多个节点的标准规范，比如接口规范、日志规范、数据规范等，形成大量的知识库，而这些标准知识库，形成Prompt的前置库，为了形成更好的指令传递给GPT模型。从而结合实际的微服务技术、中台技术等。

• 增加了模型能力的引入和团队能力提升的章节(可以理解成高级助手)
• 通过多个资料和材料的整合，形成多个专家体系，比如Java技术专家，数据分析专家，运维专家，数据库专家，产品专家等；
• 通过资料和规范，结合AI的推理能力，会更加结合形成结果，形成客服体系，进而形成人员成长体系，解决人员的问题；
• 通过专家体系的融合，形成方案解决方案设计能力，针对场景和项目的不同，结合和搭配出不同的场景技术方案，提供更好的参考。

而整个过程需要达到的目标依然是大平台，沉淀形成新型基础设施，将人力和精力更加的集成在更有价值的地方。这个阶段的整合，更多是针对于文档规范和调整，会有一定的调整，同时为了更好的区分和不影响当前业务，分离出GPT版本，进行小规模的试行和验证，推进。

PromptOps(参考Ops)流水线体系的建设

建立更新机制和流程

这个主要得益于在DevOps/GitOps上的成熟和规范，效果等，在以前的经验中，这两块基本上达到了较高的自动化能力。

为了平台化更好的优化和更新，需要不断的吸取新的知识和参考，同时获取到更好的项目参考，比如包括同类竞品项目，开源项目等，这个是一部分的集成能力，另一部分是本身Prompt库的升级，更新等，这里主要是参考DevOps的思路，形成流水线和自动化的能力，建立多个输入端，形成类似于人工智能标注一样的处理流程。

• 在原来的沉淀结构上提一步的提升和规范，提升了每个章节内容的建设范围和边界。
• 根据层级数据安全，做好一定的敏感词定义和过滤，形成Prompt安全规范，避免敏感信息和层级数据外漏
• 根据结果和返回数据进一步沉淀到数据平台，过程进一步的进行优化和维护

这个过程的主要目标是形成流水线，减少在Prompt上的投入的运维管理。

结合数字中台多产品线的融入和落地

这是一个落地的问题

这里主要利益于产品的自研能力，为什么一直坚持自研也是这个考虑，这样更好的创新和能力的整合。

在这里同样的思路，如果一个事情过于复杂，需要想办法让它变得更简单。在这块上搜索和输入的Prompt内容，结合上面的专家体系和规范体系，结合产品工程中的特定卡点进行嵌入，最终直接输出结果。这个方式类似于Prometheus/ELK等，直接嵌入到每个工程运行的卡点里面，直接点击即可查看结果，或者输入少量的提示词即可直观的看到。

• 通过找到每个产品服务的卡点，进行GPT产品线的埋点，进行产品整合，以获取得到更好的反馈结果，这里主要以sdk埋点的形式
• 在工程师层面淡化AI的各种概念，形成无感切入，在后期中不断的沉淀和优化，以达到更好的效果，比如缺少某个关键词，通过上面的流水线进一步优化

这个过程主要的目标是落地运用，达到原目标的结果，这个在数据设计和规范编码上已经有一定的运用，效果还是不错的。

总结

对于数字中台的升级上，结合GPT和超级自动化作为新的突破点，提出了在数字中台基础设施上进一步提升能力的架构设计思路，并探讨了落地建设方面的问题和解决思路。经验因人而异，每个人都有自己的思考和理解。这个是下一步升级架构方案，当前还在进一步的优化和思考中，同时也在初步的结合中。以上为升级的方案，期望可以给他人一些参考，也期望有兴趣的朋友可以关注讨论。

鸣谢

这里主要参考了一些开源项目研究和得到的思路，这里做鸣谢：

• AutoGPT 为了目标实现而实现的能力
• 阿里云运维体系 运维体系和客服体系相当成熟
• Chat2DB 基于规范(SQL语法)基础实现的能力
• Kuboard 多产品和结合落地的能力体现

软件工程师罗小东，多年平台架构设计和落地经验，从单体工程到服务化工程，从整合再到拆分再整合实践过程中，对多边型架构的一些落地心得。

背景

这里以开源项目alinesno-cloud微服务架构的建设拆分再到整合成产品型结构的进行阐述，从原来的几十个工程基线(近百个服务模块)，再到后来的20个左右产品模块的组合，进行服务能力的输出。过程工程由微服务、六边型、再到多边型工程结构的实践经验，这里偏向于工程结构以适应平台产品化发展的变更。

需要达到的效果是把工程结构多组合的结构以适应项目的需求变化。多边形架构是一个泛指的概念，指的是由多个组件或模块组成的系统架构。这些组件或模块可以以不同的形状和大小组合在一起，形成各种不同形态的系统架构。多边形架构中的每个组件或模块都可以担任不同的角色和功能，并通过定义清晰的接口和协议，实现彼此之间的通信和交互。

概述

软件架构也在不断地演化。从单体应用到RPC服务再到微服务，这些技术的出现和应用都是为了解决不同阶段的问题。而六边形架构是在微服务架构基础上的一种新型架构，它强调领域驱动设计（DDD）和面向接口的编程，旨在更好地支持业务复杂度的增长和应对变化。

这里以时间维度阐述自己从MVC架构到六边型架构，再到多边型架构的产品线整合尝试，这里以过程以时间维度（18年到21年）和成熟度进行阐述过程。

• 初版定义：单体到Dubbo服务工程的尝试建设
• 技术升级：从Dubbo服务工程到Cloud工程结构的改造
• 产品改造：从Cloud工程到自定义工程结构的改造
• 模型成熟：从六边型概念到多边型工程结构的改造

对于这块的模型的定义有很多不一致的理解层面，这里针对的是问题和解决两个角度进行阐述，经验不一，我有我思。

过程

在产品型建设过程中，软件架构也在不断地演变和升级。从单体应用到分布式系统、再到微服务和六边形架构，每一种架构都有其独特的优势和适用场景。本文将会介绍从单体工程到RPC服务、再到微服务、再到六边形架构以及多边型架构的技术发展。

初版定义：单体到Dubbo服务工程的尝试建设

这个过程的改造适合国情化的发展

在单体应用时代，由于业务需求相对简单且交互较为单一，使用单体架构是比较合适的选择。但是，随着业务的不断扩大和功能的不断增加，单体架构也开始暴露一些问题，如代码耦合度高、代码可维护性差等。为了解决这些问题，在RPC服务时代，我们将原本单体应用中的模块拆分成了独立的服务，同时采用远程过程调用方式进行通信，使得不同服务之间的耦合度降低，系统的可扩展性得到了提升。

工程结构开始是MVC型，后面改成Dubbo型，将Service层抽取出来，提供出api实体和接口工程给第三方依赖，这个过程的改造会将庞大的业务系统架构进行拆分，形成多个模块化，将单体应用改造为Dubbo服务，可以将原本臃肿而难以维护的单体应用拆分成多个独立的服务，使得系统变得更加模块化和清晰。这样做的好处包括：

• 提高可伸缩性：将单体应用改造成Dubbo服务后，每个服务可以独立部署和扩展，可以根据实际负载情况进行动态伸缩，提高了系统的可伸缩性。
• 提高可靠性：Dubbo提供了多种服务治理功能，比如容错机制、路由策略等，可以有效保证服务的可靠性和稳定性，相对于单体应用更加可靠。
• 提高可维护性：将单体应用拆分成多个服务后，每个服务的代码规模变小了，易于维护和升级。同时，模块化的设计也使得开发人员更加关注自己的业务领域，提高了团队的开发效率。
• 提高代码复用率：Dubbo服务通过接口进行解耦，将相同或类似的功能封装到独立的服务中，提高了代码复用率，减少了重复开发的工作量。
  通过将单体应用改造成基于Dubbo的分布式服务架构，可以帮助企业构建基于微服务的架构体系，从而提高系统的可伸缩性、可靠性、可维护性和代码复用率。

这是一个不错的工程结构，而且确实也解决了原始大型工程的问题，这个过程的建设相对于传统项目来说，有可能会形成微服务，也可能会形成大型的分布式工程（也就是伪微服务），不过总的来说，会解决单体陷阱的问题。

技术升级：从Dubbo服务工程到Cloud工程结构的改造

新型的分布式服务，也会带来新的问题，需要让这个服务就做这个事情

Dubbo服务之间有很强的依赖性，在不小心或者不轻易间，会产生强依赖性和不断传递问题，这个形成的影响又是另一方面，特别是在公用网络或者外部网络的情况下，服务之间的关联还有调用不稳定性常常发生，还包括操作系统的因素等，另一个更为明显的，Dubbo只是一个RPC架构，针对微服务和分布式来说，外围生态和组件成熟度不高，基本上都是东拼西凑起来。

另一个更加夸张的是原阿里团队的不维护，导致出来了很多不一致的版本，生态体系有可能无法发展的情况，这个时候，不得来说，会转向SpringCloud体系，一个是协议的通用性，另一个是社区生态。虽然来说，不管从工程结构和代码量来说，Dubbo服务会少于Cloud体系，而且工程资源还有开发的习惯、有高性能、低延迟、易扩展等特点，但是无法在很多场景下，会带来很多限制。

另一个致命的是，由于工程结构的特点，它对外提供的是RPC接口是直接面向Service层服务，在很多情况下会影响项目开发人员，设计人员的设计思维，很多情况下我们只写到Service层服务，这个会让人有一种误区就是逻辑只到Service层，那这样的话，Rest层接口这个自然就不会存在，这样的设计，很多时候会无形的影响设计人员在处理服务模块的时候，会自然而然的将工程设计只到Service层。

这个容易产生大量的工程服务组件，在领域设计上，容易（这里只是说容易，但并不绝对）无形中拆分了这个模块，这个跟高内聚、低耦合的思想有一定偏离，在后期的使用过程中，总会感觉需要有一层进行聚合，而这个聚合的服务其实最好的体现在Rest层上面，而dubbo面向service的设计，让很多工程结构下无形的把这个思维在潜意识里面隐藏了。

开始尝试会在前面加一层聚合服务进行整合，但是这个链路并不是很乐观，因为从实际结果上，还是拆分了。

以上种种，将Dubbo服务工程结构转成SpringCloud工程结构，增加了一些层级和工程代码量，但是效果上会把上面潜意识的问题消除掉，达到的效果就是：这个服务就做这个事情，由原来的RPC服务减少，转成模块形的设计，进一步减少复杂度和提高服务的内聚。

产品改造：从Cloud工程到自定义工程结构的改造

在一些架构不满足的情况下，需要自定义工程结构

前期在使用Cloud过程中，过多的复杂组件和概念，还有starter工程结构的增加，无形中加剧和工程变重，这个过程容易影响业务的开发，另一个问题是，在服务组件不断的成熟下，这些组件会开始进一步的平台化（直白的说增加一个管理界面）。

它包含多个工程和组件，使得开发人员可以快速构建复杂的微服务应用程序。然而，使用大量的工程组件也有一些弊端：

• 复杂性：Spring Cloud包含众多的组件和工具，这使得整个应用程序变得非常复杂。开发人员需要学习和掌握各种组件的使用方法，这增加了开发难度和时间成本。
• 版本兼容性：由于Spring Cloud包含众多的组件和工具，每个组件都有自己的版本号。当一个组件更新版本时，它可能会影响其他组件的兼容性。这给开发人员带来了额外的负担，需要测试和修复版本兼容性问题。
• 性能问题：每个组件都需要运行在不同的进程中，这可能会导致性能问题。每个进程都需要消耗CPU和内存资源，这可能会降低整个应用程序的性能表现。

另外一个特别让人意外的是，Netflix组件在不断的放弃维护，而又发展出alibaba版、tenant版，还有n多的个人版本，这些基本上容易导致被牵着走。

在市场架构调整中，做了一些调整，以适配工程结构，同时抛弃掉Cloud思维结构：

• 去掉Cloud体系和大量的第三方组件，只保留基础的springboot工程结构，同时将第三方组件需要用到的核心能力进行自定义封装。
• 去掉所谓官方“好的”微服务插件，比如配置中心、注册中心、链路跟踪等，将这些独立出来，一般小的工程用不上，大的工程通过自定义封装包的形式加载（比如nacos)
• 将工程结构进一步的独立化，适当的组件进行平台化，通过租户的形式提供服务，并提供出可视化的管理界面
• 将大量的工程进一步压缩消减，形成模块化，提供包的形式，需要的时候依赖，而不是都通过接口调用，通过插件的概念形式进行整合（类似于wordpress插件）

通过上面的调整，你会发现，工程结构会有点类似于云平台，每个服务组件都有单独的能力，这个时候，产品型的体现已经慢慢程现，但是还不够充分。

模型成熟：从六边型概念到多边型工程结构的改造

为了产品更好的迭代和发展，提取出领域的概念，进一步彻底的产品化

架构也开始出现一些问题，如服务之间的依赖关系复杂、服务治理难度大等。为了解决这些问题，领域模型的思维进一步的切入到服务建设中。将微服务合并拆分出领域服务，并以领域模型为中心进行设计和开发，强调了面向API接口编程的思想，通过定义清晰的接口，使得不同服务之间的交互更加规范化、灵活化。

在这个过程中，特别需要关注的是业务本身的特点和复杂性，导致软件难以维护、扩展和适应业务变化，做了一些调整方向，主要是：

• 明确业务领域模型，提高业务分析和设计的准确性和效率，可以自由地进行修改、测试和演化，而不会对其他系统产生影响。
• 将业务逻辑与外部依赖分离开来，使得业务逻辑在不同的环境中都能够独立运行。
• 多个模块间内部核心和外部适配器之间通过接口来进行通信，使得它们可以相互独立地演化和变化。
• 多种不同类型的适配器，使得系统可以更加灵活地适应不同的业务场景和需求变化，从而提高了系统的可扩展性。

这个原来在调整工程结构过程时，发现六边型概念是跟我想要的基本上吻合的，而且融合度非常高，但是过多的代码编码概念，开发人员来说可能会有一定的技术门槛，特别是在领域建模、聚合、限界上下文等方面，在某个程度会让我们感觉到这个是否是我们需要的，最终我们把工程结构进一步拆分和根据内部的习惯定义，重新设计和工程结构，以下是调整的结构图：

这个调整的结构使得服务产品间更稳定，组件或模块可以以不同的形状和大小组合在一起，形成各种不同形态的系统架构，每个组件或模块都可以担任不同的角色和功能，并通过定义清晰的接口和协议，实现彼此之间的通信和交互，以适应不同的业务场景。

总结

以上为在过程工程由微服务、六边型、再到多边型工程结构的实践经验，这里偏向于工程结构以适应平台产品化发展的变更，最终发展形成产品化的工程结构调整过程。工程结构的调整是解决的是应用程序的可测试性、可维护性和可扩展性问题，同时针对于自己所面对的场景不断的适配调整过程，这个过程的调整差不多有4年左右，不断的进行优化调整而形成的结果，这里也是输出一些经验，供参考。

软件工程师罗小东，多年平台架构设计和落地经验，这里主要是针对于中台化项目交付与传统项目交付的一些心得体会。

理念

Supercell游戏开发公司内部有一套技术平台，旨在提供支持Supercell开发的多款游戏的共享工具、技术和基础设施。这个中台包括了各种组件和服务，如玩家账户系统、社交网络功能、统计分析工具、虚拟货币交易系统等等，这些工具和服务都可以在Supercell开发的不同游戏之间进行共享和复用。

让Supercell游戏开发团队更加专注于开发游戏本身，而无需重新开发已经存在的功能或迎合特定游戏的需求。同时，这也能够促进Supercell内的知识共享和协作，并且降低整体开发成本和风险，这也是中台架构的由来。

概述

在过去几年中，我们一直专注于中台架构和项目的开发。尤其是在处理中小型项目方面，我们积累了丰富的经验。以下是一个典型案例的分析，我们将从实践中总结出的心得和经验与大家分享。

在2023年的第一季度，团队完成了一个约为百万级的大数据项目。我们采用中台产品和ISV（业务组）合作伙伴的方式进行交付。相对于传统项目，这种模式在交付和团队优化方面有明显的不同。只是说感觉相对于网上各种理论来说，各种概念的解释来说，原来初衷的理念更加符合，而我想要的也是这个模式，而不是网络上被各种名词和概念所淹没的中台模式，有时候会把一些简单的事情说得太过于玄乎，而没有体现初衷。

起初听到芬兰SuperCell模式时，原本觉得有这个可能，但是过程当中的体会没那么深，对外交流的时候，各种底气还是来自于一些材料，但是当真正自己在用SuperCell模式(也就是中台)的时候，你会发现，这个结构在一定的程度上确实将团队的结构还有能力进行了优化处理，而且整个流程过程会更加顺利，这里主要从几个角度进行阐述：

• 项目中的中台组织结构是怎么样的；
• 过程怎么分工处理同时做好前端的支撑；
• 过程的一些常见问题和规避操作；

不同于大厂的中台交付模式，但团队和经验不同，因此我们只针对中小型项目进行说明，我有我思。

过程

在过程中，做了很多的职责分离，这里针对于原来的数字中台运营方式来进行，角度阐述也是从这个运营思路。

项目中的中台组织结构是怎么样的

传统项目的组织结构会一个项目从各个层级跟到尾，可能管理团队多个方面，而这里略有不同。

在这个大数据项目里面，我们的组织结构基本上对项目经理的职责还有中台人员的职责进行了调整（这里不提商务）。

在传统或者一般的项目里面，项目经验对接的职责和范围可能会比较大，在项目组里面人员权限也比较大，调动的人员可能从下层的开发和底层的技术人员可能都会涉及，而在中台的组织结构里面，我们把项目结构进行了两层拆分，分成了中台层和项目层，而项目经验对接的只是每层的负责人。另一个是项目的实施过程也进行了拆分，分多个阶段，一个是中台的产品交付和业务需求的实施交付，还有另一个是中台后期的支撑。

感觉这个过程好像跟一般的项目过程，比如甲方乙方等实施交付区别不大，我第一感觉也是如此，但是实际并不是。

这个阶段之间的分隔，在传统项目交付里面并没有那么明确，而且人员意识还有团队意识，过程的沟通，交付产物等，各个角色支持力度等需要更加的明确，怎么说的呢，就是在前期一些培训阶段的时候，问题最多不是技术，反而是这个阶段之间的实施问题。常常会出现，要么就是业务进到中台层里面，要么就是中台层进入到业务里面，类似的情况，往往是缺少阶段处理的意识，这个就会形成一定的交付隐患。

中台层要做的是架构方面和一定范围能力的技术的支持，但是不要介入到业务里面，业务场景最合适的业务层的解决办法，中台需要提供的是平台级的能力，因为中台层要支撑的不仅仅是一个项目，而是多个项目，这个需要在支撑阶段提出明确的支撑能力，哪些有，哪些没有。

业务只需要根据中台的能力来进行场景的规划，如果需要的或者确实没有的而一定需要用到的，或者提交需求到中台即可，而不是等着中台解决业务问题，形成两边的死循环。

在前期的组织结构初期，就做了明确的沟通要求了边界，明确划分哪个阶段参与和明确提出计划和时间。

过程怎么分工处理同时做好前端的支撑

传统项目可能前期有需求还有原型等之类的，或者需求调研之后才会考虑到实施，这里也略有不同。

在数字中台上会带有一部分基础的业务能力，还有一些通用的服务组件，在项目确定开始之后，基本上实施计划和工作就已经开始，另外加上是一些数据类项目，通用的组件更多，而我们要做的是数据输入层，也就是数据调研和采集，这个前期都有一定的模板和样例，在项目开始的前一周，实施的准备条件就已开始部署，交付出第一版本给客户演示的时候，差不多是项目开始后的两三个星期左右，后面就是培训使用。

而这个过程业务端在进行业务的处理的开发，中间加上客户的时间情况等等，这个业务型开发的时间在一个月左右，因为在中台上也包含技术devops，在这个过程都会自动同步到用户测试环境，这个过程时间相对来说，也比较从容，业务团队过程中需要的文档和手册等处理，中台团队会有一些培训，这个培训时间大概是前面的三天左右时间。其它的就是等数据调研这部分的结果，完成之后数据采集到数据中台里面，进一步的分层、计算、接口等获取到指标，输出给业务方，这部分主要是中台的过程中的操作，同步带好业务端的人员怎么使用，带好流程。

这个过程中一个比较大的体会是角色定位和分工上，还有时间点的把控上等都会比较明确，会有一些卡点，但是相对于以前传统项目方式来说，这个会更加明确。

过程有碰到的一个时间是过年时间，在这个时间后，基本上业务演示的第一版本也就出来了，在给领导层做演示，得到一定的认可后，基本上就走验收流程。前后大概是两个月的时间，其它的时间点会有一些运维和管理的操作，这部分在业务上，也在移交到运维层面上，在项目上投入的资源也进一步的减少。

这个过程中的一个比较明确的体会就是时间，时间点上会比较明确和准时，如果说业务组在缺少数据中台产品的支撑和中台团队的支撑，是基本上不可能在这么短的时间出的结果，而中台团队没有前期的积累也基本上不太可能会跟业务组和项目实施等配合得好。甚至在实施过程中，因为业务组一直做的是业务组件（我们把业务组件分开和微服务化），在交付实施过程才发现这个项目是一个比较大的项目，涉及到模块那么多，这也是原来考虑的，业务组要做的是做好业务场景需求就可以，其它的中台层给好支撑点。

另外一个因素是中台和业务组的磨合，初期的项目会有一些磨合，如果这个过程没有做过，可能会消耗一至两周的时间点，这个需要考虑的。

过程的一些常见问题和规避操作

过程一直强调角色和职责，业务组和中台组就做好自己的事情就可以。

在这个过程中，也会有很多的坑点，一些不注意可能也会形成项目后期的问题，类似于技术债，大致列了几个问题：

1. 避免让业务组接触太多的技术概念而忽视业务
   在中台会有很我技术概念和学习层面，这个过程容易使业务组的技术人员深入到技术层面，比如微服务、容器化、主数据、Hive等，它需要的是一个模板和使用说明，而不是研究说明，根据业务场景来进行模板输出就可以，后面根据个人兴趣去学习即可，重点是给出使用案例。比如数据采集，跟业务组人员说“发送到数据总线”可能他们会迷糊一下，但是跟他说“发送到这个API接口”他就立马明白。
2. 实施过程中台文档的产出
   文档材料的产出是过程中特别需要注意和加深的，也是中台组的要求，这里对业务组的要求由项目经理，但是中台组的要求是一定要有文档的产出，这个文档的产出并不是只是一个项目，而是多个项目都有在使用的时候，这些文档和沉淀对中台组来说意义就比较大，实现的输出的意义也比较大，同时对文档有比较严格的要求，格式还有内容等，形成高质量的文档，这部分不论在哪个项目都做了强制性的要求，同时方便后期更新迭代等。
3. 避免两个组之间互相切换和沉入
   中台切入业务，业务切入中台，这个是前期特别容易出现的问题，只需要一个简单的场景，在讨论过程中，如果没有这个意识，就会变成中台组在做业务组件开发的情况出来，或者业务组提要求了，然后中台组根据特定（注意是特定）修改中台组件的情况，后面一种是我们特别容易出现的，而且也特别头大，有些情况下确确实实是中台组加个字段或者加个功能会比较简单，但是这个属性是某业务特有的，实际上这个过程从业务组做维护会更好。比如我们会用电信厂家的接口发送短信，而不会给个单独给某个业务设置接口，除非说这个接口有多行业公共的属性，那再统一集成。

当然，还有周期、工时、支撑、商务等挺多方面，这些主要依赖于过程的团队的情况和管理方式进行处理，这里就不做过多的阐述。

总结

在前期多个中小型项目中，我们建设中台体系的过程虽然有听说中台模式的好处和优势，但是身边比较少成功的案例（除了一些大厂），或者说在使用了并没有发挥出它本身应该有的作用，结合起来发现并没有达到降本增效的层面，反而发现过程更加复杂和麻烦，最后发现可能还没有原来单体应用的简单。

这些以前见到其它陷入的比较多，从自己的心得来说，这些是一个过程点，但是要达到终点，这个需要比较大的，而且长期的团队实战和不断迭代升级过程，上面是在这方面的心得体会，希望可能给一些人参考。

软件工程师罗小东，多年平台架构设计和落地经验，这里从智慧型项目、数字化项目进行数据治理建设的一些经验总结。

概述

针对于中小型团队和当前接触到的大部分项目来说，很少有非常大的数据治理需求，特别是互联网型的PB级数据。在大部分情况下，数据量在TB级或亿级级别较多。相对于PPT级别的方法论，会更加注重于实际运用，为了应对这些场景，我们在以下几个方面进行了考虑和优化：

• 是否真的需要建立一个Hadoop体系的数据仓库
• 针对于中小型客户数据治理需求怎么建设
• 怎么样针对当前的项目进行数据资源管理
• 后期的数据治理和各个数据治理维护怎么做

在真正理解项目需求、精细化管理以及灵活选择数据治理工具和技术的基础上，能够更好地应对不同场景下的数据治理需求。不同项目不同架构，我有我思。

过程建设

许多客户都有数字化建设的需求，但不同的场景需要使用不同的技术方案，在具体的建设过程中，整理的一些思路：

• 首先要充分了解客户的业务场景和需求，从而选择最适合的技术方案。
• 在建设过程中，要注重数据质量和服务，以确保数据的准确性和能力体现。
• 合理规划数据治理流程，包括数据采集、清洗、转换、存储等环节，并通过数据可视化手段展示数据治理效果，提高数据治理成效。
• 对于不同的项目规模和预算成本，选择不同方案，优化算法和调整计算引擎，减少资源和成本。

针对不同的客户场景，规划合理的数据治理流程。

是否真的需要建立一个全套的数据仓库体系

针对于不同的场景，对于数据治理，需要根据具体场景来选择合适的方案

前期的搭建方式

目前在搭建数据治理平台时，开始我们使用的是CDH做为数据仓库底座，通常使用Hadoop体系的数据仓库平台，并按照ODS/DWD/ADS等层级进行划分，通过Kettle/Filebeat/Sqoop等方式抽取数据进行离线计算，使用Hive做为数据仓库，我们的工程师在这块上也有多年的治理经验，计算引擎使用的偏向于Spark，数据建模和维护也是按通用的数据标准处理，这个有前期多个项目里面基本上都是，有一些项目会运行在K8S上。

这个过程消耗的资源较多，而且计算引擎和计算过程比较统一，特别是Spark计算的时候，消耗大量的内存资源。而对于一般中小型项目，或者一般的客户来说，这个资源的建设会成本过高，特别是在数据治理这块并不是要求特别高的时候。

客户数据治理成本高

一些客户可能并不理解数据治理的成本和价值，除了政务型项目或不缺费用的项目，很难落地，没有达到预期的数据运营效果。

比如一个智慧社区项目，在这块上的数据仓库主要存储的数据在几个方面，用户行为、IOT数据采集、还有视频流数据的存储（只存储主键祯数据）,另外就是一些业务系统的数据采集存储，针对于以上数据的分析，与AI结合，提供出API服务能力，在这些数据中，超过一定生命周期的会做清理，最后评估出来10年左右180T存储，而这个过程中，大部分是冷数据。

最后建设使用的方案是云厂家的一体机来进行管理，但是这个成本是极高的，类似于这样的数据场景，遇到的比较多，最后在考虑一个问题，是否需要这么重的数据仓库。

针对于中小型客户数据治理需求怎么建设的

建立一个轻量级的数据场景，以更好地满足不同项目的需求。建设轻量级数据治理平台

建设轻量级数据治理平台，是优化数据管理和维护成本的方法之一。目前大数据套件较多，学习成本较高，对中小型团队而言，这一成本占比较大。因此，需要采取有效措施降低人员培训成本和管理维护成本。

将多个工具整合为轻量级数据中台，使用minio分布式存储、Clickhouse数据仓库、kettle抽取工具和kafka数据总线等技术统一数据治理，适配各类规模的企业需求。在数据清理和转换后，将数据存储到ODS层，非结构化和半结构化数据存储在分布式存储和ES中，并根据生命周期规划定期清理不必要的数据，只保留有价值的数据和流程相关数据。

此外，针对人员培训，设计系统化的培训课程和多种灵活的培训方式，以提高员工的数据管理和分析能力。对于团队管理和维护，可以建立数据治理的文化氛围，鼓励全员参与，同时引入自动化工具和脚本，减少人工操作和管理成本。

通过以上措施，项目可以建设出高效、灵活的数据治理平台，降低人员培训和管理成本，提高数据治理能力和业务价值体现 ，实现项目的业务需求和决策目标。

怎么样针对当前的项目进行数据资源管理

建设通用的数据治理能力组件和平台组件，以便根据具体项目需求进行选择和组合，实现对数据资源的有效管理。

针对当前的项目进行数据资源管理，可以建设一套通用的数据治理能力组件和平台组件。这些组件可用于多种场景下的数据治理工作，如：

• 数据上报服务：供政务、个人、单位等通用型用户使用的通用数据采集上报平台，支持非技术型人员和部门进行数据入仓。
• 数据总线服务：连接数据平台中不同组件和子系统的核心组件，实现数据的快速传输和交换，并统一集成数据主题管理。
• 主数据管理服务：帮助企业确保数据质量、提高业务流程效率，并为数据分析和决策提供支持，促进企业内部数据的标准化、管理和共享。
• 数据集成服务：提供在线设置ETL作业、转换任务的定时运行策略，监控任务的执行情况，查看任务执行日志的功能，强有力地支撑后续的数据开发、数据挖掘。
• 数据开发服务：向数据开发工程师提供拖拉拽控件的方式，设计复杂的工作流有向无环图，挖掘出有商业价值的数据。
• 数据安全网关：提供数据交换、数据共享、数据开放的平台，包含网关接口安全、接口权限认证、黑名单管理、Oauth2接口认证等功能，向组织内各个部门提供支持。

这些数据治理能力组件和平台组件可根据具体项目需求进行选择和组合，实现对数据资源的有效管理，我们采用灵活的数据治理方案，根据项目大小和需求，选择相应的数据治理工具和技术。

在提供工具的同时，针对于业务的个性化要求和业务开发需求，比如报表、大屏、还有数据服务使用等，当前是让ISV团队进行处理，而这个过程由中台团队提供技术支持和培训，而数据治理套件不对客户。

后期的数据治理和各个数据治理维护怎么做

建立一套完善的数据治理流程和规范，包括数据质量控制、数据安全保护、数据持续更新等方面的要求

实现数据治理和各个数据治理维护的目标，包括数据流程标准化、人员技术培训、数据指标采集等。在实际应用过程中，需要根据企业的具体需求和情况，适当调整和优化数据治理策略，以提高数据质量和效率，为项目的发展提供有力支撑。

• 数据流程标准化：通过数据总线服务连接数据平台中的不同组件和子系统，以便实现数据的快速传输和交换，并统一集成数据主题管理。建立标准化的数据流程，包括数据采集、清洗、存储、转换等环节，并确保每个环节都符合相关标准和规范。
• 人员技术培训：利用主数据管理服务对企业内部数据进行标准化、管理和共享，确保数据质量和提高业务流程效率。同时，为各个层次的员工提供有针对性、系统化的培训课程，提高他们的数据管理和分析能力。
• 数据指标采集：使用数据集成服务在线设置ETL作业和转换任务的定时运行策略，监控任务的执行情况和查看任务执行日志的功能。确保多种数据格式和来源的数据经过清洗、转换后能够及时有效地送达组织的数据仓库，并为后续的数据开发和挖掘提供支持。
• 数据治理目标达成：使用数据开发服务向数据开发工程师提供拖拉拽式的控件，设计复杂的工作流图，挖掘出有商业价值的数据，帮助企业实现对数据的全面管控和治理。同时，使用数据安全网关进行数据交换、共享和开放的管理，确保数据的安全性和防止潜在的风险。

同时实现对数据的全面管控和治理，确保数据的质量和安全，提高数据开发和分析的效率和准确性，从而更好地支撑企业的业务需求和决策，提供出数据服务和治理。

总结

数据治理是数字化建设中非常重要的一环。在进行数据治理时，我们需要根据不同的业务场景和需求，选择最适合的数据治理方案，包括选择不同的组件组装和数据存储方式等。对于轻量级数据管理平台和重量级数据管理平台，我们可以针对具体情况进行选择，权衡成本与效益，以满足客户实际需求。在整个数据治理过程中，我们还需要注重客户成本的管理，确保项目的落地和实际效果，并且不断优化数据治理流程，需要积极参与业务需求分析和技术选型，确保数据治理方案符合客户需求和行业标准。

过程考虑不同的场景选择不同的数据治理方案和组件组装，根据实际情况选择轻量级或重量级数据中台，注重客户成本管理和实际效果，以满足客户需求并推动数字中台建设。

以上为在大中小型项目中的数据治理经验输出，提供一些参考。

附录

• 我们使用的数据开发工具是dolphinscheduler进行二次开发整合 ，是一个非常优秀的数据开发工具