Google Distributed Cloud 是什么，无法全部迁移到公有云的企业可以怎样部署

企业数字化转型并不意味着所有应用、数据库和业务数据都必须迁移到公有云。金融交易、工业控制、医疗数据处理以及对网络延迟要求较高的业务，可能受到法规、系统兼容性、数据传输成本和业务连续性等因素限制，需要继续运行在企业自己的数据中心或现场设备中。对于这类企业，如何在保留本地基础设施的同时使用云计算、容器和人工智能能力，是云架构规划的重要问题。

Google Distributed Cloud（谷歌分布式云）正是为不同地点的计算需求提供基础设施和软件支持的一组解决方案。它可以将 Google Cloud 的部分基础设施、服务和 Kubernetes 容器平台扩展到企业数据中心及边缘环境，但并不意味着所有部署都采用同一种架构，也不意味着本地系统必须完全依赖公有云运行。企业需要根据数据主权、网络连接、硬件管理方式和应用需求，选择适合的部署形态。

一、Google Distributed Cloud 有哪些部署方式

Google Distributed Cloud 并非单一产品，而是包含多种部署形态的产品组合。根据 Google Cloud 官方文档，主要方向包括连接式部署、隔离式部署，以及运行在企业自有硬件上的纯软件部署。

连接式部署（Google Distributed Cloud connected）采用经过 Google 认证的专用硬件，部署在企业数据中心或边缘位置，并与 Google Cloud 保持连接。企业可以在本地运行 Kubernetes 容器和虚拟机工作负载，由 Google Cloud 提供集中管理能力。这种方式适用于需要低延迟处理、希望减少大量原始数据上传，或者需要在本地网络中运行计算任务的场景。

隔离式部署（Google Distributed Cloud air-gapped）面向不能依赖公共互联网或 Google Cloud 连接的环境。其硬件和软件可以在隔离的本地环境中运行，适用于具有严格数据主权、安全隔离或合规要求的场景。这种部署并不要求持续连接 Google Cloud，但也意味着企业需要认真规划本地的软件更新、安全维护、监控和恢复机制。

纯软件部署（Google Distributed Cloud software only）则允许企业在自己的物理服务器或现有 VMware 基础设施上运行相应的软件。它以 Google Kubernetes Engine（GKE）相关技术为基础，将企业本地的 Kubernetes 集群纳入相应的管理体系。对于已经拥有数据中心、虚拟化平台和服务器设备的企业，这种方式可以减少购买专用硬件的需求，但仍需评估平台要求、部署复杂度和运维能力。

这三类方式解决的问题并不相同。企业如果需要本地低延迟计算，同时希望使用云端管理能力，可以研究连接式部署；如果系统必须在完全断网的情况下运行，应重点考察隔离式方案；如果企业希望继续使用现有服务器和虚拟化设施，则可以评估纯软件部署。不能仅凭“混合云”三个字，就假定所有功能、连接条件和管理方式都完全相同。

二、企业应该怎样划分本地与公有云的工作负载

部署之前，企业首先应按照业务要求划分工作负载，而不是先购买硬件，再寻找适合运行的应用。

对于生产控制、实时设备监测、现场视频分析和工业物联网（IIoT）等业务，数据产生位置与计算位置之间的距离可能直接影响响应时间。把处理任务放在工厂、门店或现场数据中心，可以减少数据往返公有云产生的网络延迟，也能避免持续传输大量原始数据所带来的带宽开销。

对于需要弹性扩展、跨地区访问或使用托管数据分析服务的应用，公有云通常更容易提供相应资源。企业可以将经过筛选的数据、分析结果和业务汇总信息传送到 Google Cloud，再利用云端计算和存储能力开展后续处理。

例如，制造企业可以在工厂本地处理设备传感器数据，及时识别异常，并将设备运行摘要和经过筛选的数据传到云端，供多个工厂进行集中分析。零售企业可以在门店附近处理部分视频和设备数据，只将业务所需的结果发送到中心平台。具体能否这样部署，仍取决于选定产品支持的工作负载、数据接口和应用设计。

对于受监管的数据，企业还必须明确数据存储位置、传输路径、访问权限、加密方式和备份位置。将计算节点放在本地，并不自动代表所有数据都符合本地化要求。如果日志、备份、遥测信息或应用输出仍然传往外部环境，就需要逐项核查相关的数据流向和合同要求。

三、网络架构不能只考虑带宽和延迟

混合云环境通常涉及企业局域网、数据中心网络、互联网连接、云端虚拟私有云以及不同地点之间的通信。网络设计不仅决定应用响应速度，也影响身份验证、系统管理、数据同步和故障恢复。

