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

2020 年 3 月 16 日
筆記

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

前言

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

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

1、Dubbo 一類的服務框架，接口即服務。一般以服務名、版本號、分組這樣的三元組作為唯一標識

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

Dubbo 和 SpringCloud 對於服務有不同的定義，主要原因在於二者的註冊發現機制有所差別，Dubbo 以接口為粒度進行服務註冊與發現；SpringCloud 以應用粒度進行服務註冊於發現。

服務框架提供的自動註冊與發現的機制，讓開發者非常的省心，只需要關心對方的服務名即可，而不用關心服務的地址，但如果出現地址找不到，路由出錯或者是想要查看服務註冊信息、服務調用關係時，就有些犯難了，藉助於服務查詢，則可以對這些問題進行基本的定位。

服務查詢開源實現

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

服務查詢主要包括：服務列表查詢、服務詳情查詢、服務提供者列表、服務消費者列表、服務元數據等，下面主要展示服務列表查詢。

Dubbo Admin

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

Dubbo Admin:

https://github.com/apache/dubbo-admin

Dubbo Admin 默認支持 Zookeeper 註冊中心，但理論上可以支持任意註冊中心，只需要引入對應的註冊中心擴展即可。由於 Zookeeper 並不支持模糊查詢的需求，Dubbo Admin 採取了同步的策略，即在 Dubbo Admin 啟動時將所有的註冊信息同步在內存中，所以在服務查詢時，實際是在對內存操作。

同步註冊中心的服務信息並不困難，只需要依賴 dubbo-registry 模塊中對應的註冊中心擴展即可，本質上是把 dubbo-admin 當成了一個普通的 Dubbo 節點，而這個 Dubbo 節點並不提供服務也不消費服務，僅僅負責同步註冊信息，服務變更信息也可以及時同步到 Dubbo Admin。

Naocs 控制台

當選擇 Nacos 作為註冊中心時，可以使用配套的 Nacos 控制台。Nacos 官網提供了一個在線控制台，以讓用戶有一個直觀的體驗：

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

Nacos ：

https://nacos.io/zh-cn/docs/what-is-nacos.html

Nacos 控制台：

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

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 服務治理等等，未來會有更多增強特性，歡迎關注。

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