架构自治服务是一种面向架构分析领域的数据自助服务。它提供了一种集成一体的数据分析方案，让开发人员、架构师、管理者等可以根据不同任务，自由搭配、组合出适用于自身洞察需求的任务/函数。
最近，刚好看到两本书名非常有意思的书：《持续 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+ 的团队时，这一类工具带来的收益就会相当的可观。
