架构自治服务：构建数据驱动的架构洞察

架构自治服务是架构分析领域的数据自助服务。它提供了一体化的数据分析解决方案，允许开发人员、架构师、管理人员等根据不同的任务自由匹配和组合适合自己洞察需求的任务/功能。

最近，我偶然看到两本书，书名很有趣：《持续 API 管理》和《数据自助服务实践指南》。前一本书的内容配不上大纲，后一本书的标题配不上内容——内容不错，但标题错了。原书的书名是《The Self-Service Data Roadmap》，重点介绍各种数据自助模型和路线图。

回到正题，这两本书的书名让我思考了两个问题：1.如何构建持续的架构治理？ 2、架构如何构建自治服务？只有实现自助+连续性，开发者才能实现架构自治。另一方面，从数据治理的角度来看，架构治理本身也是数据。在数据领域，自助服务已成为数据民主化的重要趋势（来自《大数据湖最佳实践》）。这一点可以从流行的Tableau、Apache Superset等看出。

我们为什么考虑构建自治服务？

Log4j 跟踪

我们受到 SourceGraph 的 Insight 工具的启发。在该工具的演示中，它提供了Log4j版本的趋势跟踪。开发者可以通过编写表达式来进行数据统计，如：>=1.12.0。那么，我们又迎来了一个顿悟时刻：这难道不是许多 ArchGuard 用户在过去几个月中面临的痛点吗？对于大型 IT 组织来说，这种跟踪可以从治理层面提供更高的整体视图。

改变是一个过程

从“无序”状态到“有序”时期，需要一个漫长的过程。在这个缓慢的过程中，每个人或组织都会以不同的方式做出反应，有些通过可视化，有些通过数据。无论采用哪种方法，都需要流程的数字化。

最佳实践的局限性

在日常生活中，技术专家总是向人们传播各种“最佳实践”，但这并不是人们所需要的。对于大多数人来说，他们更想要的是能够解决当前的问题，他们需要的是最佳实践。这个实践可能是代码实践、分层架构实践、边界划定实践。此外，看似“标准化”的架构测量模型通常很难应用于大多数大型组织。

什么是架构自治服务？

受到《数据自助服务实践指南》的启发，我们开始探索什么是架构自治服务。我们称之为架构治理型数据自助服务、架构自治服务：

架构自治服务是针对架构分析领域的数据自助服务。它提供了一体化的数据分析解决方案，允许开发人员、架构师、管理人员等根据不同的任务自由匹配和组合适合自己洞察需求的任务/功能。

本质上是特定领域（即架构）的数据自助服务。作为工程师和架构师，我们可以根据我们的领域知识构建系统。这种领域知识不仅来自于自己的经验，还来自大量前人的经验：各种书籍。

基于这个想法，我们制定了ArchGuard在不同阶段应该如何发展的路线图，即构建自治服务。

架构自治服务路线图

在架构演进的场景中，可定制的架构适应度函数可以作为自动化的目标。根据不同的自主服务需求，对应的模式有四种（从低到高）：

探索性数据分析模式。专注于理解和总结架构治理所需的数据集，以确定所需的数据整理转换。数据结构、内容和关系是否正确？

领域知识转换模型。将 SOLID、CUPID 等知名行业最佳实践知识内化到自助服务中。

分析转换模式。结合架构关注点和可视化分析，以交互方式组织数据并转换为流程，例如 Log4j 整改跟踪。

操作洞察模式。从多层指标出发，为数据用户提供了丰富的、相互关联的可操作集合，例如架构和度量函数。

从抽象模型上看，它是结合领域知识构建的数据自助服务，更聚焦于“数据转换+数据搜索”两个核心。

构建自治服务的示例

还记得开头提到的SourceGraph，它提供了灵活的数据洞察服务。通过以下方法，可以追踪系统的Log4j问题：

lang:gradleorg\.apache\.日志记录\.log4j[ '"] 2\.(0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16)(\.[0- 9]+)patterntype:regexp

由于SourceGraph更多的是基于正则分析，所以需要通过复杂的正则表达式来实现。

ArchGuard 基于 AST + 模型分析，因此需要根据字段进行过滤：

字段:名称 == /.*log4j/ 字段：版本> 2.17.0

为了提供更好的自助服务，我们需要流畅的灵活性和实用性。在这种情况下，正则化显然提供了更大的灵活性。

从此，我们可以追踪整个组织的Log4j治理状态。

如何实现架构自治服务？

从ArchGuard的实验和我们在数据方面的一些经验来看，实现这样的架构自治服务可以分为四个步骤：

1. 构建架构治理的数据库
2. 抽象数据服务的接口
3. BI和BI的自助交互分析
4. 设计指标驱动的架构演进。例如，一个精心设计的适应度函数

就是数据的完整性。对于我们来说，重点是如何建立这样一个数据库。

1。构建架构治理的数据库

组织内一系列现有架构（广义的架构）管理相关的大量工具：

• 代码质量控制：SonarQube（部分功能）、ArchUnit、Jacoco、CheckStyle等
• SCA（软件组件分析）分析：JFrog Xray、Black Duck等
• 漏洞扫描工具：OpenVAS等
• API管理：Swagger等

这样的工具还有很多，但很多我都看不懂。对于这一系列工具来说，需要将数据连接起来，提供一个“连接共享”的数据库。

所以，为了实现数据的自助服务能力，我们需要构建一个数据库作为基础设施。当然，在 ArchGuard 中，我们做得不太好。

2。抽象数据服务的接口

根据定义，对于架构治理，围绕ETL+数据自治服务，我们可以重点关注：

• 数据整理服务。它包括元数据处理的各个方面，例如模型和访问标准化：在Chapi底层抽象不同语言的数据模型，或者在Scanner底层抽象依赖关系。
• 数据转换服务。允许开发者在数据处理过程中添加一些特定的业务逻辑。
• 数据搜索服务。如何简化数据发现过程，使用关键字、通配符等，并减少处理所需的时间。

在排序、转换、搜索这三个阶段，我们要构建很多抽象来提供数据的自助服务。组织可以通过模型来抽象，转换可以通过插件接口来抽象，搜索可以通过DSL来抽象。

3。如禾BI自助交互分析

简单场景下，我们应该使用现有的BI（商业智能）工具进行分析。其前提是组织已经拥有成熟的数据系统。如果没有，那么我们就要思考如何才能达到这样的能力？如何构建这种建筑数字孪生？

然而，无论怎样，构建一个支持自助交互分析的工具都是困难的。

4。设计指标驱动的架构演进

《演进式架构》中推荐的适应度函数仍然是我们推荐的架构治理方法。虽然书中不会给出明确的定义，但可以为各个组织制定适合自身需求的指标模型提供参考。

我们还在思考什么是合理的模型？如何更好地推进整个组织的结构性治理？

总结

最后，回到ArchGuard问题（#93），问题类似：做了这么多，我们如何证明它有效？

因此，基于这些数据，我们也做了一些思考，例如：基于AST和机器学习构建自动升级。当我们有10个基于log4j使用内部封装的项目时，类似的项目是否可以直接用类似的方式进行改进，或者是否可以生成相应的自动重构CLI。当我们是一个1000+的团队时，这类工具带来的好处将是相当可观的。