> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/zh/guan-li-yuan-zhuan-qu/architecture-and-design/bcdr-whitepaper.md). # 业务连续性和灾难恢复白皮书 ## **简介** Zoom 通过单一集成平台提供 AI 优先的统一通信即服务 (UCaaS) 和呼叫中心即服务 (CCaaS)。本文详细介绍了 Zoom 一流服务和产品背后的创新与架构，说明我们如何在 UCaaS 和 CCaaS 中为最终用户和 IT 提供一致、安全且易于管理的体验。 ## **源于经验构建** Zoom 的云优先愿景帮助组织摆脱传统企业部署系统的成本和复杂性。我们并非将功能硬加到陈旧的技术堆栈中，而是投资于涵盖客户端、媒体服务和会议室系统的全栈工程，将端到端质量、弹性和易用性优化为一个统一的平台——以单客户端策略为基础，在各平台上采用通用代码库，并充分利用每个操作系统的原生用户体验。这一云优先方法体现在 Zoom Workplace 应用中：这是一个单一、现代化的应用程序，让用户能够集中访问 Meetings、聊天、Phone、呼叫中心、Events、Webinars、Rooms、白板、Canvas 等。访问权限由许可证控制，因此 IT 可以启用或关闭产品和功能，而无需部署由不同安装程序组成的拼凑方案，也无需管理相互冲突的客户端版本。对于 IT 而言，该模式可降低开销——需要购买、上架和修补的服务器更少；需要维护的定制集成更少；也无需专门团队来维持企业部署基础设施运行。容量、更新和安全性改进均通过云交付，因此管理员可以专注于策略、采用情况和成果，而非维护工作。 ## 实时媒体架构和弹性以下章节将讨论 Zoom 实现一流实时媒体体验的设计方法。 ### Zoom Meetings、Webinars 和 Events 我们架构的基础是一个智能传输层，它根据实际网络状况和策略选择最佳路径。在可用时使用 UDP，在限制更严格的环境中可无缝回退至 TCP/TLS（包括 HTTPS/443）。屏幕共享会尽可能使用可靠 UDP 以实现流畅运动，并在需要时自动回退。正在连接会议、网络研讨会或事件 & 活动 &直播时，Zoom Workplace 应用会根据地理位置被引导至最近的在线资源，以最大限度地减少延迟。当组织策略或性能要求时，流量可通过专用链路穿越 Zoom 的全球骨干网，前往不同的数据中心。

Diagram detailing how the Zoom App maintains active-active connectivity to failover data centers, zone controllers, and multi-media routers. — Zoom 会议、网络研讨会和事件 & 活动 &直播主动-主动架构及设计概述。

下一层是响应式服务质量层，可适应实时网络和设备状况。它监控带宽、丢包、延迟和抖动，同时还收集本地 CPU 使用率、内存和网络 I/O。这些信号将告知上层采取适当的自适应操作，以维持质量和可靠性。 Zoom 在会议层使用的自定义自适应编解码器针对实时性能进行了调优。周边算法会持续优化帧率和分辨率，以匹配设备和网络状况。为在条件允许时提供尽可能最佳的体验，Zoom 使用多个同时流，Zoom Workplace 应用会动态选择最合适的层。凭借高效压缩，即使丢包率高达约 45%，会议仍可使用；在此情况下，音频优先于视频，以保持对话清晰。多流方法还会根据每位参会者发送和接收音频及视频的能力调整带宽。 Zoom 的分布式会议层使用基于订阅的交换，不进行服务器端转码或混流。传统服务通常会对流进行转码和混流，从而增加 CPU 和内存开销；我们的交换方法旨在降低资源使用并高效扩展。参会者根据地理位置被路由到最近的数据中心，并分配至负载最低的服务器；当参会者位于同一地点时，可将其分组至同一服务器以提高效率。该架构支持灵活的企业部署和混合部署，并为大型企业版提供级联流量路径。会议服务器是我们的 MMR（多媒体路由器），每个 MMR 都归属于一个“会议区域”。区域控制器管理会议区域中的所有 MMR，并将其状态报告给全局云控制器。每个数据中心均部署完全相同架构的会议区域副本，我们可以随时轻松添加更多区域，以增加各区域的容量。这三层（MMR、Zoom 控制器和全局云控制器）用于平衡不同位置的资源。如果会议中只有两名参会者，Zoom 可以利用点对点连接，实现卓越的速度和可靠性。所有这些使 Zoom 能够维持 99.9% 正常运行时间的会议服务可用性，并提供可靠的视频会议体验。 ### Zoom Phone Zoom Phone 专为云而构建于云端，采用已在我们的 Zoom Meetings 和 Webinars 产品中验证的音频质量自适应技术。Zoom 的架构内置冗余和弹性，因此形成高度可用的解决方案，可扩展以满足即使是最大组织的需求。 Zoom Phone 利用智能传输机制，在多样化网络环境中实现可靠连接。对于媒体，它会在可用时通过 UDP 使用 SRTP，并可无缝回退至 TCP/TLS，同时采用自适应比特率和丢包缓解技术，以在恶劣条件下保持音频质量。对于连接，呼叫会路由至最近的在线 SIP 区域以最小化延迟，并可在需要时跨数据中心自动故障转移。

