微服務洞察，讓微服務更透明

微服務作為云原生時代下一種開發軟體的架構和組織方法，通過將明確定義的功能分成更小的服務，并讓每個服務獨立迭代，增加了應用程式的靈活性，允許開發者根據需要更輕松地更改部分應用程式，同時每個微服務可以由單獨的團隊進行管理，使用適當的語言撰寫，并根據需要進行獨立擴縮容，但微服務同樣也并非“銀彈”，在帶來如此多的優勢的同時，逐漸膨脹的微服務數量也為系統帶來了空前的復雜度，服務之間錯綜復雜的呼叫、協作關系如同一層迷霧籠罩在系統之上，借助 Trace、Log、Metric 三駕馬車我們的系統具備了一定的可觀測性，但所能得到資訊是標準化且固定的，往往不能夠滿足復雜場景下的觀測需求，比如微服務引擎 MSE（Microservices Engine）中的微服務治理功能模塊為用戶用好微服務提供了諸多幫助，但其中的很多功能，比如全鏈路灰度、無損上下線等會涉及多個應用，且所涉及的資訊又不被標準的可觀測系統覆寫，而微服務洞察通過動態的資訊采集能夠填補這其中的一部分空缺，更好地滿足這些微服務場景的觀測需求，同時也將他們納入到標準的觀測體系中來，

微服務洞察

設想這樣一個問題現場，線上系統出現了一個奇怪的問題，某一個介面偶現錯誤，頻率不高，出現時間毫無規律，但是沒有發現任何有效的錯誤日志，這時，在通常的實踐中，除非具備腦內 debug 的神力，不然我們往往需要在代碼中增加日志邏輯，然后重啟應用，靜靜等待問題復現后查詢日志，如果定位了問題范圍需要更多的資訊，就需要我們不斷回圈 撰寫日志邏輯->重啟應用->靜靜等待 的步驟直到解決 bug，但這還不是最令人頭疼的，如果給這個問題加上問題觸發伴隨應用重啟、pod 內日志丟失、重啟后問題無法復現等 debuff，排查的難度將會進一步上升，

而由于微服務洞察具備任意位置類粒度的動態資訊采集的核心能力，能夠幫助我們解決上述場景中的一些痛點，首先在第一次發現這個問題后，我們可以直接在線上環境中通過配置一條微服務洞察的規則，來收集一些初步資訊來幫助我們判斷可能的問題原因，由于收集的資訊會以呼叫鏈的形式組織，我們可以從中獲取問題出現的頻率、時間、引數分布、上下游呼叫資訊等，同時由于資訊會直接上報并集中存盤到遠端系統，因此不受應用重啟的影響，我們也不需要一臺一臺實體去查詢日志，

在對問題有了初步的判斷之后，我們往往能夠將問題定位到一個范圍之內，這時我們可以進一步鎖定某些方法，通過配置規則，列印它們的入參、回傳值、呼叫堆疊等資訊來判斷其執行是否符合預期，

通過上述的舉例可以發現，借助微服務洞察的能力，我們能夠輕松地探知標準的可觀測系統難以觸達的角落，從而滿足我們對一些微服務場景的觀測需求，

洞察微服務場景

無損下線

無損下線是微服務治理中的一個功能，主要是為了解決在發布程序中的微服務在下線的程序中可能存在的流量損失，其大致流程如下圖所示，

通過一系列的策略和措施，能夠做到服務的完全無損下線，但這樣就導致無損下線的流程比較復雜，同時還涉及到多個節點之間的通知機制，特別是在大規模之下，下線流程的完整性以及可靠性的確認變得非常復雜與繁瑣，這就是前文所提到的難以觸達的角落，我們可以通過微服務洞察的能力幫助我們觀測這個場景，

針對無損下線的場景，微服務洞察提供了場景化的規則，簡單配置一鍵開啟，

在開啟了規則之后，微服務洞察會收集無損下線流程中值得關心的資訊，組織成呼叫鏈的形式展示，如下圖場景，我們對 108 節點進行縮容操作，我們就可以得到一條 Tracing 鏈路，其中包含主動通知、服務注銷、應用停止等幾個步驟，并且我們可以在每個步驟中看到所需的資訊，

在主動通知環節我們可以看到當前 Provider 節點對哪些 Consumer 進行 GoAway 請求的呼叫，如下圖所示我們將主動通知 10.0.0.90、10.0.0.176 兩個 Consumer 節點，

當 Consumer 收到 GoAway 呼叫后，會進行負載均衡串列的重繪以及路由的隔離，我們將在負載均衡地址串列中顯示最新抓到的當前 Consumer 對于當前服務快取的最新地址串列，我們可以在下圖中看到，地址串列中只剩下 10.0.0.204 這個服務提供者節點的呼叫地址，

我們也可以看到 Spring Cloud 向 Nacos（注冊中心）執行服務下線的呼叫結果，注銷成功，

