Polaris-Sidecar:更低成本的內網DNS實現

語言: CN / TW / HK

導語

PolarisMesh 是騰訊開源的百萬級服務發現和治理中心,積累了騰訊從虛擬機器到容器時代的分散式服務治理經驗。作為分散式和微服務架構中的核心元件,PolarisMesh 提供服務定址、流量排程、故障容錯和訪問控制等一系列能力,在K8s 和虛擬機器環境中可以無差別使用,支援主流的開發模式,相容grpc、spring cloud和servicemesh等開源生態,幫助使用者快速構建擴充套件性強、可用性高的業務架構,實現從傳統架構到雲原生架構的轉型。

內網定址存在的問題

當某個服務下部署了多個應用程式副本時,一個請求如何傳送給某一副本上進行處理呢?當應用部署於kubernetes時,請求流量先經過Service,再由Service將流量轉發至某一個Pod進行處理;而應用部署在VM或者物理機時,會額外部署一個用於流量轉發的元件,請求將先經過該元件,再由該元件將流量轉發至某一臺機器進行請求處理。

上述請求呼叫的方式,都是將所有的流量通過LVS等四層負載均衡元件進行轉發,即某個服務下的所有服務例項都掛載到一個VIP(Virtual IP)下,所有的請求都先經過此VIP,再由VIP轉發,但是這種方式使用起來會遇到以下幾個明顯的問題:

  • 負載問題 :所有的請求都必須經過這個VIP,VIP的請求轉發壓力會增大,容易引起四層負載元件出現高負載。

  • 效能問題 :請求鏈路中增加了負載均衡元件到業務程序的一跳,使得長尾時延變大;比如filebeat上報ES,ES叢集暴露一個VIP,當filebeat上報資料時,由於每個請求都是大資料包並且均經過VIP,導致長尾時延很大。

  • 成本問題 :需要維護VIP的可用性以及高效能,成本變大;直接在雲上購買VIP產品,產品規格為50Mpbs的話,每月的成本都在¥3000~¥4000左右。

如果要解決VIP所帶來的問題,那麼通用的解決方式,就是去除負載均衡元件到業務程序這一跳的網路請求鏈路,直接將主調方的請求流量傳送至對應業務程序進行處理。 這種思路存在兩種解決 方案。

  1. 侵入式方案 :主動獲取被調方地址。 主調方發起請求前先通過SDK的形式,發起請求前需呼叫SDK的獲取服務地址的方法,在獲取某服務下業務程序的的IP地址資訊後向被調方發起請求。該方案需要將服務發現SDK與業務框架進行整合。

  2. 無侵入式方案 :被動獲取被調方地址。 該方案最典型的就是DNS協議。主調方僅需要記錄被調方的域名資訊,通過DNS的形式,獲取域名下的所有服務地址資訊,隨機選取一個向被調方發起請求。該方案無需將服務發現SDK與業務框架進行整合。

在上文提到的filebeat上報ES、元件Proxy統一接入地址、資料庫主備節點統一接入地址等幾個場景中,由於涉及到開源及第三方元件,這些元件無法通過改造的方式整合註冊中心SDK,因此無法實施侵入式方案,只能通過無侵入式的方案來解決,下面我們看看如何實現無侵入的內網DNS方案。

如何實現無侵入的內網DNS

上述所提到的內網DNS方案,主要有 集中式分散式 兩種實現方式,北極星對這兩種方式均提供支援。下面向 大家分享 前期 北極星 對於這兩種方案的 設計思考

集中式DNS

集中式DNS模式,需要北極星服務端實現DNS協議,然後需要修改業務程序所在環境的/etc/resolv.conf 配置,將北極星服務端所在IP作為第一個 nameserver 地址即可,這樣業務程序所有的DNS請求都將發往北極星服務端,北極星服務端會根據域名解析出對應的服務以及名稱空間,將相關例項地址資訊資料進行DNS回包。

可見,在時間驅動型場景中,相比執行內容而言,業務更關注的任務是定時執行還是週期執行、執行具體時間點準確性、週期頻率的長短等時間因素。

分散式DNS

分散式DNS模式,則是通過在業務程序所在環境執行 polaris-sidecar 程序,然後需要修改業務程序所在環境的/etc/resolv.conf 配置,將 127.0.0.1 所在IP作為第一個 nameserver 地址,這樣業務的DNS請求將全部由polaris-sidecar程序代為處理,polaris-sidecar在將自身快取的服務地址列表進行DNS回包。polaris-sidecar 自身的服務地址資訊快取會定時和北極星服務端進行同步,從而拉取服務的最新例項地址列表。

北極星的選擇:分散式DNS

這裡再給出一個北極星對於集中式DNS與分散式DNS,在能力支援上的對比表格:

功能

集中DNS

分散式DNS

服務發現 支援 支援
服務註冊 不支援 不支援
標籤路由 不支援 支援
就近路由 不支援 支援
故障熔斷 支援 支援
限流 不支援 部分支援
鑑權 不支援 支援

集中式DNS :DNS請求只能攜帶域 名名稱 資訊, 提供的資料資訊非常有限,北極星在此基礎上只能做到服務發現,無法滿足使用者就近路由、分割槽路由等服務治理的需求。

分散式DNS :由於 polaris-sidecar 與業務程序在同一部署環境下,因此可以將一些靜態資訊注入為環境變數,polaris-sidecar 會將這些環境變數資訊作為服務治理所需要的資料,每次處理DNS請求時可以通過這些靜態標籤執行相應的服務治理流程;因此相比集中式DNS服務發現,分散式DNS方案可以享受到更多的北極星服務治理能力。

選型依據 :北極星服務端外掛化的設計,要支援集中式DNS的方案十分便捷,僅需要在北極星服務端接入層中新增一個DNS協議的接入外掛即可。但是北極星定位是一個服務治理中心,因此北極星在支援DNS協議的服務發現基礎之上,同時還希望能將治理能力帶入到DNS協議中,因此,最終北極星採用分散式DNS方案實現內網DNS定址的能力。

後續規劃

  • 協議擴充套件:支援SRV記錄,解決後端多個例項埠號不一致的問題。

  • 能力補齊:支援限流及鑑權能力。

如何使用Polaris