对于连接式 Google Distributed Cloud，企业需要规划本地网络与 Google Cloud 之间的连接，并根据部署要求配置相关网络组件。官方文档说明，连接式部署通过安全的 Cloud VPN 连接访问 Google Cloud 服务及相关虚拟私有云资源；实际网络方案应依据产品要求和企业网络拓扑确定。

设计时应区分业务流量与管理流量，明确哪些系统需要访问本地应用，哪些工作负载需要调用云端服务，以及连接中断时哪些业务必须继续运行。对大量数据传输的场景，还应估算持续带宽、峰值流量、数据传输费用和同步积压量。

DNS、负载均衡和应用故障切换也需要分别设计。DNS 主要负责将域名解析为相应地址，负载均衡器负责按照配置将流量分配给后端服务，两者不能相互替代。DNS 缓存和 TTL 会影响地址变更后的客户端行为，但降低 TTL 并不能保证所有客户端立即切换。若应用需要跨地点快速切换，应综合考虑健康检查、路由策略、连接状态和应用自身的恢复能力。

四、容灾设计必须明确 RTO 和 RPO

混合云架构并不天然具备高可用性。即使企业同时拥有本地服务器和云端资源，如果数据库没有复制、应用无法在备用环境启动，或者身份验证服务仍然依赖故障中的系统，发生故障时依然可能无法恢复业务。

因此，企业应先定义恢复时间目标（RTO）和恢复点目标（RPO）。RTO 表示业务中断后希望在多长时间内恢复；RPO 则表示企业能够接受多大程度的数据回退。不同业务的目标可能差异很大，不能对所有应用设定统一数值。

对于允许短暂停机的内部报表系统，可以采用定期备份和经过验证的恢复流程。对于关键交易系统，则可能需要持续数据复制、备用计算资源、自动化健康检查和经过演练的故障切换流程。

主动—主动（Active-Active）架构可以让多个环境同时承载业务流量，但并非所有应用都适合直接采用。数据库写入冲突、会话状态、数据一致性、网络分区和重复执行操作，都可能增加设计难度。企业必须明确流量如何分配、数据如何同步，以及在网络中断时由哪个系统继续提供服务。

同样，备用环境如果与主环境共享同一电源、网络出口或基础设施故障域，就可能在同一次事故中同时失效。容灾规划应从实际故障范围出发，而不是仅凭部署了两套系统就认定具备完整的灾难恢复能力。

五、成本与运维能力决定方案是否值得采用

采用分布式云架构，可能减少部分数据传输成本、改善本地响应时间，并延续企业已有的基础设施投资，但不代表整体成本一定低于公有云。企业仍需考虑硬件采购或租用、机房空间、电力、网络、安全维护、软件许可、技术支持以及人员培训等支出。

连接式部署可以减少企业自行管理底层硬件和部分软件维护工作的负担，但企业仍然需要负责自身网络、应用部署和业务运行。纯软件部署可以利用已有服务器，却也意味着企业必须具备相应的基础设施管理、集群运维、升级和故障处理能力。隔离式环境则需要特别规划离线更新、漏洞修复、软件包验证和本地监控。

因此，企业不宜只比较每月云资源账单，而应按完整业务周期计算总拥有成本（TCO）。对于数据量很大、延迟要求严格的应用，本地计算可能更有经济价值；对于访问量变化明显、没有严格本地化要求的应用，公有云可能更容易扩展。最终结果取决于实际资源使用量、服务要求和维护成本。

六、企业可以采用分阶段部署路线

实施时，可以先选择一项业务边界明确、风险可控的应用进行试点，验证网络连接、身份权限、监控、数据备份和故障恢复流程。试点不应只测试正常运行，还应模拟网络中断、节点故障、存储异常和云端服务暂时不可用等情况，确认系统是否符合预定的恢复目标。

试点通过后，再逐步迁移适合本地运行的容器化应用，统一日志、监控、配置管理和安全策略。对于暂时无法容器化的传统应用，可以继续留在现有虚拟机或物理服务器上，不必为了采用分布式云而强行重构全部系统。

在扩大部署范围之前，还应明确谁负责硬件、网络、操作系统、集群平台、应用和数据安全，并建立升级、补丁、备份及事故响应流程。尤其对于连接式部署，企业必须了解其对 Google Cloud 连接和集中管理的依赖；对于隔离式部署，则应确认完全断网时的运行和维护方式是否符合业务要求。

Google Distributed Cloud 为无法全面迁移公有云的企业提供了多种本地化部署选择，但真正的价值不在于把所有系统都搬到某一种新平台，而在于让不同工作负载运行在更符合其要求的位置。企业只有明确数据边界、连接依赖、容灾目标和长期运维成本，才能在本地控制能力与云端服务之间建立可持续的架构。