1. 课程导入与ThingWorx高可用灾备全景

ThingWorx 是 PTC 面向工业物联网场景的应用使能平台，它把设备连接、数据建模、可视化编排、业务逻辑与第三方系统集成整合在同一套运行时之上。当这套平台承载产线监控、设备远程运维、能耗分析等关键业务时，一次计划外停机往往不只是"页面打不开"，而是直接影响现场判断与响应。本课程的目标，是让学员能够独立设计、部署并验证一套具备高可用（High Availability，HA）与灾备（Disaster Recovery，DR）能力的 ThingWorx 环境。本章先建立全景认知：平台由哪些核心组件构成、高可用与灾备分别解决什么问题、工程落地时会遇到哪些真实挑战，以及后续章节的整体框架。

一、ThingWorx 平台的核心组件

理解高可用，必须先理解"哪些东西会坏、坏了会怎样"。ThingWorx 的典型部署并非单一进程，而是由若干职责不同的组件协同工作：

• ThingWorx 应用服务器（Platform Server）：核心运行时，承载 Thing、ThingTemplate、ThingShape、Mashup、服务与订阅等模型对象，对外提供 REST/WebSocket 接口。它是有状态倾向的组件，模型数据与运行时状态都与之相关。
• 持久化数据库（PostgreSQL）：保存模型定义、配置、用户与权限、部分运行时数据。它是整个平台的"事实来源"，一旦不可用，应用服务器即使存活也无法正常提供业务。
• 模型存储库（Model Repository）：用于存放 Mashup 资源、扩展包、文件类实体等二进制内容，通常以文件系统或对象存储形式存在，需要与数据库保持一致性。
• 连接层（Industrial Connectivity / Kepware）：通过 OPC UA、Modbus、MQTT 等协议采集现场设备数据，再送入平台。它决定了"数据能不能进来"。
• 反向代理与负载入口（Nginx / 负载均衡器）：统一对外入口，负责 TLS 终止、请求分发与会话保持。
• 可选组件：如 Flow 服务、ThingWorx Foundation 的扩展微服务、日志与监控代理等。

这些组件的可用性等级并不相同。数据库与模型存储库属于"共享单点"，应用服务器属于"可横向扩展层"，连接层则介于两者之间。高可用设计的核心思路，就是让可扩展层冗余、让共享层具备故障切换能力。

二、高可用与灾备：两个不同层次的目标

高可用与灾备经常被混用，但工程上必须区分。高可用的目标是减少服务中断，通常在同一数据中心内通过冗余节点、健康检查与自动故障转移实现，衡量指标是可用性百分比（如 99.9% 对应年停机约 8.76 小时）。灾备的目标是在区域性灾难后恢复业务，依赖跨站点复制与切换预案，衡量指标是 RPO（恢复点目标，允许丢失多少数据）与 RTO（恢复时间目标，允许中断多久）。

两者是互补关系：高可用解决"单台机器坏了"，灾备解决"整个机房没了"。一个常见误区是只做应用层双活，却让数据库保持单实例——此时应用冗余毫无意义，因为数据库一挂，两个应用节点同时失效。因此本课程反复强调：先识别共享单点，再谈冗余。

三、工程落地中的真实挑战

把 ThingWorx 做成高可用，难点不在"装两台服务器"，而在以下几个具体问题：

• 有状态与无状态的边界：ThingWorx 应用服务器本身可横向扩展，但会话、定时任务、订阅触发等行为需要明确由谁执行，否则会出现重复执行或状态丢失。
• 数据库切换的一致性：主备切换后，应用连接串、连接池、序列与自增主键都需要重新校验，否则会出现写入冲突。
• 模型存储库与数据库的同步：两者若不同步，切换后可能出现"模型存在但资源缺失"的残缺状态。
• 连接层的数据连续性：设备数据在切换窗口内可能丢失，需要通过设备侧缓存或双上报缓解。
• 切换的可验证性：没有演练过的切换预案等于没有预案。必须定义明确的健康判据与回切条件。

四、本课程的整体框架

后续章节将沿着"认知—设计—部署—验证—运维"的路径推进：先深入各组件的高可用机制与选型依据，再给出双站点部署的具体配置（数据库流复制、负载均衡健康检查、模型存储库同步），随后通过故障注入演练验证 RPO/RTO 是否达标，最后落到日常监控、备份策略与切换手册的维护。本章作为导入，重点是建立"组件—单点—冗余—指标"这条主线，让后续每一个配置动作都能对应到一个明确的可用性目标。

学习本章后，你应当能够：说清 ThingWorx 各核心组件在高可用中的角色；区分高可用与灾备的目标与指标；识别典型部署中的共享单点；并理解本课程后续内容为何按当前顺序组织。