架構自治服務是一種面向架構分析領域的數據自助服務。它提供了一種集成一體的數據分析方案，讓開發人員、架構師、管理者等可以根據不同任務，自由搭配、組合出適用于自身洞察需求的任務/函數。

最近，剛好看到兩本書名非常有意思的書：《持續 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. 設計指標驅動的架構演進

在《演進式架構》里推薦的適應度函數，依舊是我們推薦的架構治理方式。雖然，書中不會給出明確的定義，但是通過其提供的參考就可以：為每個組織制定適合于自身需求的指標模型。

我們也依舊在思考什么才是合理的模型？怎樣才能更好地推進整個組織的架構治理？

小結

最后，回到 ArchGuard issue（ #93 ） 的問題類似： 做了這么多，怎么證明能起作用？

也因此，基于這些數據，我們還進行了一些思考，打個比方： 基于 AST 與機器學習構建自動升級 。當我們有 10 個項目采用了基于 log4j 的內部封裝，那么，對于相似的項目是不是直接能以相似的方式進行改進，又或者是生成對應的自動重構 CLI。當我們是一個 1000+ 的團隊時，這一類工具帶來的收益就會相當的可觀。