Diagram showing a Zoom Phone device connected to a primary data center, with a secondary connection to an additional data center for failover events. — Zoom Phone 的主动-主动架构

Zoom 在其每个数据中心均部署了冗余会话边界控制器 (SBC)，以保障客户端和运营商通信安全。这些运营商级 SBC 可为广泛的组织提供便捷访问，涵盖从最小的客户到全球企业版。负载均衡器将基于 SIP 的通信重定向到 Zoom 的呼叫交换机，以均匀分配呼叫量。即使在注册高峰期和呼叫繁忙时段，这种分配也能为用户带来流畅体验。呼叫交换机是 Zoom Phone 的核心呼叫控制组件。这些可扩展组件不仅支持基本 PBX 功能，还可向 Zoom Phone 仪表板提供遥测数据，并启用将 Zoom Phone 呼叫升级为 Zoom 会议等功能。

A diagram showing the active-active architecture for hardware and SIP zones hosted within a data center — 数据中心内托管的硬件和 SIP 区域的主动-主动架构

Zoom Workplace 应用利用专有逻辑监控应用的带宽、丢包、延迟和抖动，同时收集应用的 CPU 使用率、内存和网络 I/O。此技术会主动监控呼叫并进行实时调整，以克服不佳的网络状况，从而为各种网络环境和不同设备提供卓越的呼叫质量和可靠性。 Zoom Phone 仪表板采集实时和历史服务质量数据，以及使用情况和采用指标、呼叫日志及与游牧紧急服务相关的指标。Zoom 会自动使用平均意见得分 (MOS) 对每次呼叫评分，使 IT 管理员能够跟踪穿越网络的所有呼叫的性能，并隔离潜在的网络相关问题。
### Zoom 呼叫中心与 Zoom Phone 类似，Zoom 呼叫中心的主动-主动架构有助于在其全渠道环境中提供弹性和冗余。呼叫中心以 Zoom Meetings 和 Phone 服务经过验证的架构为基础，无缝集成实时通信功能与 Web 功能，打造直观界面，使您的坐席团队和客户均可受益。每个数据中心均设有两个完全相同、互连的会话发起协议 (SIP) 区域。SIP 区域允许通过互联网拨打和接听语音呼叫，每个区域都配备专用硬件和服务，以实现独立持续运行。在数据中心内，负载均衡器会将呼叫均匀分配至两个 SIP 区域。呼叫会分布于呼叫交换机集群中，这些交换机负责呼叫路由、建立和终止等各项功能。呼叫从呼叫交换机连接至每个区域内的 SBC，后者将连接至 Zoom 的底层提供商网络或客户提供的运营商，以进行 PSTN 路由，直至呼叫到达最终目的地。SBC、负载均衡器和呼叫交换机均配有处于待命状态的冗余硬件，以增强弹性。 Zoom 呼叫中心中的语音采用与 Zoom Phone 相同的客户端自适应和传输行为——在可用时使用 UDP，并回退至 TCP/TLS——即使在受限网络上也能保持音频清晰。对于视频和数字频道，该服务利用 Zoom 的实时媒体骨干网和云弹性，以实现一致质量和故障转移。 #### Cobrowse Zoom 呼叫中心的 Cobrowse 服务运行在与核心 Zoom 呼叫中心服务分离的基础设施上。会议开始时，软件开发工具包 (SDK) 会与协同浏览中心服务器 (CHS) 建立持久 WebSocket 连接，以进行双向通信；流量会根据地理位置路由至最近的在线数据中心，从而减少延迟。该服务采用无状态分布式架构，并在 CHS 节点间使用动态负载均衡，以支持在云、混合和企业部署模型中的弹性扩展。为帮助维持会议连续性，如果连接中断，SDK 会自动重新连接到正常的 CHS 节点，并可在数据中心间故障转移，且中断极小。结合持续运行状况监控和 Zoom 更广泛的主动-主动弹性方法，该架构旨在为企业环境提供可靠、可扩展的协同浏览性能。

