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

目前，微服務架構已經成為企業尤其是網際網路企業技術選型的一個重要參考。微服務架構中涉及到很多子產品，本文将重點介紹微服務架構的服務注冊與發現以及如何基于DNS做服務發現。最後，簡單介紹下阿裡巴巴内部是如何基于DNS做服務發現的。

服務發現互動協定

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

“私有”協定

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

DNS協定為基礎的服務發現

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的服務發現方式，大緻可以歸結兩類：

獨立DNS伺服器

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

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

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

• 優點
  1. 集中的DNS伺服器，便于更新維護
• 缺點
  1. 對DNS伺服器性能要求高
  2. 這種情況下一般需要LVS裝置為DNS伺服器叢集做請求轉發，存在單點問題

DNS Filter

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

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

阿裡基于DNS的服務發現實踐

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

注冊中心 VIPServer

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

• 主動與被動健康檢查

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

• 多種負載均衡政策

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

• 多重容災保護政策

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

  1. 用戶端緩存，即使VIPServer服務端挂掉也不影響應用的正常調用；
  2. 服務端保護門檻值，有效防止應用因壓力過大而發生雪崩；
  3. 用戶端容災目錄，提供人工幹預服務IP清單的能力；
  4. 用戶端空清單保護，有效防止人為誤删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系統解析；

阿裡雲上的VIPServer服務及開源計劃

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

Spring Cloud 接入 EDAS 之服務發現篇

。

總結

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