微服務作為雲原生時代下一種開發軟體的架構和組織方法，通過將明確定義的功能分成更小的服務，並讓每個服務獨立迭代，增加了應用程式的靈活性，允許開發者根據需要更輕鬆地更改部分應用程式。同時每個微服務可以由單獨的團隊進行管理，使用適當的語言編寫，並根據需要進行獨立擴縮容。但微服務同樣也並非“銀彈”，在帶來如... ...
微服務作為雲原生時代下一種開發軟體的架構和組織方法，通過將明確定義的功能分成更小的服務，並讓每個服務獨立迭代，增加了應用程式的靈活性，允許開發者根據需要更輕鬆地更改部分應用程式。同時每個微服務可以由單獨的團隊進行管理，使用適當的語言編寫，並根據需要進行獨立擴縮容。但微服務同樣也並非“銀彈”，在帶來如此多的優勢的同時，逐漸膨脹的微服務數量也為系統帶來了空前的複雜度，服務之間錯綜複雜的調用、協作關係如同一層迷霧籠罩在系統之上，藉助 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
