随着容器化的流行，越来越多的项目采取了容器化方案来设计架构、实施部署。
作为时序数据引擎核心的TDengine Database，在部署时一般建议采用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的整体架构有所了解，可以参考：https://tdengine.com/docs/cn/v2.0/architecture#cluster。
我们再来强调TDengine Database中的几个概念：
- 物理节点(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实现。
