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


參考文件



https://github.com/polarismesh/polaris-sidecar/blob/main/README.md

專案連結




  • polaris-sidecar
    https://github.com/polarismesh/polaris-sidecar

  • polaris-controller
    https://github.com/polarismesh/polaris-controller

學習視訊連結



為了方便大家更好的學習北極星(PolarisMesh)開源專案,我們特別推出了《 北極星PolarisMesh訓練營 系列學習課程,幫助大家更好地瞭解和使用北極星,您可以通過以下連結瞭解課程資訊(視訊課程每週更新1~2個),歡迎大家關注、點贊、轉發:
  • bilibili

    https://www.bilibili.com/video/BV1A34y147tx/

  • 知乎

    https://www.zhihu.com/zvideo/1490462493013667841


往期

推薦


Linux 下一代架構基金會宣佈:聯合騰訊等企業和社群,發力微服務標準化建設

《騰訊雲開源業界首個雲原生標準的一站式微服務管理框架 Femas》

《分散式任務排程:你知道和不知道的事》

《雲原生時代的Java應用優化實踐》

《全面相容Eureka:PolarisMesh(北極星)釋出1.5.0版本》

《全面擁抱Go社群:PolarisMesh全功能對接gRPC-Go | PolarisMesh12月月報》

《SpringBoot應用優雅接入北極星PolarisMesh

《Serverless可觀測性的價值》

《RoP重磅釋出0.2.0版本:架構全新升級,訊息準確性達100%》



掃描下方二維碼關注本公眾號,

瞭解更多微服務、訊息佇列的相關資訊!

解鎖超多鵝廠周邊!


戳原文,檢視更多PolarisMesh的資訊!


點個在看你最好看


本文分享自微信公眾號 - 騰訊雲中間件(gh_6ea1bc2dd5fd)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。