## **用于混合和企业部署的 Zoom Node** [Zoom Node](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer) 是一个云管理的混合平台，可将您的数据中心资源与 Zoom 云相连，使您能够在企业部署 Zoom 服务模块（工作负载），并通过 Zoom Web门户进行管理。其中有两个模块在弹性方面尤为突出：Zoom Meetings Hybrid 和 Zoom Phone Local Survivability (ZPLS)。 [Zoom Meetings Hybrid](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-meetings-hybrid) 通过本地 Node 为内部参会者路由实时媒体，而信令、管理员和策略仍保留在 Zoom 云中；如果 Zoom 数据中心无法访问，它还包括本地持续运行选项。内部用户可获得低延迟路径并减少互联网出口流量，外部参会者则可以像往常一样通过云加入。必要时，帐户还可添加录制连接器以进行本地捕获；如果本地容量不可用，则会自动故障转移至云。

Zoom Meetings Hybrid Module shows how users in a local network connect to the Hybrid MMR, cascading to the cloud. — Zoom Meetings Hybrid 模块展示本地
网络中的用户如何连接到 Hybrid MMR，并级联至云端。

[Zoom Phone Local Survivability](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-phone-local-survivability) (ZPLS) 可在 WAN 或提供商路径中断时，保持站点的核心呼叫功能在线。电话会在本地注册，内部扩展呼叫持续可用；在配置后，可通过企业部署 PSTN 路径维持关键外拨通话。连接恢复后，服务会自动恢复正常云操作。

Diagram showing how the ZPLS module supports PSTN, intra-site, and cross-site survivability. — Zoom Phone Local Surviability 支持在影响服务的事件发生时，针对 PSTN 和
跨站点连接的多种故障恢复场景。

## **全球分布式数据中心和冗余** Zoom 在全球多个相互连接的数据中心中分布部署代理和通信服务器。我们持续评估数据中心和互联网服务提供商 (ISP)，以针对带宽、延迟和灾难恢复隔离优化客户性能。我们的数据中心位于安全的共址设施中，这些设施对 ISP 运营商保持中立，并提供物理安全、冗余电力以及对顶级 ISP 和对等互连合作伙伴的同时访问。我们还在区域或容量要求合理的情况下，使用公共云提供商进行某些部署。我们的共址设施采用具备完全冗余和快速故障转移能力的容错架构构建。Zoom 会动态对通信服务器进行负载均衡，自动将新会议转移至响应时间最佳的数据中心。这些设施在物理层也专为弹性而设计。每个共址设施均采用 N+1 冗余并配备全套环境控制措施，旨在使设施能够在组件故障和物理危害期间持续运行： * 温度和湿度控制 * 完全冗余且可应对组件故障的电力系统 * 有弹性的应急照明 * 消防保护 * 防水损保护数据中心包括不间断电源 (UPS) 冗余模型，例如 N、N+1 或 2N，以及采用 N+1 设计的发电机冗余；电力维护和测试由相应的数据中心提供商负责。如果 Zoom 使用 AWS 托管部分云基础设施，Zoom 安全团队会通过外部服务审计师报告每年审查 AWS 控制措施的存在性和运行情况；发现的任何例外情况均会与 AWS 讨论，如其对 Zoom 的系统或数据构成风险，则会升级至 Zoom 管理层。

