为了扩展 TWX 应用程序，必须遵循哪些架构和应用程序开发最佳实践？
大多数应用程序一开始只使用很少的设备，但随着时间的推移，它们很快就会扩展到数千个设备。一旦一个 TWX 实例的流量过多，应采取什么策略？ 当前端被用户数量淹没时，同样的问题也适用。
最佳答案
每当我遇到 ThingWorx 架构问题时，我都会被重定向到下面链接的 PTC ThingWorx 指南。我不认为您需要 PTC 帐户才能查看它，但如果是这样，它是免费的。
ThingWorx 8 高可用性管理员指南 http://support.ptc.com/WCMS/files/173281/en/ThingWorx_8_High_Availability_Administrators_Guide.pdf
如果您有很大的负载问题，指南建议使用 两个 ThingWorx 实例来处理负载。
At least two ThingWorx instances are required for HA configuration. A single instance is started, which becomes leader and fully connects to the database. Standby servers boot up and can become the leader if needed, but they do not fully connect to the database or load information like the leader does. All ThingWorx servers have a service that is called by the load balancer, which indicates their availability. Different codes identify the leader, which receives traffic, and standby nodes, which do not receive traffic but may become leader.
引用指南中的高级架构示例:
负载均衡器确定用户要使用哪个 ThingWorx 实例。通常它用于确定冗余架构中哪些可用(这就是使其高度可用的原因)。但是，它也可用于根据性能确定使用哪个。在 PTC 的 HA 管理指南中，他们使用 HAProxy(请参见第 47 页)作为负载均衡器。请参阅 HAProxy Config Doc 的第 3.2 节了解如何根据性能进行配置。
希望这有帮助!这是一个非常开放的话题
关于frontend - ThingWorx 水平可扩展性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49261054/