微服務治理實踐：服務查詢

本文是《微服務治理實踐》系列篇的第二篇文章，為大家介紹如何實作服務查詢。該系列文章基于阿裡雲商業化産品 EDAS 的微服務實踐，如果你的團隊具備較強的微服務治理能力，那麼希望我們在微服務治理方面的實踐和背後的思考，可以為你提供一些參考。

前言

自從微服務架構變得火熱以後，越來越多服務治理相關的名詞被大家所熟知，例如：服務注冊發現、負載均衡、容錯等等，其中有一項能力，可以說是服務治理平台的剛需，卻又很少被大家提及，也是這篇文章即将介紹的内容 -- 服務查詢。

什麼是服務？其實并沒有嚴格的定義，但按照使用不同架構的習慣，我們可以大概歸納如下：

1、Dubbo 一類的服務架構，接口即服務。一般以服務名、版本号、分組這樣的三元組作為唯一辨別

2、SpringCloud 一類的微服務，應用即服務。一般以應用名稱作為唯一辨別

服務查詢開源實作

開源架構對服務查詢的支援主要有 Apache Dubbo 提供的 Dubbo Admin、Nacos 提供的 Nacos 控制台 。首先介紹這兩種開源實作，再介紹 EDAS 對服務查詢的延伸。

服務查詢主要包括：服務清單查詢、服務詳情查詢、服務提供者清單、服務消費者清單、服務中繼資料等，下面主要展示服務清單查詢。

Dubbo Admin

支援 2.7 版本以上的 Dubbo 應用，提供了 Dubbo 基本的服務治理能力，其中就包括了服務查詢。

Dubbo Admin 預設支援 Zookeeper 注冊中心，但理論上可以支援任意注冊中心，隻需要引入對應的注冊中心擴充即可。由于 Zookeeper 并不支援模糊查詢的需求，Dubbo Admin 采取了同步的政策，即在 Dubbo Admin 啟動時将所有的注冊資訊同步在記憶體中，是以在服務查詢時，實際是在對記憶體操作。

同步注冊中心的服務資訊并不困難，隻需要依賴 dubbo-registry 子產品中對應的注冊中心擴充即可，本質上是把 dubbo-admin 當成了一個普通的 Dubbo 節點，而這個 Dubbo 節點并不提供服務也不消費服務，僅僅負責同步注冊資訊，服務變更資訊也可以及時同步到 Dubbo Admin。

Naocs 控制台

當選擇

Nacos

作為注冊中心時，可以使用配套的 [Nacos 控制台](

http://console.nacos.io/nacos/index.html#/login

)。Nacos 官網提供了一個線上控制台，以讓使用者有一個直覺的體驗：

http://console.nacos.io/nacos/index.html

Nacos 控制台的服務查詢是對 Nacos Server 上存儲資料的直接解析，在頁面審查元素中，可以發現其調用了一些 OpenApi，但這部分 OpenApi 并沒有在文檔中開源出來。

開源實作總結

總的來說，服務查詢的開源實作都能夠解決一定程度的問題，但同時也有一些局限性：

• Dubbo Admin 有版本的限制，隻支援 Dubbo 2.7+
• Dubbo Admin 同步了注冊中心中全量的資料，資源消耗大，且由于記憶體限制，無法橫向擴充，實作并不優雅
• Nacos 控制台提供的服務資訊是注冊中心視角的服務，而不是微服務視角的服務，有了解 gap
• Nacos 控制台缺少與微服務治理其他能力的關聯，本質上還是注冊中心的功能
• 開源實作無法滿足混合部署類型微服務的訴求，部分公司可能多種微服務架構并存

EDAS 服務查詢實踐

EDAS 支援 Dubbo、SpringCloud、HSF 三種微服務的部署，在設計微服務治理功能時，一般會考慮多個微服務架構是否相容的問題。我們遇到了一些難點：

• 微服務架構版本多

  Dubbo 支援 2.5.x，2.6.x，2.7.x，SpringCloud 支援 D 以上的版本。

• 注冊中心類型多

  雖然 EDAS 提供了 EDAS 注冊中心替使用者托管了注冊中心，但仍然有一部分使用者習慣使用自建的注冊中心：Zookeeper、Nacos、Eureka。

• 部署形态多

  EDAS 支援 ECS Jar 包部署，同時支援 K8s 鏡像部署，服務治理的實作不能受到部署形态的限制。

• 使用者改造成本

  盡可能降低使用者的遷移成本，一般我們認為使用者零感覺是目标。

• 性能 & 可擴充

  Dubbo Admin 拉取全量資料的模式自然不能被接受，最終方案需要具備可擴充性。

• 雲上服務的限制

  受到使用者協定的限制，EDAS 不能在未經使用者授權的情況下通路其注冊中心，自建注冊中心也應當能夠享受服務治理。

綜上這些難點，我們最終采用了無侵入式的 Agent 方案來對托管微服務應用進行微服務治理。

