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

背景介紹

幾年前，我應客戶要求用微服務來重寫他們的IT系統。可是到了開發的末期，我們碰到了代碼缺陷、未能回歸等問題。雖然現場團隊進行了反復審查，也召開了重構會議，但是由于系統相當龐大(生產環境中的微服務超過了13個)，實在難以調整，而且收效甚微，因此最終產品的質量遠未達到他們的期望。

可見，人們往往會低估從傳統方法轉換為微服務架構的難度，特別是當生產環境中有成千上萬行代碼時，人們時常無法對目標系統擁有清晰的認識，未能確定待執行任務的優先級，直到出現問題時已為時已晚。

使用圖形分析來識別問題并修復微服務架構

經過研究，我發現了一個非常實用的工具—jQAssistant。它能夠幫助我將代碼、軟件架構、及其附帶的所有規則，都轉換成為Neo4j中的圖形。

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

一個應用示例

在此，我們將使用經典的Piggy Metrics項目。它是由Spring Boot和Spring Cloud開發，基于MongoDB數據庫的個人記賬式微服務應用。

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

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

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

松耦合的微服務

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

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

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

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

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

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

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

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

微服務還是分布式整體?

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

數據治理

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

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

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

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

文檔是否最新?

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

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

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

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

魯棒性

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

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

信息共享

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

如下圖所示，您可以導出許多不同形狀的架構數據。作為服務之間依賴關系的簡單示例，我們既可以通過對其進行更改，以提供所需的內容，又可以導出為實用的dock可視化。

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

值得一提的是，如果不借助工具，我們很難用手動完成此類圖形的構建。何況我們的系統往往也是動態發展的。

更多實用場景

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

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

原文標題：Fixing Your Microservices Architecture Using Graph Analysis，作者: Nicolas Mervaillie

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