1. 课程导入
物联网平台不是一套“装上就能跑”的软件，而是连接海量设备、承载实时数据、驱动业务决策的关键基础设施。当一座城市的智能水表、一条产线的振动传感器、一支车队的定位终端同时在线时，平台一旦中断，影响的不是一次页面刷新，而是设备失联、数据断流、告警失效，甚至现场安全。因此，高可用与容灾不是运维团队的“加分项”，而是物联网平台工程能力的基本盘。
本课程的学习目标可以概括为三层。第一层是建立概念坐标系：能准确区分可用性、可靠性、可维护性、容灾能力与业务连续性之间的关系，理解 SLA、RTO、RPO、MTBF、MTTR 等指标分别约束什么。第二层是掌握架构方法：能够针对接入层、消息层、计算层、存储层和控制面，分别设计冗余、隔离、降级、切换与恢复策略。第三层是形成工程闭环：从容量评估、故障注入、切换演练到复盘改进，能够把“高可用”从口号变成可验证、可度量、可迭代的工程实践。
核心概念速览：可用性描述系统在给定时间内可正常服务的能力，常以“几个 9”表达；可靠性强调无故障运行的概率；容灾关注灾难场景下数据与服务的存活能力；业务连续性则从业务视角衡量中断造成的实际损失。RTO 是恢复时间目标，回答“多久能恢复”；RPO 是恢复点目标，回答“最多丢多少数据”。二者必须与业务损失直接挂钩，而不是由技术团队单方面拍定。
理解这些概念时，最容易混淆的是“高可用”与“容灾”。高可用通常面向单机房、单集群内的组件故障，例如某台网关宕机、某个 Broker 节点失联，目标是在秒级到分钟级内自动切换，用户几乎无感。容灾则面向机房级、地域级甚至区域性灾难，例如断电、断网、洪水、地震，目标是在更长时间窗口内恢复核心业务，允许一定数据丢失和较长的服务中断。两者不是替代关系，而是分层防御：高可用解决“局部坏了怎么办”，容灾解决“整体没了怎么办”。
从工程视角看，物联网平台的高可用与容灾需要沿着一条完整的数据链路来审视。设备通过 MQTT、CoAP、HTTP 等协议接入，经过接入网关完成认证、限流与协议解析；消息进入 Kafka、Pulsar 或 RocketMQ 等消息中间件；流计算与规则引擎对数据进行清洗、聚合、告警判断；结果写入时序数据库、关系库或对象存储；同时，设备影子、指令下发、OTA 升级等控制面能力反向作用于设备。这条链路上任何一环出现单点，都会成为整体可用性的短板。
上图展示了物联网平台高可用与容灾的整体框架。需要特别注意的是，容灾层并不是独立于数据链路之外的“备份系统”，而是贯穿接入、消息、计算、存储各层的冗余与切换能力。同城双活解决机房级故障，异地灾备解决区域级灾难，二者共同构成纵深防御。控制面则必须与数据面适度隔离，避免一次配置推送或 OTA 升级把整个平台拖垮。
在工程实践中，高可用与容灾的落地通常遵循“先度量、再设计、后验证”的路径。度量阶段要明确业务可接受的 RTO 与 RPO，例如某智慧园区平台要求核心告警链路 RTO 不超过 5 分钟、RPO 不超过 30 秒，而历史数据查询链路可以放宽到 RTO 2 小时、RPO 15 分钟。设计阶段要针对每条链路识别单点，决定采用主备、双活、多活还是降级策略。验证阶段则要通过故障注入和切换演练，确认自动切换是否真的能在目标时间内完成，数据丢失是否控制在 RPO 以内。
工程视角的三个提醒：第一，高可用不是“没有故障”，而是“故障发生时业务仍可接受”；第二，容灾方案的成本与恢复目标强相关，RTO 越短、RPO 越小，投入通常呈指数上升；第三，任何没有经过演练的切换方案都只能算“假设可用”，不能算“已验证可用”。
本课程后续将沿着这条数据链路逐层展开：从接入层的高可用设计，到消息中间件的副本与跨域复制；从流计算的状态恢复，到时序数据库的降级与归档；从同城双活的流量调度，到异地灾备的数据同步与切换决策。每一层都会给出可操作的参数示例、判断依据和验证方法，帮助你把“高可用与容灾”从概念转化为可落地的工程能力。