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

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

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

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

Log4j 的跟蹤

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

改變是一種進(jìn)行時(shí)

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

最佳實(shí)踐的局限性

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

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

啟發(fā)于《數(shù)據(jù)自助服務(wù)實(shí)踐指南》，我們便開始探索什么是架構(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ái)說，它是特定領(lǐng)域（即架構(gòu)）的數(shù)據(jù)自助服務(wù)。作為一個(gè)工程師、架構(gòu)師，我們可以基于我們的領(lǐng)域知識(shí)來(lái)打造系統(tǒng)。這種領(lǐng)域知識(shí)，除了來(lái)自于自身的經(jīng)驗(yàn)，還來(lái)自于大量先輩的經(jīng)驗(yàn)：各種書。

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

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

在架構(gòu)演進(jìn)的場(chǎng)景之下， 可以以可 自定義架構(gòu)適應(yīng)度函數(shù)作為自動(dòng)化的目標(biāo)。按不同的自治服務(wù)需求 ，對(duì)應(yīng)有四種對(duì)應(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)域知識(shí)轉(zhuǎn)換模式。將行業(yè)內(nèi)熟知的最佳實(shí)踐知識(shí)，如 SOLID、CUPID 等內(nèi)化到自助服務(wù)中。

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

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

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

架構(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ù)雜的正則來(lái)實(shí)現(xiàn)。

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

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

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

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

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

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

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

簡(jiǎn)單來(lái)說，就是數(shù)據(jù)的整俁。而對(duì)于我們來(lái)說，重點(diǎn)便在于如何構(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 等

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

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

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

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

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

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

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

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

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

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

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

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

小結(jié)

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

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