隨著容器(qi)化的(de)流(liu)行，越來越多的(de)項(xiang)目采取了容器(qi)化方案來設計架構、實(shi)施部署(shu)。
作為時序(xu)數據(ju)引(yin)擎(qing)核心的TDengine Database，在部署時一般建(jian)議采(cai)(cai)用(yong)FQDN(Fully Qualified Domain Name，完全(quan)限定域名)來進(jin)行節點之間的通(tong)信。很多客戶(hu)在進(jin)行容器(qi)化架構設(she)計時，通(tong)信方式(shi)均采(cai)(cai)用(yong)IP地址(zhi)尋址(zhi)，而且由于這些容器(qi)的IP、容器(qi)名(也就是hostname)會隨著容器(qi)的生命周期變(bian)化而變(bian)化，這就給TDengine采(cai)(cai)用(yong)hostname作為FQDN尋址(zhi)進(jin)行通(tong)信帶(dai)來了困難。
本文將結合(he)實(shi)際，嘗試給(gei)出一最佳實(shi)踐建議，以實(shi)現以下兩個(ge)需(xu)求(qiu)：
- TDengine集群節點采用IP地址尋址
- 應用端無需配置集群節點IP/FQDN地址，而僅采用LoadBalancer域名作為firstEP實現集群尋址
假設TDengine集群由(you)兩個節點組(zu)成，IP分別為172.16.31.1和172.16.31.2。
在(zai)深入(ru)之前，希望(wang)讀(du)者(zhe)先對(dui)TDengine的整體架構有所了解(jie)，可以(yi)參考：。
我們再來強調TDengine Database中的幾(ji)個概念：
- 物理節點(pnode): pnode是一獨立運行、擁有自己的計算、存儲和網絡能力的計算機，可以是安裝有OS的物理機、虛擬機或Docker容器。物理節點由其配置的 FQDN來標識。
- 數據節點(dnode): dnode 是 TDengine 服務器側執行代碼 taosd 在物理節點上的一個運行實例，一個工作的系統必須有至少一個數據節點。dnode包含零到多個邏輯的虛擬節點(VNODE)，零或者至多一個邏輯的管理節點(mnode)。dnode在系統中的唯一標識由實例的End Point (EP )決定。EP是dnode所在物理節點的FQDN和系統所配置的網絡端口號(Port)的組合。
- 管理節點(mnode): 一個虛擬的邏輯單元，負責所有數據節點運行狀態的監控和維護，以及節點之間的負載均衡。同時，管理節點也負責元數據(包括用戶、數據庫、表、靜態標簽等)的存儲和管理。
客戶(hu)端初(chu)始化的(de)(de)(de)基本流程(cheng)是(shi)：應用通(tong)過taosc原生接口訪問TDengine，需要(yao)通(tong)過firstEP找到(dao)集群(qun)，獲取(qu)到(dao)集群(qun)的(de)(de)(de)元數據（meta-data），也(ye)就(jiu)是(shi)集群(qun)所有(you)節(jie)點列(lie)(lie)表(biao)(FQDN 或 IP列(lie)(lie)表(biao))。客戶(hu)端驅動一旦獲得列(lie)(lie)表(biao)后，即可按列(lie)(lie)表(biao)與集群(qun)對應的(de)(de)(de)節(jie)點進行通(tong)信(xin)了。默認(ren)的(de)(de)(de)通(tong)信(xin)方式是(shi)：15K以下的(de)(de)(de)數據走UDP協議，15K以上的(de)(de)(de)走TCP協議。
理解了(le)(le)以上流程，我們(men)就可(ke)以利用(yong)負(fu)載均衡器LoadBalancer的(de)(de)相關特點幫助我們(men)實現(xian)去(qu)hostname的(de)(de)容器化部(bu)署了(le)(le)。當(dang)然，本方案也(ye)同樣可(ke)以用(yong)在(zai)非容器化部(bu)署，但希望采用(yong)IP地址部(bu)署TDengine的(de)(de)場(chang)景。
在這個方案里，firstEP指(zhi)向LoadBalancer的域名及對應的端口(默認為(wei)6030)。我們假設LoadBalancer的域名是(shi)lb.yakult-sh.com.cn。TDengine集群節點尋址采用IP地址作為(wei)FQDN：172.16.31.1/172.16.31.2。
應用通過客戶端驅(qu)動去連接firstEP：lb.yakult-sh.com.cn:6030。LoadBalancer收到請(qing)求(qiu)后(hou)，根(gen)據預(yu)先設定好的(de)(de)負(fu)載(zai)均衡(heng)策略(lve)，將請(qing)求(qiu)轉發(fa)給預(yu)設的(de)(de)TDengine節(jie)點(dian)——172.16.31.1:6030 或 172.16.31.2:6030，收到該(gai)消(xiao)息的(de)(de)節(jie)點(dian)將meta-data消(xiao)息原路返回給請(qing)求(qiu)者(zhe)(如當前節(jie)點(dian)不是mnode主(zhu)節(jie)點(dian)，會觸(chu)發(fa)重定向，后(hou)續流程類似)，最終應用/客戶端應用驅(qu)動刷(shua)新(xin)獲得了meta-data列表。
之后，應用需要建立與(yu)集群任一節點的通信(xin)時，無需通過(guo)LoadBalancer，將直接通過(guo)已獲得的IP列表(biao)發起連接，實現通信(xin)。
最(zui)后(hou)一點(dian)，也是(shi)最(zui)重要的(de)一點(dian)：如果完(wan)成以上步(bu)驟不能成功(gong)通信(xin)，那么(me)有(you)可能是(shi)您(nin)的(de)LB不支持UDP，或UDP丟包率(lv)過高導致。解決(jue)方(fang)法很簡單，打開(kai)所有(you)節點(dian)(包括所有(you)客戶(hu)端(duan)和服務端(duan))的(de)rpcForceTCP開(kai)關，將所有(you)發起的(de)通信(xin)轉為TCP通信(xin)而不再采用UDP通信(xin)，確保穿透(tou)LoadBalancer的(de)通信(xin)均走TCP實現。
