架构自治服务是面向架构分析领域的数据自助服务。它提供了一个一体化的数据分析解决方案，让开发人员、架构师、管理者等可以根据不同的任务，自由匹配组合适合自己洞察需求的任务/功能。最近刚看到两本书，名字很有意思：《持续 API 管理》和《数据自助服务实践指南》。前书内容不如大纲，后书书名不如内容——内容是好内容，但书名错了。原书的书名是，着重介绍了各种数据自助服务模型和路线图。回到正题，这两本书的书名让我思考了两个问题：1.如何构建持续的架构治理？2、如何构建一个自治服务的架构？只有自服务+持久化后，开发者才能实现架构自主。另一方面，从数据治理的角度来看，架构治理本身也是数据。在数据领域，自助服务已经成为数据民主化的重要趋势（来自《大数据湖最佳实践》）。这可以从流行的Tableau、ApacheSuperset等看出。为什么我们要考虑构建自治服务？对于Log4j跟踪，我们从SourceGraph的Insight工具中获得灵感。在这个工具的Demo上，提供了Log4j版本的趋势追踪。开发者可以通过编写表达式来进行数据统计，例如：>=1.12.0。所以，我们又迎来了另一个惊喜时刻：这不就是许多ArchGuard用户在过去几个月所面临的痛点吗？对于大型IT组织，此跟踪从治理角度提供了更高级别的全局可见性。变化是一个从“无序”状态到“有序”状态需要很长时间的过程。在这个缓慢的过程中，每个人或组织的反应都不同，有的通过可视化，有的通过数据。无论采用哪种方法，都需要将正在进行的时间数字化。最佳实践的局限性在技术专家的日常生活中，总是向人们传播各种“最佳实践”，这并不是人们所需要的。对于大多数人来说，他们更想要的是解决当前的问题，他们需要的是一种最佳实践。这种实践可能是代码的实践，分层架构的实践，边界划分的实践。此外，看似“标准化”的架构测量模型往往难以适用于大多数大型组织。什么是架构自治服务？受到《数据自助服务实践指南》的启发，我们开始探索什么是自治服务的架构。我们把架构治理类型的数据自助服务称为架构自助服务：架构自助服务是一种针对架构分析领域的数据自助服务。它提供了一个一体化的数据分析解决方案，让开发人员、架构师、管理者等可以根据不同的任务，自由匹配组合适合自己洞察需求的任务/功能。本质上，它是特定领域（即模式）的数据自助服务。作为工程师、架构师，我们可以根据我们的领域知识构建系统。这种领域知识，除了自己的经验之外，还来自于大量前辈的经验：各种书籍。基于这个思路，我们制定了ArchGuard在不同阶段应该处于什么状态的路线图，即自治服务的架构。在架构演进场景下，自定义架构服务路线图可以将可定制的架构适应度函数作为自动化的目标。根据不同的自主服务需求，对应的模式有四种（从低到高）：探索性数据分析模式。专注于理解和总结架构治理所需的数据集，以确定所需的数据整理转换，例如数据结构、内容、关系是否正确？领域知识转换模型。将业内已知的最佳实践知识（例如SOLID、CUPID等）内化到自助服务中。分析转换模式。结合架构关注点和可视化分析，交互组织数据并转化为流程，例如Log4j的整改跟踪。运营洞察模式。从多层指标开始，为数据用户提供一组丰富的可操作集合，这些集合相互关联，例如架构调节功能。在抽象模式上，它是结合领域知识构建的数据自助服务，更专注于数据转换+数据搜索两大核心。构建自治服务的示例还记得开头提到的SourceGraph吗，它提供了一种灵活的数据洞察服务。使用如下方法跟踪系统的Log4j问题：lang:gradleorg\.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:name==/.*log4j/field:version>2.17.0为了提供更好的自助服务，我们需要稳定以及灵活性和实用性。在这种情况下，正则化显然提供了更大的灵活性。于是乎，我们可以在整个组织中跟踪Log4j的治理情况。如何实现架构架构自主服务？从ArchGuard的实验和我们在数据方面的一些经验来看，实现这样的架构自治服务可以分为四个步骤：构建架构治理的数据库，抽象数据服务的接口，BI的自助交互分析设计指标驱动的架构演变。比如设计合理的适应度函数，简单来说就是数据的完整性。对于我们来说，重点是如何建立这样一个数据库。1、构建架构治理的数据库大量组织中现有的一系列架构（广义上的架构）管理相关工具：代码质量控制：SonarQube（部分功能）、ArchUnit、Jacoco、CheckStyle等。SCA（softwarecomponentanalysis））分析：JFrogXray、BlackDuck等漏洞扫描工具：OpenVAS等API管理：Swagger等工具很多，但很多我都不懂。对于这一系列的工具，需要打通数据，提供一个“连接共享”的数据库。于是乎，为了实现对数据的自助服务能力，就需要搭建数据库作为基础设施。当然，在ArchGuard中，我们并没有很好地做到这一点。2.抽象数据服务的接口从定义上看，对于架构治理，我们可以关注ETL+数据自治服务：数据整理服务。它包括元数据处理的方方面面，比如模型和访问标准化：在Chapi底层抽象不同语言的数据模型，或者在Scanner底层抽象依赖。数据转换服务。允许开发者在数据处理过程中加入一些特定的业务逻辑。数据搜索服务。如何简化数据发现过程，使用关键字、通配符等，减少处理所需的时间。在整理、转换、搜索这三个阶段，我们要建立很多抽象，才能提供对数据的自助服务。在排序方面可以通过模型进行抽象，在转换方面可以通过插件接口进行抽象，在搜索方面可以通过DSL进行抽象。3、与BI的自助交互分析在简单的场景下，我们应该利用现有的BI（BusinessIntelligence）工具进行分析。它的前提是组织内部已经有一套成熟的数据系统。如果没有，那我们就得想想如何实现这样的能力？如何在此架构上构建数字孪生体？但是，构建一个支持自助交互分析的工具也很困难。4.设计指标驱动的架构演进《演进式架构》中推荐的适应度函数仍然是我们推荐的架构治理方式。虽然，书中不会给出明确的定义，但提供的参考资料可以：为每个组织制定适合自己需求的指标模型。我们还在思考什么是合理的模型？如何更好地推动整个组织的治理？总结最后，回到ArchGuardissue(#93)，问题是类似的：做了这么多，如何证明它是有效的？因此，基于这些数据，我们也进行了一些思考，例如：构建基于AST和机器学习的自动升级。当我们有10个项目使用基于log4j的内部打包时，我们是否可以直接用类似的方式改进类似的项目，或者生成相应的自动重构CLI。当我们是1000+的团队时，这类工具带来的收益会很可观。
