ThingWorx 水平可扩展性

Posted 2023-03-10

【中文标题】ThingWorx 水平可扩展性

【英文标题】：ThingWorx Horizontal Scalability

【发布时间】：2018-08-21 23:56:23

【问题描述】：

为了扩展 TWX 应用程序，必须遵循哪些架构和应用程序开发最佳实践？

大多数应用程序一开始只使用很少的设备，但随着时间的推移，它们很快就会增加到数千台设备。一旦一个 TWX 实例的流量过多，应该遵循什么策略？ 当前端被用户数量压得喘不过气来时，同样的问题也适用。

【参考方案1】：

每当我遇到 ThingWorx 架构问题时，我都会被重定向到下面链接的 PTC ThingWorx 指南。我认为您不需要 PTC 帐户即可查看它，但如果需要，它是免费的。

ThingWorx 8 高可用性管理员指南 http://support.ptc.com/WCMS/files/173281/en/ThingWorx_8_High_Availability_Administrators_Guide.pdf

如果您有很大的负载问题，该指南建议使用 两个 ThingWorx 实例来处理负载。

HA 配置至少需要两个 ThingWorx 实例。一种 单个实例启动，成为领导者并完全连接到 数据库。备用服务器启动并可以成为领导者，如果 需要，但它们没有完全连接到数据库或加载 像领导者一样的信息。所有 ThingWorx 服务器都有服务 由负载均衡器调用，表示它们的 可用性。不同的代码识别领导者，接收者 流量和备用节点，它们不接收流量，但可能 成为领导者。

参考指南中的高级架构示例：

负载均衡器确定用户要使用哪个 ThingWorx 实例。通常它用于确定冗余架构中哪些是可用的（这就是使其高度可用的原因）。但是，它也可以用于根据性能确定使用哪个。在 PTC 的 HA 管理员指南中，他们使用 HAProxy (p. 47) 作为负载平衡器。如何根据性能进行配置，请参阅HAProxy Config Doc 的第 3.2 节。

希望这会有所帮助！这是一个非常开放的话题

【讨论】：

您提供的解决方案与高可用性有关。将一个实例作为领导者，另一个作为备用实例不会增加更多的处理能力，因此不符合水平可扩展性的条件。

好吧，我帖子中的信息只是一个开始和一个高级架构。确定用户被重定向到哪个 Thingworx 实例取决于您用作负载均衡器的任何内容，在 PTC 的指南中，他们使用 HAProxy，您可以在第 47 页找到更多信息。（配置信息：haproxy.org/download/1.5/doc/configuration.txt）显然代理可以是配置为根据可用的重定向进行重定向，但也可以针对性能进行配置。请参阅 HAProxy 配置文档中的第 3.2 节

【参考方案2】：

在 ThingWorx 9.0 版本中，ThingWorx Foundation 平台通过主动-主动集群设置支持真正的水平可扩展性，不提供单点故障。文档here 提供了有关安装和设置的详细信息。 还有一个ThingWorx 9.0 deployment architecture guide 用于所有架构细节的概述。

ThingWorx High Availability Clustering setup image