【51CTO.com快譯】您是否已在自己手頭的項目中使用到了微服務(wù)?在使用的過程中，您是否碰到過一些意料之外的問題?本文將通過分析基于Spring Cloud的微服務(wù)系統(tǒng)、jQAssistant和Neo4j，與您討論如何用圖形技術(shù)，來實現(xiàn)檢測反模式(antipattern)、可視化全系統(tǒng)、以及跨服務(wù)影響分析。

背景介紹

幾年前，我應(yīng)客戶要求用微服務(wù)來重寫他們的IT系統(tǒng)?？墒堑搅碎_發(fā)的末期，我們碰到了代碼缺陷、未能回歸等問題。雖然現(xiàn)場團隊進行了反復(fù)審查，也召開了重構(gòu)會議，但是由于系統(tǒng)相當(dāng)龐大(生產(chǎn)環(huán)境中的微服務(wù)超過了13個)，實在難以調(diào)整，而且收效甚微，因此最終產(chǎn)品的質(zhì)量遠未達到他們的期望。

可見，人們往往會低估從傳統(tǒng)方法轉(zhuǎn)換為微服務(wù)架構(gòu)的難度，特別是當(dāng)生產(chǎn)環(huán)境中有成千上萬行代碼時，人們時常無法對目標(biāo)系統(tǒng)擁有清晰的認識，未能確定待執(zhí)行任務(wù)的優(yōu)先級，直到出現(xiàn)問題時已為時已晚。

使用圖形分析來識別問題并修復(fù)微服務(wù)架構(gòu)

經(jīng)過研究，我發(fā)現(xiàn)了一個非常實用的工具—jQAssistant。它能夠幫助我將代碼、軟件架構(gòu)、及其附帶的所有規(guī)則，都轉(zhuǎn)換成為Neo4j中的圖形。

我發(fā)現(xiàn)圖形的轉(zhuǎn)換將有助于：檢測反模式，進行影響分析，改善數(shù)據(jù)治理，以及促進團隊之間的溝通等方面。下面，我們將通過分析一個具體應(yīng)用示例，來詳細討論圖形化轉(zhuǎn)換的過程。

一個應(yīng)用示例

在此，我們將使用經(jīng)典的Piggy Metrics項目。它是由Spring Boot和Spring Cloud開發(fā)，基于MongoDB數(shù)據(jù)庫的個人記賬式微服務(wù)應(yīng)用。

該應(yīng)用程序的圖形轉(zhuǎn)換相對比較簡單。如上圖所示，我們只需準(zhǔn)備構(gòu)建應(yīng)用所需的JAR文件，然后通過命令行將JAR文件提供給jQAssistant即可。幾秒鐘之后，您將會獲得對應(yīng)的簡單圖形。

如上圖代碼段所述，來自Piggy Metrics應(yīng)用的類–UserController是一個標(biāo)準(zhǔn)的Spring RestController。它定義了兩個名為getUser和createUser的方法。兩者都帶有綠色的@RequestMapping注釋。在這些注釋中，我們可以找到與各個NPC相映射的HTTP動詞。最后則是名為userService的調(diào)用。下圖便是該controller所對應(yīng)的圖形。

由圖可見，代碼的不同部分會被通過各種節(jié)點與關(guān)系來表示。例如：在左側(cè)，紅色的節(jié)點表示JAR文件，它通過CONTAINS關(guān)系鏈接到藍色UserController類。而UserController類本身會鏈接到getUser和createUser方法，以便進一步調(diào)用其他方法。當(dāng)然，我們在前面代碼中看到的注釋、請求映射、以及參數(shù)等，都會以綠色顯示在圖形中。據(jù)此，我們將能夠輕松地檢查代碼、類或模塊之間的循環(huán)依賴關(guān)系，命名約定的遵循，以及測試是否覆蓋了特定代碼等架構(gòu)規(guī)則。

松耦合的微服務(wù)

許多人認為：松散耦合的微服務(wù)是通過HTTP、異步協(xié)議、以及消息協(xié)議進行通信的，而此類通信并不能反映到字節(jié)碼上。我們卻需要在此基礎(chǔ)上使用圖形來表示代碼。也就是說，除了語言和框架，我們還會在應(yīng)用中通過軟件架構(gòu)，這一更高層次的概念，來表示API、以及不同的工程實踐。

