Blog

Blog

PHODAL

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

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

最近,刚好看到两本书名非常有意思的书:《持续 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 的试验,以及我们在数据上的一些经验,实现这样一架构自治服务可以分为四步:

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

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

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+ 的团队时,这一类工具带来的收益就会相当的可观。

参考资料:

  • 《大数据湖最佳实践》
  • 《数据自治服务实践指南》
  • 《持续 API 管理》
  • 《演进式架构》

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

标签