隨著容器化的流行，越來越多的項目采取了容器化方案來設計架構、實施部署。

作為時序數(shù)據(jù)引擎核心的TDengine Database，在部署時一般建議采用FQDN(Fully Qualified Domain Name，完全限定域名)來進行節(jié)點之間的通信。很多客戶在進行容器化架構設計時，通信方式均采用IP地址尋址，而且由于這些容器的IP、容器名(也就是hostname)會隨著容器的生命周期變化而變化，這就給TDengine采用hostname作為FQDN尋址進行通信帶來了困難。

本文將結合實際，嘗試給出一最佳實踐建議，以實現(xiàn)以下兩個需求：

• TDengine集群節(jié)點采用IP地址尋址
• 應用端無需配置集群節(jié)點IP/FQDN地址，而僅采用LoadBalancer域名作為firstEP實現(xiàn)集群尋址

假設TDengine集群由兩個節(jié)點組成，IP分別為172.16.31.1和172.16.31.2。

在深入之前，希望讀者先對TDengine的整體架構有所了解，可以參考：https://tdengine.com/docs/cn/v2.0/architecture#cluster。

我們再來強調(diào)TDengine Database中的幾個概念：

• 物理節(jié)點(pnode): pnode是一獨立運行、擁有自己的計算、存儲和網(wǎng)絡能力的計算機，可以是安裝有OS的物理機、虛擬機或Docker容器。物理節(jié)點由其配置的 FQDN來標識。
• 數(shù)據(jù)節(jié)點(dnode): dnode 是 TDengine 服務器側執(zhí)行代碼 taosd 在物理節(jié)點上的一個運行實例，一個工作的系統(tǒng)必須有至少一個數(shù)據(jù)節(jié)點。dnode包含零到多個邏輯的虛擬節(jié)點(VNODE)，零或者至多一個邏輯的管理節(jié)點(mnode)。dnode在系統(tǒng)中的唯一標識由實例的End Point (EP )決定。EP是dnode所在物理節(jié)點的FQDN和系統(tǒng)所配置的網(wǎng)絡端口號(Port)的組合。
• 管理節(jié)點(mnode): 一個虛擬的邏輯單元，負責所有數(shù)據(jù)節(jié)點運行狀態(tài)的監(jiān)控和維護，以及節(jié)點之間的負載均衡。同時，管理節(jié)點也負責元數(shù)據(jù)(包括用戶、數(shù)據(jù)庫、表、靜態(tài)標簽等)的存儲和管理。

客戶端初始化的基本流程是：應用通過taosc原生接口訪問TDengine，需要通過firstEP找到集群，獲取到集群的元數(shù)據(jù)（meta-data），也就是集群所有節(jié)點列表(FQDN 或 IP列表)。客戶端驅動一旦獲得列表后，即可按列表與集群對應的節(jié)點進行通信了。默認的通信方式是：15K以下的數(shù)據(jù)走UDP協(xié)議，15K以上的走TCP協(xié)議。

理解了以上流程，我們就可以利用負載均衡器LoadBalancer的相關特點幫助我們實現(xiàn)去hostname的容器化部署了。當然，本方案也同樣可以用在非容器化部署，但希望采用IP地址部署TDengine的場景。

在這個方案里，firstEP指向LoadBalancer的域名及對應的端口(默認為6030)。我們假設LoadBalancer的域名是lb.taosdata.com。TDengine集群節(jié)點尋址采用IP地址作為FQDN：172.16.31.1/172.16.31.2。

應用通過客戶端驅動去連接firstEP：lb.taosdata.com:6030。LoadBalancer收到請求后，根據(jù)預先設定好的負載均衡策略，將請求轉發(fā)給預設的TDengine節(jié)點——172.16.31.1:6030 或 172.16.31.2:6030，收到該消息的節(jié)點將meta-data消息原路返回給請求者(如當前節(jié)點不是mnode主節(jié)點，會觸發(fā)重定向，后續(xù)流程類似)，最終應用/客戶端應用驅動刷新獲得了meta-data列表。

之后，應用需要建立與集群任一節(jié)點的通信時，無需通過LoadBalancer，將直接通過已獲得的IP列表發(fā)起連接，實現(xiàn)通信。

最后一點，也是最重要的一點：如果完成以上步驟不能成功通信，那么有可能是您的LB不支持UDP，或UDP丟包率過高導致。解決方法很簡單，打開所有節(jié)點(包括所有客戶端和服務端)的rpcForceTCP開關，將所有發(fā)起的通信轉為TCP通信而不再采用UDP通信，確保穿透LoadBalancer的通信均走TCP實現(xiàn)。