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

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