下面讓我們回到上面的UserController例子。由于采用了Spring框架，因此我們可以遍歷圖形，以使用各種正確的注釋來標(biāo)識出方法，進而關(guān)聯(lián)映射到一些HTTP動詞上。

上圖展示了一個Cypher查詢。通過瀏覽帶有@RequestMapping注解的方法，HTTP信息被輸入到了圖中。端點(Endpoint)作為一個新的概念被引入到了圖中。圖中左側(cè)藍色的代碼行，能夠以指令的形式，將endpoint標(biāo)簽添加到發(fā)現(xiàn)的內(nèi)容中，并將HTTP映射信息，添加到那些作為REST端點被公開的已知方法節(jié)點上。在此，我們定義了一些淺藍色的REST端點。它們能夠與前文提到的getUser和createUser兩種方法，及其不同的路徑相匹配。

參照端點定義的方式，我們還可以定義HTTP客戶端的相關(guān)概念。例如：由于Piggy Metrics應(yīng)用采用了Feign庫在兩項服務(wù)之間進行HTTP調(diào)用，因此我們可以使用它來遍歷圖形，并通過查找FeignClient注釋、及其相關(guān)信息，來創(chuàng)建新的概念。

就像公開某些REST端點的控制器一樣，我們制作了如上圖所說的HTTP客戶端。它通過HTTP動詞來調(diào)用URL。也就是說，我們可以將帶有URL信息的FeignClient標(biāo)簽作為新的概念添加到圖形中。

一旦確定了HTTP客戶端和REST端點，我們就可以根據(jù)這些新的概念，輕松地將它們連接到各種匹配的HTTP方法，及其用到的URL上。例如，在如下代碼圖中，我們通過被稱為INVOKES_REMOTE的關(guān)系，在圖中展示該過程。

由于服務(wù)是松散耦合的，因此，我們可以確定跨服務(wù)的依賴關(guān)系，讓這些松耦合能夠在圖中變得顯而易見。從下圖可視化的內(nèi)容中，我們能夠清晰地查看到四項服務(wù)，以及它們之間的相互調(diào)用。

據(jù)此，我們可以找到其中可能存在的反模式，例如那些導(dǎo)致“雞生蛋、雞生蛋”的服務(wù)間循環(huán)問題。當(dāng)然，我們也可以通過采取影響分析，以確定諸如修改端點的難度等方面的問題。

微服務(wù)還是分布式整體?

通過圖表分析，我們也可以查看微服務(wù)是否遵循了最佳實踐，進而提高服務(wù)實現(xiàn)的成熟度。如下圖例子所示：

數(shù)據(jù)治理

在前面的Piggy Metrics應(yīng)用中，我們通過MongoDB和Spring Data，不但可以輕松地定義持久性實體的概念，而且能夠檢查跨服務(wù)的MongoDB集合的使用情況。下圖展示了我們查詢到的該帳戶集合被兩個不同的服務(wù)所調(diào)用的情況。

根據(jù)這兩個服務(wù)之間的隔離情況，我們判斷應(yīng)當(dāng)合并它們。當(dāng)然，我們還能夠發(fā)現(xiàn)更多同一個數(shù)據(jù)庫同時在多個位置被管理的情況。據(jù)此，我們也可以定義哪個數(shù)據(jù)存儲庫的更改，會直接或間接地影響到哪些端點。

如上面的數(shù)據(jù)表所示，底部的“UserRepository”被遠程服務(wù)間接地使用著。如果想更改它，我們需要檢查遠程服務(wù)可能受到的影響。而這些是僅靠查看存儲庫的相關(guān)代碼、或單個服務(wù)，所無法獲悉的。

通過前文提到的jQAssistant，我們可以針對JDBC去掃描數(shù)據(jù)庫中的元數(shù)據(jù)，并將該數(shù)據(jù)庫的結(jié)構(gòu)映射到圖形中。據(jù)此，我們進而可以對MongoDB采取更高級的影響分析，或針對驗證進行數(shù)據(jù)列級別的分析。也就是說，如果我們想更改某個數(shù)據(jù)庫的數(shù)據(jù)格式、或者是列的長度，那么就需要識別與該列相關(guān)的所有對象。

文檔是否最新?

微服務(wù)領(lǐng)域的另一個最佳實踐是：事先采用契約優(yōu)先(contract-first)的方法，即：先定義API規(guī)范，然后予以實施。例如，我們可以先選用目前行業(yè)標(biāo)準(zhǔn)化的OpenAPI規(guī)范，然后使用YAML文件來編寫API契約。不過，您可能遇到的問題是：如何知曉自己實施的規(guī)范或文檔是否為最新呢?

