共计 1668 个字符，预计需要花费 5 分钟才能阅读完成。
涛思数据|肖波
随着容器化的风行，越来越多的我的项目采取了容器化计划来设计架构、施行部署。
作为时序数据引擎外围的 TDengine，在部署时个别倡议采纳 FQDN(Fully Qualified Domain Name，齐全限定域名)来进行节点之间的通信。很多客户在进行容器化架构设计时，通信形式均采纳 IP 地址寻址，而且因为这些容器的 IP、容器名 (也就是 hostname) 会随着容器的生命周期变动而变动，这就给 TDengine 采纳 hostname 作为 FQDN 寻址进行通信带来了艰难。
本文将结合实际，尝试给出一最佳实际倡议，以实现以下两个需要：
- TDengine 集群节点采纳 IP 地址寻址
- 利用端无需配置集群节点 IP/FQDN 地址，而仅采纳 LoadBalancer 域名作为 firstEP 实现集群寻址
假如 TDengine 集群由两个节点组成，IP 别离为 172.16.31.1 和 172.16.31.2。
在深刻之前，心愿读者先对 TDengine 的整体架构有所理解，能够参考 TDengine 技术文档。
咱们再来强调 TDengine 中的几个概念：
- 物理节点(pnode): pnode 是一独立运行、领有本人的计算、存储和网络能力的计算机，能够是装置有 OS 的物理机、虚拟机或 Docker 容器。物理节点由其配置的 FQDN 来标识。
- 数据节点 (dnode): dnode 是 TDengine 服务器侧执行代码 taosd 在物理节点上的一个运行实例，一个工作的零碎必须有至多一个数据节点。dnode 蕴含零到多个逻辑的虚构节点(VNODE)，零或者至少一个逻辑的治理节点(mnode)。dnode 在零碎中的惟一标识由实例的 End Point (EP) 决定。EP 是 dnode 所在物理节点的 FQDN 和零碎所配置的网络端口号 (Port) 的组合。
- 治理节点 (mnode): 一个虚构的逻辑单元，负责所有数据节点运行状态的监控和保护，以及节点之间的负载平衡。同时，治理节点也负责元数据(包含用户、数据库、表、动态标签等) 的存储和治理。
客户端初始化的根本流程是：利用通过 taosc 原生接口拜访 TDengine，须要通过 firstEP 找到集群，获取到集群的元数据（meta-data），也就是集群所有节点列表(FQDN 或 IP 列表)。客户端驱动一旦取得列表后，即可按列表与集群对应的节点进行通信了。默认的通信形式是：15K 以下的数据走 UDP 协定，15K 以上的走 TCP 协定。
了解了以上流程，咱们就能够利用负载均衡器 LoadBalancer 的相干特点帮忙咱们实现去 hostname 的容器化部署了。当然，本计划也同样能够用在非容器化部署，但心愿采纳 IP 地址部署 TDengine 的场景。
在这个计划里，firstEP 指向 LoadBalancer 的域名及对应的端口(默认为 6030)。咱们假如 LoadBalancer 的域名是 lb.taosdata.com。TDengine 集群节点寻址采纳 IP 地址作为 FQDN：172.16.31.1/172.16.31.2。
利用通过客户端驱动去连贯 firstEP：lb.taosdata.com:6030。LoadBalancer 收到申请后，依据事后设定好的负载平衡策略，将申请转发给预设的 TDengine 节点——172.16.31.1:6030 或 172.16.31.2:6030，收到该音讯的节点将 meta-data 音讯原路返回给请求者(如以后节点不是 mnode 主节点，会触发重定向，后续流程相似)，最终利用 / 客户端利用驱动刷新取得了 meta-data 列表。
之后，利用须要建设与集群任一节点的通信时，无需通过 LoadBalancer，将间接通过已取得的 IP 列表发动连贯，实现通信。
最初一点，也是最重要的一点：如果实现以上步骤不能胜利通信，那么有可能是您的 LB 不反对 UDP，或 UDP 丢包率过高导致。解决办法很简略，关上所有节点 (包含所有客户端和服务端) 的 rpcForceTCP 开关，将所有发动的通信转为 TCP 通信而不再采纳 UDP 通信，确保穿透 LoadBalancer 的通信均走 TCP 实现。
流动举荐：