微服務洞察通過將無損下線的 workflow 抽象成 Tracing 結構的策略，可以幫助我們降低大規模場景、復雜鏈路下無損下線問題的排查成本，

全鏈路灰度

全鏈路灰度是微服務治理中的另一個功能，有時某個功能發版依賴多個服務同時升級上線，我們希望可以對這些服務的新版本同時進行小流量灰度驗證，這就是微服務架構中特有的全鏈路灰度場景，通過構建從網關到整個后端服務的環境隔離來對多個不同版本的服務進行灰度驗證，在發布程序中，我們只需部署服務的灰度版本，流量在呼叫鏈路上流轉時，由流經的網關、各個中間件以及各個微服務來識別灰度流量，并動態轉發至對應服務的灰度版本，如下圖：

而在使用該能力的時候，要想探清流量的匹配情況以及流量的走向具有較大的難度，而借助微服務洞察的能力可以幫助我們便捷地感知這些資訊，

這部分的示例將基于 A、B、C 三個應用，其中 A、B 應用分別部署一個基線版本和一個灰度版本，其內部存在 /a -> /b -> /c 的呼叫鏈路，

我們只需要配置如下的規則可以看到流量的路徑，以及實體和流量的標簽資訊，

從所展示的資訊中可以看到，灰度流量正確地流經了灰度實體而不是非灰度實體（其中 mse.app.tag 是應用的標簽，mse.tag 是流量的標簽）

全鏈路灰度支持按照 headers 中的資訊來匹配灰度流量，因此我們也在上一條規則的基礎上，增加如下的規則來觀測灰度流量的 headers 資訊，來幫助我們判斷流量匹配是否符合預期，

開啟規則后，對于 /a -> /b -> /c 鏈路中的帶有 gray 全鏈路灰度標簽的流量，會在采集上一條規則所定義的資訊的基礎上，同時采集 Headers 資訊，在鏈路展示頁面詳情展示如下：

借助微服務洞察的能力，我們只需要簡單的規則配置，就可以完成對復雜的全鏈路灰度場景的觀測，讓我們在使用全鏈路灰度時不再提心吊膽，

參考的框架/組件內部

微服務架構下的開發往往會使用很多框架或是中間件，這些框架和中間件的內部無法添加日志邏輯，因此在使用時對開發者來說時黑盒的，極大地增加了觀測的難度，而借助微服務洞察，任意位置都只需要通過配置規則的方式就可以獲取到現場資訊，接下來以負載均衡和 Nacos 為例，

Nacos

Nacos 借用官網的描述，致力于幫助您發現、配置和管理微服務，Nacos 提供了一組簡單易用的特性集，幫助您快速實作動態服務發現、服務配置、服務元資料及流量管理，處于微服務架構中的關鍵位置，但是目前在可觀測方面 Nacos 服務端能夠獲取一些資訊，但是客戶端則成了黑暗的角落，開發者也不能隨意地添加日志資訊，想要關注其中的資訊難上加難，而在微服務洞察的幫助下，通過簡單的規則配置，就可以獲取到客戶端內部的資訊，來補全這部分的觀測需求，

我們以服務變更回呼的方法以及收取訂閱服務內容的方法為例，前者會在所訂閱的服務發生變更時被觸發，后者會在收到訂閱的服務內容時被觸發，通過關注這兩個方法的入參，我們便可以獲取到此時服務的詳細資訊，

負載均衡

以 Spring Cloud 常用的客戶端負載均衡組件 Ribbon 作為示例，Ribbon 位于客戶端一側，通過服務注冊中心（本文中為 Nacos）獲取到一份服務端提供的可用服務串列，隨后，在客戶端發送請求時通過負載均衡演算法選擇一個服務端實體再進行訪問，以達到負載均衡的目的，通過分析代碼可以發現，Ribbon 內部的 updateZoneServerMapping 方法的引數 Map<String, List<Server>> map 基本等同于每次更新動作最后所更新的可用服務串列，我們只需要配置一條規則來獲取這個方法的入參就可以獲取到當時真實的可用服務串列資訊，

小節

本文以一個假象的場景出發，介紹了微服務引擎 MSE（Microservices Engine）微服務治理功能模塊中微服務洞察功能的應用場景和簡單的使用介紹，借助微服務洞察，我們可以便捷地觀測到一些不被標準可觀測系統覆寫的角落，在提供任意位置類粒度的動態資訊采集這一核心能力的同時，我們也會結合微服務開發者們的微服務開發運維經驗，不斷去探索更多有價值的微服務場景，在核心能力的基礎上以更加貼近場景的方式收集并采集資訊，旨在幫助我們更好地治理我們的微服務應用，助力于云上幫助企業構建完整的微服務體系，歡迎大家嘗鮮與體驗～

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Insight-into-microservices-to-make-microservices-more-transparent.html

標籤：架構設計

上一篇：Java工廠模式的最佳實踐？

下一篇：微服務洞察，讓微服務更透明