建站
咨詢
售后
建站咨詢
新聞中心
您是否已在自己手頭的項目中使用到了微服務?在使用的過程中，您是否碰到過一些意料之外的問題?本文將通過分析基于Spring Cloud的微服務系統(tǒng)、jQAssistant和Neo4j，與您討論如何用圖形技術，來實現(xiàn)檢測反模式(antipattern)、可視化全系統(tǒng)、以及跨服務影響分析。
背景介紹
幾年前，我應客戶要求用微服務來重寫他們的IT系統(tǒng)?？墒堑搅碎_發(fā)的末期，我們碰到了代碼缺陷、未能回歸等問題。雖然現(xiàn)場團隊進行了反復審查，也召開了重構會議，但是由于系統(tǒng)相當龐大(生產(chǎn)環(huán)境中的微服務超過了13個)，實在難以調(diào)整，而且收效甚微，因此最終產(chǎn)品的質(zhì)量遠未達到他們的期望。
可見，人們往往會低估從傳統(tǒng)方法轉換為微服務架構的難度，特別是當生產(chǎn)環(huán)境中有成千上萬行代碼時，人們時常無法對目標系統(tǒng)擁有清晰的認識，未能確定待執(zhí)行任務的優(yōu)先級，直到出現(xiàn)問題時已為時已晚。
使用圖形分析來識別問題并修復微服務架構
經(jīng)過研究，我發(fā)現(xiàn)了一個非常實用的工具—jQAssistant。它能夠幫助我將代碼、軟件架構、及其附帶的所有規(guī)則，都轉換成為Neo4j中的圖形。
我發(fā)現(xiàn)圖形的轉換將有助于：檢測反模式，進行影響分析，改善數(shù)據(jù)治理，以及促進團隊之間的溝通等方面。下面，我們將通過分析一個具體應用示例，來詳細討論圖形化轉換的過程。
一個應用示例
在此，我們將使用經(jīng)典的Piggy Metrics項目。它是由Spring Boot和Spring Cloud開發(fā)，基于MongoDB數(shù)據(jù)庫的個人記賬式微服務應用。
該應用程序的圖形轉換相對比較簡單。如上圖所示，我們只需準備構建應用所需的JAR文件，然后通過命令行將JAR文件提供給jQAssistant即可。幾秒鐘之后，您將會獲得對應的簡單圖形。
如上圖代碼段所述，來自Piggy Metrics應用的類–UserController是一個標準的Spring RestController。它定義了兩個名為getUser和createUser的方法。兩者都帶有綠色的@RequestMapping注釋。在這些注釋中，我們可以找到與各個NPC相映射的HTTP動詞。最后則是名為userService的調(diào)用。下圖便是該controller所對應的圖形。
由圖可見，代碼的不同部分會被通過各種節(jié)點與關系來表示。例如：在左側，紅色的節(jié)點表示JAR文件，它通過CONTAINS關系鏈接到藍色UserController類。而UserController類本身會鏈接到getUser和createUser方法，以便進一步調(diào)用其他方法。當然，我們在前面代碼中看到的注釋、請求映射、以及參數(shù)等，都會以綠色顯示在圖形中。據(jù)此，我們將能夠輕松地檢查代碼、類或模塊之間的循環(huán)依賴關系，命名約定的遵循，以及測試是否覆蓋了特定代碼等架構規(guī)則。
松耦合的微服務
許多人認為：松散耦合的微服務是通過HTTP、異步協(xié)議、以及消息協(xié)議進行通信的，而此類通信并不能反映到字節(jié)碼上。我們卻需要在此基礎上使用圖形來表示代碼。也就是說，除了語言和框架，我們還會在應用中通過軟件架構，這一更高層次的概念，來表示API、以及不同的工程實踐。
下面讓我們回到上面的UserController例子。由于采用了Spring框架，因此我們可以遍歷圖形，以使用各種正確的注釋來標識出方法，進而關聯(lián)映射到一些HTTP動詞上。
上圖展示了一個Cypher查詢。通過瀏覽帶有@RequestMapping注解的方法，HTTP信息被輸入到了圖中。端點(Endpoint)作為一個新的概念被引入到了圖中。圖中左側藍色的代碼行，能夠以指令的形式，將endpoint標簽添加到發(fā)現(xiàn)的內(nèi)容中，并將HTTP映射信息，添加到那些作為REST端點被公開的已知方法節(jié)點上。在此，我們定義了一些淺藍色的REST端點。它們能夠與前文提到的getUser和createUser兩種方法，及其不同的路徑相匹配。
參照端點定義的方式，我們還可以定義HTTP客戶端的相關概念。例如：由于Piggy Metrics應用采用了Feign庫在兩項服務之間進行HTTP調(diào)用，因此我們可以使用它來遍歷圖形，并通過查找FeignClient注釋、及其相關信息，來創(chuàng)建新的概念。
就像公開某些REST端點的控制器一樣，我們制作了如上圖所說的HTTP客戶端。它通過HTTP動詞來調(diào)用URL。也就是說，我們可以將帶有URL信息的FeignClient標簽作為新的概念添加到圖形中。
一旦確定了HTTP客戶端和REST端點，我們就可以根據(jù)這些新的概念，輕松地將它們連接到各種匹配的HTTP方法，及其用到的URL上。例如，在如下代碼圖中，我們通過被稱為INVOKES_REMOTE的關系，在圖中展示該過程。
由于服務是松散耦合的，因此，我們可以確定跨服務的依賴關系，讓這些松耦合能夠在圖中變得顯而易見。從下圖可視化的內(nèi)容中，我們能夠清晰地查看到四項服務，以及它們之間的相互調(diào)用。
據(jù)此，我們可以找到其中可能存在的反模式，例如那些導致“雞生蛋、雞生蛋”的服務間循環(huán)問題。當然，我們也可以通過采取影響分析，以確定諸如修改端點的難度等方面的問題。
微服務還是分布式整體?
通過圖表分析，我們也可以查看微服務是否遵循了最佳實踐，進而提高服務實現(xiàn)的成熟度。如下圖例子所示：
數(shù)據(jù)治理
在前面的Piggy Metrics應用中，我們通過MongoDB和Spring Data，不但可以輕松地定義持久性實體的概念，而且能夠檢查跨服務的MongoDB集合的使用情況。下圖展示了我們查詢到的該帳戶集合被兩個不同的服務所調(diào)用的情況。
根據(jù)這兩個服務之間的隔離情況，我們判斷應當合并它們。當然，我們還能夠發(fā)現(xiàn)更多同一個數(shù)據(jù)庫同時在多個位置被管理的情況。據(jù)此，我們也可以定義哪個數(shù)據(jù)存儲庫的更改，會直接或間接地影響到哪些端點。
如上面的數(shù)據(jù)表所示，底部的“UserRepository”被遠程服務間接地使用著。如果想更改它，我們需要檢查遠程服務可能受到的影響。而這些是僅靠查看存儲庫的相關代碼、或單個服務，所無法獲悉的。
通過前文提到的jQAssistant，我們可以針對JDBC去掃描數(shù)據(jù)庫中的元數(shù)據(jù)，并將該數(shù)據(jù)庫的結構映射到圖形中。據(jù)此，我們進而可以對MongoDB采取更高級的影響分析，或針對驗證進行數(shù)據(jù)列級別的分析。也就是說，如果我們想更改某個數(shù)據(jù)庫的數(shù)據(jù)格式、或者是列的長度，那么就需要識別與該列相關的所有對象。
文檔是否最新?
微服務領域的另一個最佳實踐是：事先采用契約優(yōu)先(contract-first)的方法，即：先定義API規(guī)范，然后予以實施。例如，我們可以先選用目前行業(yè)標準化的OpenAPI規(guī)范，然后使用YAML文件來編寫API契約。不過，您可能遇到的問題是：如何知曉自己實施的規(guī)范或文檔是否為最新呢?
如上圖所示，我們可以通過掃描YAML文件，在文件內(nèi)容中找到OpenAPI的相關描述。也就是說，通過遍歷所有的YAML文件，我們查找名為OpenAPI的密鑰，以檢查每個服務是否包含了至少一個規(guī)范文件。而且，這是一種快速檢索文檔缺失的方法。
此外，就文檔本身而言，我們甚至可以進一步深入地了解文檔的具體內(nèi)容。例如，我們既可以從中提取參數(shù)名稱與類型，又可以使用Spring controller執(zhí)行相同的操作，并將兩者的實際檢測差距進行比較。
如下圖所示，通過查詢，我們很快發(fā)現(xiàn)到某項服務缺少對應的文檔。即：在三個端點中，只有兩個端點擁有實際文檔。此外，我們還能深入地“挖掘”API參數(shù)，及其參數(shù)類型。
魯棒性
魯棒性是非常重要的方面，它能夠應對生產(chǎn)環(huán)境中的故障，以免整個系統(tǒng)的崩潰。通常，我們可以采用諸如斷路器(circuit breakers)和響應回退(response fallbacks)之類的主流機制，以避免讓故障影響到上層服務。
為了檢查所有端點、或HTTP客戶端是否已實施了正確的回退，我們可以使用上述簡單的查詢，通過遍歷FeignClient注釋，來查看它們是否具有聲明為fallback的屬性。如上圖所示，在Piggy Metric示例中，我們發(fā)現(xiàn)服務中缺少了兩個fallbacks。
信息共享
為了共享，我們往往需要創(chuàng)建一個可視化的文件。而擁有開放式圖形數(shù)據(jù)庫的優(yōu)勢就在于：您可以有選擇地將圖形導出為GraphML文件，進而采用yEd之類的工具將GraphML文件導出為可視化的數(shù)據(jù)。而且，在yEd中，您可以自定義樣式與布局，以滿足大量元素的實際需求。
如下圖所示，您可以導出許多不同形狀的架構數(shù)據(jù)。作為服務之間依賴關系的簡單示例，我們既可以通過對其進行更改，以提供所需的內(nèi)容，又可以導出為實用的dock可視化。
可見，此類可視化轉換對于開發(fā)者團隊和架構師之間的交流，產(chǎn)品所有者與項目經(jīng)理之間的對話，以及讓他們更好地了解需要完成的工作，都是非常實用的。為了讓您對系統(tǒng)的圖形化有個整體的印象，下圖展示了一個真實的應用示例。
值得一提的是，如果不借助工具，我們很難用手動完成此類圖形的構建。何況我們的系統(tǒng)往往也是動態(tài)發(fā)展的。
更多實用場景
上述示例可能過于簡單。在實際應用中，圖形分析還可以被運用到更多的實際場景中。例如，我們可以通過依賴項分析，更深入地研究安全性問題，進而通過尋找端點上的注釋予以安全加固。此外，我們可以通過導入運行時(runtime)的數(shù)據(jù)，以獲悉某個API每天被調(diào)用的次數(shù)，進而為該API重要性分配權值。當然，我們也可以從版本控制系統(tǒng)中導入數(shù)據(jù)，以便根據(jù)源代碼的依賴性，對修改進行優(yōu)先級排序。顯然，那些被鮮少修改的服務，就意味著它基本能夠正常工作，我們也就不必過于關注了。
總的說來，您可以根據(jù)自己當前的需求與架構，使用基礎的源代碼，來構建能夠反映更高級別概念的圖形。據(jù)此，您可以獲悉有關目標系統(tǒng)的實時最新狀況，檢查它與初始計劃方案的匹配度，進而對實際架構規(guī)則進行及時改進。
分享文章：如何用圖形分析來可視化微服務架構
當前網(wǎng)址：http://www.dlmjj.cn/article/cdjiodh.html
