微服務架構中基於DNS的服務發現

服務發現交互協議

微服務架構中，服務註冊與發現的通信協議大致可以分為兩類：一類是「私有」協議，如dubbo + zk及eureka；另一類是通用的DNS協議，如k8s + coredns。

「私有」協議具有很高的定製性，可以和具體產品一起實現更高級的功能，如zk + dubbo，可以支持推送和長連接。但是，「私有」協議也帶來了另外一個問題，就是開放性很差，第三方接入需要使用特定的SDK，跨語言特性不好。而在微服務或雲環境下，跨語言服務註冊和發現是非常常見的一個場景。

DNS協議是一個「古老」的協議，也是最基本、最通用的協議之一。基於DNS協議的服務發現具備非常好的通用性，幾乎所有語言都可以無縫接入。與「私有」協議的服務發現相比，基於DNS協議的服務發現還有一些問題需要解決，如埠問題、語言框架的緩存問題。這些問題已經有了對應的解決方案，將在後續文章中向大家介紹，本文重點放在基於DNS的服務發現的大概玩法。

微服務體系中，服務註冊與服務發現是兩個最核心的模塊。服務A調用服務B時，需要通過服務發現模塊找到服務B的IP和埠列表，而服務B的實例在啟動時需要把提供服務的IP和埠註冊到服務註冊中心。一個典型的結構如下圖：

目前，流行的註冊中心比較多，常見的有zookeeper、ectd、consul、eureka等。服務註冊通常有三種：自註冊、第三方註冊、註冊中心主動同步。

自註冊

自註冊，顧名思義，就是服務提供方在啟動服務時自己把提供服務的IP和埠發送到註冊中心，並通過心跳方式維持健康狀態；服務下線時，自己把相應的數據刪除。典型的像使用eureka客戶端發布微服務。

第三方註冊

第三方註冊是指，存在一個第三方的系統負責在服務啟動或停止時向註冊中心增加或刪除服務數據。典型的用法是devops系統或容器調度系統主動調註冊中心介面註冊服務；

註冊中心主動同步

與第三方註冊方式類似，主動註冊方式是指註冊中心和調度或發布系統打通，主動同步最新的服務IP列表；一個例子是kubernetes體系中，coredns訂閱api server數據。

在真正發起服務調用前，調用方需要從註冊中心拿到相應服務可用的IP和埠列表，即服務發現。服務發現從對應用的侵入性上可以分為兩大類：

SDK-Based

這類的服務發現方式，需要調用方依賴相應的SDK，顯式調用SDK代碼才可以實現服務調用，即對業務有侵入性，典型例子如eureka、zookeeper等。

DNS-Based

DNS本身是一種域名解析系統，可以滿足簡單的服務發現場景，如雙方約定好埠、序列化協議等等。但是，這遠遠不能滿足真正的微服務場景需求。近幾年，基於DNS的服務發現漸漸被業界提了出來。後面將重點介紹基於DNS的服務發現及阿里巴巴的實踐。

DNS協議是目前最為通用的協議之一，幾乎所有操作系統都會有DNS客戶端實現。所以，其天然具有跨語言特性。這也是快速接入微服務體系最快的一個方式。要基於DNS做服務發現，首先註冊中心的數據應該可以以DNS的數據格式暴露出來，讓任何系統的DNS 客戶端都可以通過DNS協議獲取服務列表。

基於DNS的服務發現方式，大致可以歸結兩類：

獨立DNS Server模式的基本架構如下圖：

如上圖所示，這種架構中，需要獨立的DNS伺服器。DNS伺服器從註冊中心獲取所有已註冊的服務及對應的IP埠列表。調用方Service A 通過DNS查詢某個服務下的IP列表，然後發起調用。

這種類型的服務發現方式優缺點分別如下：

優點

集中的DNS伺服器，便於升級維護

缺點

對DNS伺服器性能要求高

這種情況下一般需要LVS設備為DNS伺服器集群做請求轉發，存在單點問題

DNS Filter模式我們定義為把DNS伺服器集成到服務調用方機器或容器里，如下圖所示：

