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

架构自治服务是一种面向架构分析领域的数据自助服务。它提供了一种集成一体的数据分析方案，让开发人员、架构师、管理者等可以根据不同任务，自由搭配、组合出适用于自身洞察需求的任务/函数。

最近，刚好看到两本书名非常有意思的书：《持续 API 管理》、《数据自助服务实践指南》，前者书的内容对不起大纲，后者书的标题对不起内容 —— 内容是好内容，但是标题不对。原书的标题是《The Self-Service Data Roadmap》，重点在于介绍各种数据自助服务的模式和路线图。

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

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

Log4j 的跟踪

我们从 SourceGraph 的 Insight 工具上获得了启发，在这个工具的 Demo 上，它提供了一个 Log4j 版本的趋势跟踪。开发人员可以通过编写表达式，诸如于： >= 1.12.0 的方式来进行数据统计。于是，我们又一次地迎来了 aha 时刻：这不就是在过去的几个月里，诸多 ArchGuard 用户面临的一类痛点吗？对于的 IT 大型组织来说，从治理的层面来说，这种跟踪能提供更高的全局视野。

改变是一种进行时

从一个 “无序” 的状态到一个 “有序” 的时期，都需要一个很长的过程。这种缓慢的过程里，每个人或者组织的应对方式都是不同的，有的是可视化，有的是通过数据。不论采用的是何种方式，它都需要对于进行时的数字化。

最佳实践的局限性

技术专家的日常，总是会向人传播各种 “最佳实践”，那并不是人们所需要的。于多数人而言，他们更想要的是能解决当前的问题，需要的是一种最好的实践。这种实践可能是代码上的实践，分层架构上的实践，边界划分上的实践。除此以外，看上去 “标准化” 的架构度量模型，往往很难以在多数大型组织上适用。

什么是架构自治服务？

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

从本质上来说，它是特定领域（即架构）的数据自助服务。作为一个工程师、架构师，我们可以基于我们的领域知识来打造系统。这种领域知识，除了来自于自身的经验，还来自于大量先辈的经验：各种书。

根据这样的思想，我们制定了一个在不同阶段中，ArchGuard 应该处于怎样的状态，即架构自治服务的路线图。

架构自治服务路线图

在架构演进的场景之下，可以以可自定义架构适应度函数作为自动化的目标。按不同的自治服务需求，对应有四种对应的模式（由低到高）：

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

领域知识转换模式。将行业内熟知的最佳实践知识，如 SOLID、CUPID 等内化到自助服务中。

分析转换模式。结合架构关注点与可视化分析，通过交互式的方式来整理数据，并转换到流程中，如对于 Log4j 的整改跟踪。

操作洞察模式。从多层指标出发，为数据用户提供一组丰富的可操作集合，它们之间是相互关联的，如架构适度度函数。

从抽象模式上来说，它是结合了领域知识所构建出来的数据自助服务，更多的是集中于数据转换 + 数据搜索的两个核心中。

架构自治服务的示例

还记得开头提到的 SourceGraph 吗，它提供了一种灵活的数据洞见服务。采用如下的方式，就可以跟踪系统的 Log4j 问题：

lang:gradle org\.apache\.logging\.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 + 模型分析的，所以需要基于字段（field）进行过滤：

field:name == /.*log4j/ field:version > 2.17.0

为了提供更好的自助服务，我们需要在平稳灵活性与实用性。在这种情况下，基于正则显然能提供了更强的灵活性。

于是乎，我们便能跟踪起整个组织的 Log4j 的治理情况。

如何实现架构架构自治服务？

从 ArchGuard 的试验，以及我们在数据上的一些经验，实现这样一架构自治服务可以分为四步：

构建架构治理的数据底座
抽象数据服务的接口
揉和 BI 的自助交互分析
设计指标驱动的架构演进。诸如于设计合理的适应度函数

简单来说，就是数据的整俣。而对于我们来说，重点便在于如何构建这样的数据底座。

1. 构建架构治理的数据底座

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

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

诸如此类的工具也非常之多，只是呢，很多我也不懂。针对于这一系列的工具，需要进行数据上的打通，以提供一个 “联接共享” 的数据底座。

于是乎，为了达到数据上的自助能力，我们就需要构建数据底座作为基础设施。当然了，在 ArchGuard 里，我们对于这点做得并不好。

2. 抽象数据服务的接口

从定义上来说，对于架构治理，围绕于 ETL + 数据自治服务，我们可以关注于：

数据整理服务。它包含了方方面面的元数据处理，诸如于模型与接入标准化：在 Chapi 底层对于不同语言的数据模型进行抽象，又或者是在 Scanner 底层对于依赖进行抽象。
数据转换服务。让开发人员可以在数据处理的过程中，添加一些特定的业务逻辑。
数据搜索服务。如何简化数据的发现过程，使用关键字、通配符等，并降低处理所需要的耗时。

在整理、转换、搜索三个阶段里，我们都要构建大量的抽象，才能提供数据上的自助服务。在整理上可以模型来抽象，在转换上通过插件化接口来抽象，在搜索上通过 DSL 来进行抽象。

3. 揉和 BI 的自助交互分析

在简单的场景里，我们应该使用现有的 BI （Business Intelligence，商业智能）工具进行分析。它的前提是，组织内部已经有了成熟的数据体系。如果没有的话，那么我们就要思考着如何达到这样的能力？如何构建这种架构上的数字孪生？

但是，不论如何，构建一个支持自助交互分析的工具也难。

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

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

我们也依旧在思考什么才是合理的模型？怎样才能更好地推进整个组织的架构治理？

小结

最后，回到 ArchGuard issue（ #93 ）的问题类似：做了这么多，怎么证明能起作用？

也因此，基于这些数据，我们还进行了一些思考，打个比方：基于 AST 与机器学习构建自动升级。当我们有 10 个项目采用了基于 log4j 的内部封装，那么，对于相似的项目是不是直接能以相似的方式进行改进，又或者是生成对应的自动重构 CLI。当我们是一个 1000+ 的团队时，这一类工具带来的收益就会相当的可观。