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

最近，剛好看到兩本書名非常有意思的書：《持續(xù) API 管理》、《數(shù)據(jù)自助服務(wù)實踐指南》，前者書的內(nèi)容對不起大綱，后者書的標(biāo)題對不起內(nèi)容 —— 內(nèi)容是好內(nèi)容，但是標(biāo)題不對。原書的標(biāo)題是《The Self-Service Data Roadmap》，重點在于介紹各種數(shù)據(jù)自助服務(wù)的模式和路線圖。

回到正題上來，這兩本書的書名讓我開始思考兩個問題：1. 如何構(gòu)建持續(xù)的架構(gòu)治理？2. 如何構(gòu)建架構(gòu)的自治服務(wù)呢？只有達到自助 + 持續(xù)性之后，開發(fā)人員才可以實現(xiàn) 架構(gòu)自治 。另外一個方面，從數(shù)據(jù)治理的角度來看，架構(gòu)治理本身也是數(shù)據(jù)。而在數(shù)據(jù)領(lǐng)域，自助服務(wù)已經(jīng)是數(shù)據(jù)民主化的重要趨勢（源自《大數(shù)據(jù)湖最佳實踐》）。這一點可以從流行的 Tableau、Apache Superset 等看到。

為什么我們考慮架構(gòu)自治服務(wù)？

Log4j 的跟蹤

我們從 SourceGraph 的 Insight 工具上獲得了啟發(fā)，在這個工具的 Demo 上，它提供了一個 Log4j 版本的趨勢跟蹤。開發(fā)人員可以通過編寫表達式，諸如于： >= 1.12.0 的方式來進行數(shù)據(jù)統(tǒng)計。于是，我們又一次地迎來了 aha 時刻：這不就是在過去的幾個月里，諸多 ArchGuard 用戶面臨的一類痛點嗎？對于的 IT 大型組織來說，從治理的層面來說，這種跟蹤能提供更高的全局視野。

改變是一種進行時

從一個 “無序” 的狀態(tài)到一個 “有序” 的時期，都需要一個很長的過程。這種緩慢的過程里，每個人或者組織的應(yīng)對方式都是不同的，有的是可視化，有的是通過數(shù)據(jù)。不論采用的是何種方式，它都需要對于進行時的數(shù)字化。

最佳實踐的局限性

技術(shù)專家的日常，總是會向人傳播各種 “最佳實踐”，那并不是人們所需要的。于多數(shù)人而言，他們更想要的是能解決當(dāng)前的問題，需要的是一種最好的實踐。這種實踐可能是代碼上的實踐，分層架構(gòu)上的實踐，邊界劃分上的實踐。除此以外，看上去 “標(biāo)準(zhǔn)化” 的架構(gòu)度量模型，往往很難以在多數(shù)大型組織上適用。

什么是架構(gòu)自治服務(wù)？

啟發(fā)于《數(shù)據(jù)自助服務(wù)實踐指南》，我們便開始探索什么是架構(gòu)自治服務(wù)務(wù)。我們稱架構(gòu)治理類型的數(shù)據(jù)自助服務(wù)，稱為架構(gòu)自治服務(wù)：

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

從本質(zhì)上來說，它是特定領(lǐng)域（即架構(gòu)）的數(shù)據(jù)自助服務(wù)。作為一個工程師、架構(gòu)師，我們可以基于我們的領(lǐng)域知識來打造系統(tǒng)。這種領(lǐng)域知識，除了來自于自身的經(jīng)驗，還來自于大量先輩的經(jīng)驗：各種書。

根據(jù)這樣的思想，我們制定了一個在不同階段中，ArchGuard 應(yīng)該處于怎樣的狀態(tài)，即架構(gòu)自治服務(wù)的路線圖。

架構(gòu)自治服務(wù)路線圖

在架構(gòu)演進的場景之下， 可以以可 自定義架構(gòu)適應(yīng)度函數(shù)作為自動化的目標(biāo)。按不同的自治服務(wù)需求 ，對應(yīng)有四種對應(yīng)的模式（由低到高）：

探索性數(shù)據(jù)分析模式。關(guān)注理解和總結(jié)架構(gòu)治理所需的數(shù)據(jù)集，以確定所需的數(shù)據(jù)整理轉(zhuǎn)換，諸如數(shù)據(jù)結(jié)構(gòu)、內(nèi)容、關(guān)系是否正確？

領(lǐng)域知識轉(zhuǎn)換模式。將行業(yè)內(nèi)熟知的最佳實踐知識，如 SOLID、CUPID 等內(nèi)化到自助服務(wù)中。

分析轉(zhuǎn)換模式。結(jié)合架構(gòu)關(guān)注點與可視化分析，通過交互式的方式來整理數(shù)據(jù)，并轉(zhuǎn)換到流程中，如對于 Log4j 的整改跟蹤。

操作洞察模式。從多層指標(biāo)出發(fā)，為數(shù)據(jù)用戶提供一組豐富的可操作集合，它們之間是相互關(guān)聯(lián)的，如架構(gòu)適度度函數(shù)。