這種模式中，首先要保證ServiceA的DNS查詢都被攔截到本機的DNS伺服器上（127.0.0.1:53），在獲取到服務的IP列表後發起調用。由於這種方式把DNS伺服器前置到實際調用的機器上，所以它解決了獨立DNS伺服器模式的單點問題，完全P2P的模式。但由於需要在應用機器上安裝DNS伺服器，其維護和升級成本較前者高一些。

阿里巴巴早在2013年就開始了基於DNS做服務發現的嘗試了，現在已經形成了較為成熟的模式。是業界比較早開始這方面的探索的公司，公開資料顯示比SkyDNS（CoreDNS前身）要早幾個月時間。阿里內部以VIPServer作為註冊中心，並開發了DNS Filter，部署在應用容器內。目前已經有超過20w個機器或容器上安裝了DNS Filter，支持了幾乎所有REST服務發現。

註冊中心 VIPServer

VIPServer是阿里中間件軟負載團隊自研的服務註冊中心，按照第一章的分類，VIPServer同時支持三種模式的服務註冊，並且均有相當規模的應用。除此之外，VIPServer具備如下特性：

主動與被動健康檢查

VIPServer同時支持主動與被動健康檢查。主動健康檢查是指VIPserver服務端主動定期發送健康檢查探測包，探測服務提供方是否可以正常提供服務。用戶可以配置多種健康檢查方式，自定義探測埠和探測URL（HTTP）。主動探測的好處在於服務提供方不用做任何改動即可快融入微服務架構。被動健康檢查則是指服務提供方主動註冊自己的IP、埠和服務名等信息，並通過心跳方式保持活性。

多種負載均衡策略

同時，VIPServer支持多種負載均衡策略，包括權重、同機房、同地域、同環境等等，是阿里異地多活項目的核心系統之一。後面會有專門的文章介紹如何基於VIPServer實現異地多活，這裡不再贅述。

多重容災保護策略

VIPServer提供了多種容災保護策略，可以有效減少人為或者底層系統（網路等）異常帶來的影響。這些容災保護包括：

客戶端緩存，即使VIPServer服務端掛掉也不影響應用的正常調用；

服務端保護閾值，有效防止應用因壓力過大而發生雪崩；

客戶端容災目錄，提供人工干預服務IP列表的能力；

客戶端空列表保護，有效防止人為誤刪IP列表操作或VIPServer服務端異常；

DNS-F客戶端

出於性能的考慮，我們採用了第二種DNS Filter的服務發現模式。為此，我們單獨開發了DNS-F客戶端，DNS-F客戶端跟應用部署在同一個主機或容器內。其工作原理如下圖所示：

首先，應用ServiceA通過DNS查詢獲取到ServiceB的可用IP列表；

DNS-F會攔截到ServiceA的查詢請求，判斷自己是否該查詢的答案，如果有（服務已在VIPServer中註冊）則直接返回IP列表；

如果查詢的服務在VIPServer中沒有註冊，DNS-F把DNS查詢轉發給系統的nameserver，由真正的DNS系統解析；

在阿里雲上，我們正在將我們在DNS-Based Service Discovery上的功能及實踐經驗在Aliware的企業級應用服務(EDAS)產品上逐漸開放。我們也正在規劃將VIPServer的核心能力在一個新的開源項目(nacos)里回饋給開源社區，期待跟大家一起在未來探索服務發現領域。如果您想體驗阿里巴巴微服務解決方案，可以到阿里雲上開通EDAS服務，免費體驗。相關鏈接：Spring Cloud 接入 EDAS 之服務發現篇。

本文介紹了微服務架構中如何基於DNS做服務發現。首先，介紹了服務法註冊與發現的概念、服務註冊與發現的幾種方式及其優缺點；然後，介紹基於DNS的服務發現的兩種方式及其優缺點；最後，介紹了阿里巴巴基於DNS做服務發現的實踐，主要是基於自研的軟負載系統VIPServer。基於DNS的服務發現要解決的問題遠不止本文描述的這些，敬請期待後續系列文章

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！