blackstar-baba
commented
2 months ago 感谢建议：
- 有做过这样的实践：在设备（网关）连接到云端时，需要有一个统一入口，使用vip+keepalive+haproxy，做整个集群的反向代理，如果有同等功能的k8s负载均衡器，也可以替代
- 目前了解，tb的节点都是同等地位，无状态，使用deployment即可，有状态的服务，比如zk、postgres通常是sts
- thingsboard有多种玩法，单体架构和微服务架构，通过工程结构+配置完成一套代码，支持两种架构，如果是高可用，高负载，通常使用
后续继续完善文档，再次感谢～
针对高可用方案图，我有些问题不是很清楚 ，目前我就是要部署高可用方案，设备数就是奔着上千万台去的 1，haproxy proxy 代理可以部署k8s内部的 2，k8s 容器组本身具有 负载的功能，不管是mqtt，还是http协议都是可以的，好像和用zk,haproxy 有些冲突，就是说如果k8s自带能解决负载mqtt 的话，就不需要部署haproxy ，那什么时候要用haproxy ，除非是一个域名下，要对应多个服务，比如mqtt://a.com, http://a.com 这样子的才有可能需要用到haproxy,那如果每个微服务都有一个独立的域名就不需要部署 haproxy
3，在k8s里面可以补充哪些部署采用 k8s Deployment,还是 StatefulSet 部署方式，目前我还没有搞清楚 这个我目前想到部署时用到了TB_SERVICE_ID 这个环境变量，每个id不一样且唯一，目的是用于zk协调。 如果要TB_SERVICE_ID 唯一，则要用 StatefulSet 。
4，根据官方的k8s集群部署方案，ce版本的 3.6.4 这个连接 https://github.com/thingsboard/thingsboard-ce-k8s/blob/release-3.6.4/minikube/tb-node.yml tb-node就是tb-core 依赖了zk, 那些服务需要依赖zk的，我现在还没有搞清楚，这些服务都是基于application maven 打包拆分出来的，很神奇的样子。
我不确定，还是不清楚 tb-http-transport, tb-mqtt-transport, tb-core, tb-rule-engine 那些要用TB_SERVICE_ID 这个id, TB_SERVICE_ID 作为zk协调，要是唯一，
目前已知的：tb-rule-engine、tb-js-executor 是一个处理kafka消息的，不需要暴露端口 tb-http-transport 端口是8080，不是9090更不是 7070，用于给设备通过http上报遥测数据的 tb-core/tb-node 一样，暴露8080端口，我理解就是提供给web ui ，restclient 调用的 tb-mqtt/coap 设备连接mqtt,