如上圖所示，我們可以通過掃描YAML文件，在文件內(nèi)容中找到OpenAPI的相關(guān)描述。也就是說，通過遍歷所有的YAML文件，我們查找名為OpenAPI的密鑰，以檢查每個服務(wù)是否包含了至少一個規(guī)范文件。而且，這是一種快速檢索文檔缺失的方法。

此外，就文檔本身而言，我們甚至可以進一步深入地了解文檔的具體內(nèi)容。例如，我們既可以從中提取參數(shù)名稱與類型，又可以使用Spring controller執(zhí)行相同的操作，并將兩者的實際檢測差距進行比較。

如下圖所示，通過查詢，我們很快發(fā)現(xiàn)到某項服務(wù)缺少對應(yīng)的文檔。即：在三個端點中，只有兩個端點擁有實際文檔。此外，我們還能深入地“挖掘”API參數(shù)，及其參數(shù)類型。

魯棒性

魯棒性是非常重要的方面，它能夠應(yīng)對生產(chǎn)環(huán)境中的故障，以免整個系統(tǒng)的崩潰。通常，我們可以采用諸如斷路器(circuit breakers)和響應(yīng)回退(response fallbacks)之類的主流機制，以避免讓故障影響到上層服務(wù)。

為了檢查所有端點、或HTTP客戶端是否已實施了正確的回退，我們可以使用上述簡單的查詢，通過遍歷FeignClient注釋，來查看它們是否具有聲明為fallback的屬性。如上圖所示，在Piggy Metric示例中，我們發(fā)現(xiàn)服務(wù)中缺少了兩個fallbacks。

信息共享

為了共享，我們往往需要創(chuàng)建一個可視化的文件。而擁有開放式圖形數(shù)據(jù)庫的優(yōu)勢就在于：您可以有選擇地將圖形導(dǎo)出為GraphML文件，進而采用yEd之類的工具將GraphML文件導(dǎo)出為可視化的數(shù)據(jù)。而且，在yEd中，您可以自定義樣式與布局，以滿足大量元素的實際需求。

如下圖所示，您可以導(dǎo)出許多不同形狀的架構(gòu)數(shù)據(jù)。作為服務(wù)之間依賴關(guān)系的簡單示例，我們既可以通過對其進行更改，以提供所需的內(nèi)容，又可以導(dǎo)出為實用的dock可視化。

可見，此類可視化轉(zhuǎn)換對于開發(fā)者團隊和架構(gòu)師之間的交流，產(chǎn)品所有者與項目經(jīng)理之間的對話，以及讓他們更好地了解需要完成的工作，都是非常實用的。為了讓您對系統(tǒng)的圖形化有個整體的印象，下圖展示了一個真實的應(yīng)用示例。

值得一提的是，如果不借助工具，我們很難用手動完成此類圖形的構(gòu)建。何況我們的系統(tǒng)往往也是動態(tài)發(fā)展的。

更多實用場景

上述示例可能過于簡單。在實際應(yīng)用中，圖形分析還可以被運用到更多的實際場景中。例如，我們可以通過依賴項分析，更深入地研究安全性問題，進而通過尋找端點上的注釋予以安全加固。此外，我們可以通過導(dǎo)入運行時(runtime)的數(shù)據(jù)，以獲悉某個API每天被調(diào)用的次數(shù)，進而為該API重要性分配權(quán)值。當(dāng)然，我們也可以從版本控制系統(tǒng)中導(dǎo)入數(shù)據(jù)，以便根據(jù)源代碼的依賴性，對修改進行優(yōu)先級排序。顯然，那些被鮮少修改的服務(wù)，就意味著它基本能夠正常工作，我們也就不必過于關(guān)注了。

總的說來，您可以根據(jù)自己當(dāng)前的需求與架構(gòu)，使用基礎(chǔ)的源代碼，來構(gòu)建能夠反映更高級別概念的圖形。據(jù)此，您可以獲悉有關(guān)目標(biāo)系統(tǒng)的實時最新狀況，檢查它與初始計劃方案的匹配度，進而對實際架構(gòu)規(guī)則進行及時改進。

原文標(biāo)題：Fixing Your Microservices Architecture Using Graph Analysis，作者: Nicolas Mervaillie

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】