無侵入方案通過 Agent 技術來實作，通過位元組碼增強技術，運作時對架構代碼進行增強，例如服務建立、服務登出時進行攔截，上報給 EDAS。

基于 Agent 實作服務查詢可以解決之前諸多痛點：

• Dubbo 和 SpringCloud 的多個版本在核心鍊路的改動很小，是以我們花費了少量的代價便覆寫到了所有版本。
• Agent 實作與注冊中心無關，即使注冊中心當機，也可以在 EDAS 控制台查詢到服務。
• ECS Jar 應用啟動時由 EDAS 增加 -javaagent: 啟動參數感覺到微服務 Agent，K8s 容器應用由 EDAS 增加微服務 pilot，不受部署形态限制。
• 使用者無感覺，沒有遷移成本，僅僅隻需要重新開機一次應用
• 服務資訊上報到 EDAS 背景，可以進行加工存儲，不受制于注冊中心的存儲格式限制，可以任意擴充

下面我們在 EDAS 中部署一個 Dubbo 應用，來體驗 EDAS 服務查詢。

建立應用

第一步：選擇 ECS 叢集，Java 運作時環境。

第二步：可以在引導頁面直接選擇，使用官方提供的 Dubbo 服務端應用 Demo 進行部署。

第三步：填寫版本号，确認建立應用。

服務查詢控制台

服務清單頁

服務詳情頁

服務查詢實作細節

EDAS 通過微服務 Agent 攔截服務注冊、服務下線資訊及時上報給 EDAS，是以在正常情況下，服務查詢的延時大概在 1 分鐘以内。另外，還需要考慮服務當機的場景，例如 kill -9 pid 并不會觸發服務下線的邏輯，在注冊中心場景下，服務與注冊中心之間存在長連接配接，以心跳逾時為辨別摘除意外下線的執行個體；在 EDAS Agent 服務查詢場景下同樣存在心跳，意外下線的服務會在 3 分鐘後被摘除。

Agent 上報的資料和使用者注冊中心的資料雖然同源，但處在不同鍊路上，需要對兩者的概念做一些區分：

• 注冊中心存儲的是服務調用過程中實際的服務資訊
• EDAS 存儲的是服務意圖上報的服務資訊

基于上述的了解，服務控制台在大多數情況可以回報出服務真實的情況，但在極少數場景下會存在資料一緻性的問題，服務調用鍊路會以注冊中心中的資料為準，EDAS 控制台不會影響服務調用。

FAQ

問題一 ：Agent 攔截了我的服務，我的應用資料是不是也會洩漏？

答：Agent 僅僅攔截了服務的描述資訊，不會對應用資料進行攔截，已經有很多成熟的産品在做類似的事：例如分布式鍊路跟蹤、應用監控。

問題二：為什麼服務下線了，仍然可以在 EDAS 控制台查詢到服務？

答：下線腳本不優雅、應用當機、K8s Pod 縮容（機率）都有可能導緻控制台感覺不到服務下線，可以在 3 分鐘之後再觀察。

問答三：為什麼通過舊版服務查詢可以查詢到資料，而切換到新版服務查詢沒有資料？

答：隻有在 2020-01-20 之後重新開機過的應用才能在新版服務查詢中查到資料。重新開機過後的應用會自動挂載上最新的 Agent，新版 Agent 才支援新版服務查詢。鑒于部分使用者的應用沒有重新開機過，目前 EDAS 預設采用的是舊版服務查詢，下一個版本中我們将會切換新舊的預設值。

不僅僅是服務查詢

本文介紹了兩款開源産品 Dubbo Admin、Nacos 控制台服務查詢的實作，對他們進行了對比，并引出了 EDAS 服務查詢。服務查詢本身并不是一個特别高大上的能力，但卻是服務治理不可或缺的一個能力。服務查詢還充當了一個服務治理入口的角色，隻有搜出了服務，才能對他們進行後續的治理，可見其基礎性。EDAS 針對很多微服務場景做了增強，例如分布式鍊路跟蹤、金絲雀釋出、離群摘除、Dubbo 服務治理等等，未來會有更多增強特性，歡迎關注。

另外，我們 Dubbo / Spring Cloud 商業化團隊也在招人，除了 EDAS，我們還有 ARMS (應用實時監控服務)、MSE（微服務引擎）、ACM（應用配置管理）、SAE（Serverless 應用引擎）等獨立産品。我們在忙什麼？用心打磨這些産品，就是我們的工作。團隊的目标是将阿裡巴巴在服務治理上的最佳實踐通過産品化的形式輸出給阿裡雲上的企業客戶，幫助客戶實作業務永遠線上。

履歷投遞方式：[email protected]

作者資訊：徐靖峰，花名島風，中間件技術-微服務産品團隊進階研發工程師，負責 Dubbo / Spring Cloud 商業化産品開發相關工作，目前主要關注雲原生、微服務等技術方向。