4. ThingWorx平台组件高可用部署规划

ThingWorx 平台并非单一进程，而是由 Foundation、Connection Server、Flow、HAProxy 等多个角色协同构成的分布式系统。做高可用规划时，最容易犯的错误是“所有组件都上双活集群”，结果把有状态组件做成脑裂、把无状态组件做成单点。本节的核心任务是：先按“是否有状态、是否可水平扩展、故障影响面”给组件分类，再为每一类选择匹配的 HA 模式，最后拼成一张可落地的拓扑。

一、先给组件定性：有状态与无状态决定 HA 模式

ThingWorx Foundation 是平台核心，承载建模、服务、用户、权限与持久化数据。它依赖 PostgreSQL 与 ZooKeeper，属于有状态组件。Foundation 自身支持多节点集群，但前提是数据库与协调服务先具备高可用。因此 Foundation 的 HA 不是“多起几个 Pod”那么简单，而是“数据库主备 + ZooKeeper 仲裁 + 应用节点无状态化”三层同时成立。

Connection Server 负责设备连接、协议适配与消息接入，它本身不保存业务数据，会话状态可重建，属于可水平扩展的无状态组件。Flow 负责编排与集成逻辑，执行实例可分布到多个节点，同样属于无状态可扩展组件。HAProxy 是流量入口，承担 TLS 终止、健康检查与负载均衡，属于无状态但必须冗余的组件。四类组件的 HA 选型因此分化：Foundation 走“集群 + 共享有状态后端”，Connection Server 与 Flow 走“多实例 + 负载均衡”，HAProxy 走“双活 + VIP 漂移”。

二、Foundation 的 HA 模式：集群 + 共享有状态后端

Foundation 的 HA 部署模式通常选择“多节点应用集群 + PostgreSQL 主备 + ZooKeeper 三节点仲裁”。应用节点本身不保存业务数据，但会缓存会话与部分运行时状态，因此需要在 HAProxy 上启用会话粘滞（stickiness），避免同一用户请求在节点间反复跳转导致会话失效。PostgreSQL 采用流复制主备，主库故障时由 Patroni 或 repmgr 触发切换，Standby 提升为 Primary，应用节点通过 VIP 或 DNS 重新连接。ZooKeeper 必须部署奇数节点，3 节点可容忍 1 节点故障，5 节点可容忍 2 节点故障；若只部署 2 节点，一旦其中一台宕机，剩余节点无法形成多数派，整个协调层失效，Foundation 集群会进入不可用状态。

一个常见的教学示例参数如下：Foundation 集群 2 节点，每节点 8 vCPU / 32 GB 内存；PostgreSQL 主备各 8 vCPU / 32 GB，WAL 归档到共享存储；ZooKeeper 3 节点各 2 vCPU / 4 GB。HAProxy 健康检查间隔 2 秒，失败阈值 3 次，成功阈值 2 次。这些参数属于合理假设，实际部署需按设备连接数与并发用户数压测后调整。

三、Connection Server 与 Flow：无状态多实例 + 负载均衡

Connection Server 的 HA 模式相对简单：部署 2 个及以上实例，注册到同一负载均衡后端，设备连接按轮询或最少连接分发。由于连接会话可重建，不需要粘滞；但要注意 MQTT 长连接在实例重启时会断开，设备端需具备自动重连与断点续传能力。Flow 执行节点同样多实例部署，任务分发依赖 Foundation 或外部消息队列；Flow 逻辑必须设计为幂等，避免同一任务被重复执行导致数据重复写入。

这里有一个容易忽略的细节：Connection Server 与 Flow 虽然无状态，但它们都需要访问 Foundation 的 API。如果 Foundation 集群不可用，Connection Server 和 Flow 即使自身健康，也无法完成业务闭环。因此 HAProxy 的健康检查不能只检查 Connection Server 端口，还应检查其到 Foundation 的依赖链路，否则会出现“后端显示健康但业务不可用”的假象。

四、HAProxy 的 HA：双活 + VIP 漂移

HAProxy 作为统一入口，必须避免单点。推荐模式是两台 HAProxy 组成双活或主备，通过 Keepalived 维护一个虚拟 IP（VIP）。客户端只访问 VIP，主节点故障时 VIP 漂移到备节点，ARP 广播更新，连接在秒级内恢复。HAProxy 配置中需要为 Foundation、Connection Server、Flow 分别定义 backend，并设置合理的健康检查路径。例如 Foundation 可用 /Thingworx/Health，Connection Server 可用其管理端口健康端点。健康检查失败后，该后端节点被摘除，流量自动切换到其余节点。

五、拓扑设计中的依赖顺序与故障域

规划拓扑时，依赖顺序必须自下而上：先保证 PostgreSQL 与 ZooKeeper 的高可用，再部署 Foundation 集群，最后接入 Connection Server、Flow 与 HAProxy。故障域方面，同一组件的多个实例应分散到不同物理机、不同机架或不同可用区。例如 Foundation Node-1 与 Node-2 不应部署在同一台宿主机；ZooKeeper 三节点应跨三个故障域。若所有节点都在同一台虚拟化宿主上，宿主宕机将导致整个平台不可用，HA 形同虚设。

最后，HA 规划必须配套验证手段：定期执行主库切换演练、ZooKeeper 节点宕机演练、HAProxy 主备切换演练，并观察业务是否在可接受时间内恢复。只有经过验证的 HA 拓扑，才是真正可用的高可用架构。