## **容量** Zoom 在基础设施的各个方面均维持 50% 的额外容量，以适应不断增长的商业版需求并满足高峰使用要求。我们有信心可根据当前和未来客户需求提供服务并实现扩展。 ## **业务连续性和灾难恢复** 正常状况下的可靠性只是其中一部分；同样重要的是，平台在发生问题时如何运行。自然灾害、电力或设施故障、网络攻击事件、网络中断和硬件故障等中断，对于任何全球服务而言都是不可避免的现实；Zoom 的弹性源自其应对此类事件的准备、承受和恢复方式。这种弹性建立在四个不同但相互关联的层面上，每一层都在中断发生前、期间和后的不同阶段运作： * **高可用性** — 该架构层通过消除单点故障，在故障发生前降低其发生可能性和影响。 * **业务连续性** — 该运营层确保在确实发生中断时，基本业务功能能够持续运行。 * **灾难恢复** — 该恢复层可在中断事件发生后，使受影响的技术系统和服务恢复正常运行。 * **测试** — 该验证层确认这些实践有效，并为持续改进提供经验教训。这些层面相互构建：高可用性降低需要恢复的频率，业务连续性决定在恢复期间哪些功能持续运行，灾难恢复修复受影响的部分，而测试验证整体。本文所述的架构——主动-主动数据中心、基于地理位置的路由、自动故障转移和 N+1 部署——正是高可用性层的实际体现。以下章节将介绍其余三层。 ### 高可用性高可用性是指旨在支持持续运行和最短停机时间的系统与服务设计；Zoom 的系统中已融入这种设计，目标是最大限度地减少或消除关键故障点。服务设计为能够承受整个数据中心中断，并且在故障发生时，自动化流程会将流量从受影响区域转移。核心应用程序按照 N+1 标准部署，因此如果某个数据中心不可用，仍保留足够容量将流量负载均衡到幸存站点。这一设计理念涵盖通信平台所依赖的整套系统——冗余设施、电话通讯基础设施、互联网和 LAN 连接、安全基础设施、关系型数据库系统、大容量存储、备份、硬件，以及相关的容量管理和维护实践——从而确保任何单一组件、系统或设施发生故障都不会导致服务丢失。 ### 业务连续性 Zoom 的业务连续性规划旨在最大限度地减少中断对运营的影响、保护资产，并为客户和利益相关者维持基本服务。它确定必须优先保留或恢复的业务功能、这些功能依赖的人员、技术、供应商和工作区资源，以及这些依赖项中断时的潜在影响。这为 Zoom 在正常运营受到影响时协调响应和恢复提供了结构化基础，特别是在多个功能或资源需要同时处理时。该规划的基础是业务影响分析 (BIA)，即 Zoom 用于识别和评估中断对关键业务功能潜在影响的系统化流程。Zoom 至少每年对关键功能执行一次 BIA，或者在关键业务流程发生重大更改时执行。该分析涵盖四个关键组成部分： 1. **识别关键业务功能** — 记录对 Zoom 运营至关重要的关键流程，并确定它们之间的依赖关系和相互依赖关系。 2. **影响评估** — 评估中断对各项功能的潜在影响，同时考虑财务损失、运营停机时间、法律和监管影响以及声誉损害。 3. **资源要求** — 识别支持恢复所需的人员、技术、设施和第三方服务，并评估其可用性和充分性。 4. **恢复工作的优先级排序** — 根据其影响和既定恢复目标对关键功能的恢复进行排序，以便最关键的功能得到优先恢复。 ### 灾难恢复 Zoom 通过每年对各产品进行测试，定期验证其灾难恢复能力。公司维护一份正式记录的灾难恢复计划 (DRP)，其中定义了中断后恢复关键系统和服务的程序，包括恢复策略、角色与职责及通信协议。Zoom 的 DRP 旨在应对各种灾难场景，其中可能包括以下一种或多种情况：断电、网络连接丢失、硬件故障、自然灾害和其他中断事件，直至设施完全故障。管理灾难恢复的信息安全标准均已记录、批准、传达，并且至少每年审查一次。 Zoom 并不为云服务维护专用的热恢复站点，而是依靠冗余架构、多地点数据中心和包括 AWS、OCI 及 GCP 在内的多个云提供商来支持连续性。在平台层面，恢复模式因服务类型而异： * **Web 集群和非实时通信** 采用 AWS 高可用性基础设施，以多区域主动-主动配置运行，依靠 DNS 记录实现数据中心之间的故障转移，并在每个数据中心内包含具备复制能力的多个组件。 * **区域数据中心和实时通信** 在地理位置分散的三级及以上提供商之间以主动-主动配置运行；每个区域数据中心内都具有冗余且富有弹性的组件和连接，由多家运营商支持连接，区域间故障转移需要重新连接。 Zoom 记录在案的恢复策略包括区域故障转移，即将流量或服务从受影响区域转移；以及通过蓝绿部署进行回滚，即将服务恢复到先前已知良好的环境或部署状态，以从软件或部署相关问题中恢复。这些策略将根据定义的恢复目标进行衡量。恢复时间目标 (RTO)——中断后恢复服务的目标时间——设定为少于五分钟。恢复点目标 (RPO)——可容忍数据丢失量的目标——设定为不丢失数据，并通过在多个可用区之间复制云存储数据提供支持。这些目标为 Zoom 的设计和测试提供依据，而非作为服务保证。有效的数据备份和恢复是此方法的核心组成部分，可保护关键信息，以便在发生中断时进行恢复，从而维持业务连续性。Zoom 不会对外分享其完整的灾难恢复计划或详细测试结果，因为这些材料包含内部和敏感的机密商业版信息。请参阅 [Zoom 的信任中心](https://www.zoom.com/en/trust/legal-compliance/) 以了解有关公开可用文档的更多信息。 ### 测试 Zoom 通过由第三方审计师执行的年度桌面演练和故障转移测试来验证其恢复实践。这些测试确认响应和恢复流程是否按预期运行，识别差距，并通过吸取经验教训支持持续改进。测试涵盖了整个平台中广泛的产品和服务领域，包括 Zoom Meetings、Zoom Phone、Zoom 呼叫中心、Zoom Virtual Agent、Zoom Rooms、Zoom Events、白板、工作区预约，以及 RTC 和电话通讯网关等。结合本文所述的冗余主动-主动架构，这种分层方法旨在使 Zoom 的服务在各种中断条件下保持在线且可恢复。 ## **结论** Zoom 的可靠性由分层架构支持，该架构结合云优先服务设计、自适应媒体路由、冗余全球基础设施、容量规划以及正式的业务连续性和灾难恢复实践。涵盖 Meetings、Phone、呼叫中心、Zoom Node、全球数据中心及相关服务，Zoom 的平台旨在支持跨各种网络、区域、设备和部署模型的一致通信。支持日常服务质量的相同设计原则，也支持大规模弹性。主动-主动架构、智能路由、自适应传输、冗余设施、恢复规划、备份实践和定期测试协同工作，有助于维持基本服务，并在运营事件发生时支持恢复。对于客户和 IT 团队，此方法提供了一个平台，旨在于 UCaaS 和 CCaaS 环境中实现可靠通信、运营连续性和易于管理的企业版部署。 *作者：Jakob Ganschow 和 Sam Azimipour* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://library.zoom.com/technical-library/zh/guan-li-yuan-zhuan-qu/architecture-and-design/bcdr-whitepaper.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.