为了扩展 TWX 应用程序,必须遵循哪些架构和应用程序开发最佳实践?
大多数应用程序从很少的设备开始,但随着时间的推移,它们会迅速构建到数千台设备。一旦一个 TWX 实例的流量过多,应该遵循什么策略?当前端被用户数量淹没时,同样的问题也适用。
为了扩展 TWX 应用程序,必须遵循哪些架构和应用程序开发最佳实践?
大多数应用程序从很少的设备开始,但随着时间的推移,它们会迅速构建到数千台设备。一旦一个 TWX 实例的流量过多,应该遵循什么策略?当前端被用户数量淹没时,同样的问题也适用。
每当我遇到 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 9.0 版本中,ThingWorx Foundation 平台通过主动-主动集群设置支持真正的水平可扩展性,不提供单点故障。此处的文档提供了有关安装和设置的详细信息。还有一个ThingWorx 9.0 部署架构指南,用于概述所有架构细节。