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

关注

原创最新推荐文章于 2026-08-05 16:10:53 发布 159 阅读 AI 写同款· GEO 优化 ›

微服务架构与DDD实践：梁文锋技术管理20关键词精要微服务架构作为现代分布式系统的核心模式，通过将单一应用拆分为多个松耦合服务来实现业务能力的独立部署和扩展。其设计原理遵循单一职责和自治性原则，需要配合服务治理、容错机制等技术保障系统稳定性。领域驱动设计（DDD）则从业务视角出发，通过统一语言和领域模型解决复杂业务系统的设计难题。在技术价值层面，这两种架构方法能够提升团队协作效率、加速产品迭代，并降低系统维护成本。在实际应用场景中，微服务与DDD常结合事件驱动架构，支撑高并发电商平台、金融交易系统等互联网级应用。本文基于梁文锋的四小时深度分享，通过20个核心阅读详情

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

最近，刚好看到两本书名非常有意思的书：《持续 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. 设计指标驱动的架构演进

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

我们也依旧在思考什么才是合理的模型？怎样才能更好地推进整个组织的架构治理？也欢迎在 https://github.com/archguard/archguard 提出你的想法。

小结

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

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

参考资料：

收录于