從抽象模式上來說，它是結(jié)合了領(lǐng)域知識所構(gòu)建出來的數(shù)據(jù)自助服務(wù)，更多的是集中于 數(shù)據(jù)轉(zhuǎn)換 + 數(shù)據(jù)搜索 的兩個核心中。

架構(gòu)自治服務(wù)的示例

還記得開頭提到的 SourceGraph 嗎，它提供了一種靈活的數(shù)據(jù)洞見服務(wù)。采用如下的方式，就可以跟蹤系統(tǒng)的 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 更多的是基于正則分析的，所以需要通過復(fù)雜的正則來實現(xiàn)。

在 ArchGuard 是基于 AST + 模型分析的，所以需要基于字段（field）進行過濾：

field:name == /.*log4j/ field:version > 2.17.0

為了提供更好的自助服務(wù)，我們需要在平穩(wěn)靈活性與實用性。在這種情況下，基于正則顯然能提供了更強的靈活性。

于是乎，我們便能跟蹤起整個組織的 Log4j 的治理情況。

如何實現(xiàn)架構(gòu)架構(gòu)自治服務(wù)？

從 ArchGuard 的試驗，以及我們在數(shù)據(jù)上的一些經(jīng)驗，實現(xiàn)這樣一架構(gòu)自治服務(wù)可以分為四步：

1. 構(gòu)建架構(gòu)治理的數(shù)據(jù)底座
2. 抽象數(shù)據(jù)服務(wù)的接口
3. 揉和 BI 的自助交互分析
4. 設(shè)計指標(biāo)驅(qū)動的架構(gòu)演進。諸如于設(shè)計合理的適應(yīng)度函數(shù)

簡單來說，就是數(shù)據(jù)的整俁。而對于我們來說，重點便在于如何構(gòu)建這樣的數(shù)據(jù)底座。

1. 構(gòu)建架構(gòu)治理的數(shù)據(jù)底座

大量的組織內(nèi)現(xiàn)有的一系列架構(gòu)（廣義上的架構(gòu)）管理相關(guān)的工具：

• 代碼質(zhì)量控制：SonarQube（部分功能） 、ArchUnit、Jacoco、CheckStyle 等
• SCA （軟件成分分析）分析：JFrog Xray、Black Duck 等
• 漏洞掃描工具：OpenVAS 等。
• API 管理：Swagger 等

諸如此類的工具也非常之多，只是呢，很多我也不懂。針對于這一系列的工具，需要進行數(shù)據(jù)上的打通，以提供一個 “聯(lián)接共享” 的數(shù)據(jù)底座。

于是乎，為了達到數(shù)據(jù)上的自助能力，我們就需要構(gòu)建 數(shù)據(jù)底座 作為基礎(chǔ)設(shè)施。當(dāng)然了，在 ArchGuard 里，我們對于這點做得并不好。

2. 抽象數(shù)據(jù)服務(wù)的接口

從定義上來說，對于架構(gòu)治理，圍繞于 ETL + 數(shù)據(jù)自治服務(wù)，我們可以關(guān)注于：

• 數(shù)據(jù)整理服務(wù)。它包含了方方面面的元數(shù)據(jù)處理，諸如于模型與接入標(biāo)準(zhǔn)化：在 Chapi 底層對于不同語言的數(shù)據(jù)模型進行抽象，又或者是在 Scanner 底層對于依賴進行抽象。
• 數(shù)據(jù)轉(zhuǎn)換服務(wù)。讓開發(fā)人員可以在數(shù)據(jù)處理的過程中，添加一些特定的業(yè)務(wù)邏輯。
• 數(shù)據(jù)搜索服務(wù)。如何簡化數(shù)據(jù)的發(fā)現(xiàn)過程，使用關(guān)鍵字、通配符等，并降低處理所需要的耗時。

在整理、轉(zhuǎn)換、搜索三個階段里，我們都要構(gòu)建大量的抽象，才能提供數(shù)據(jù)上的自助服務(wù)。在整理上可以模型來抽象，在轉(zhuǎn)換上通過插件化接口來抽象，在搜索上通過 DSL 來進行抽象。

3. 揉和 BI 的自助交互分析

在簡單的場景里，我們應(yīng)該使用現(xiàn)有的 BI （Business Intelligence， 商業(yè)智能）工具進行分析。它的前提是，組織內(nèi)部已經(jīng)有了成熟的數(shù)據(jù)體系。如果沒有的話，那么我們就要思考著如何達到這樣的能力？如何構(gòu)建這種架構(gòu)上的數(shù)字孿生？

但是，不論如何，構(gòu)建一個支持自助交互分析的工具也難。

4. 設(shè)計指標(biāo)驅(qū)動的架構(gòu)演進

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

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

小結(jié)

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

也因此，基于這些數(shù)據(jù)，我們還進行了一些思考，打個比方： 基于 AST 與機器學(xué)習(xí)構(gòu)建自動升級 。當(dāng)我們有 10 個項目采用了基于 log4j 的內(nèi)部封裝，那么，對于相似的項目是不是直接能以相似的方式進行改進，又或者是生成對應(yīng)的自動重構(gòu) CLI。當(dāng)我們是一個 1000+ 的團隊時，這一類工具帶來的收益就會相當(dāng)?shù)目捎^。