Google PCA: 迁移、现代化与混合云策略 — 学习指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

属于 Google Professional Cloud Architect — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

一个成功的迁移、现代化和混合云战略，需要将平台选择与业务成果对齐，同时管理可用性、数据完整性、延迟、安全性和成本等方面的风险。该路径在快速平移（rehost）以降低数据中心风险与有针对性的重构（refactor）以获取云优势之间取得平衡。运营模式必须与技术同步发展，以维持改进。本节提供了一个实用的蓝图，涵盖评估和批次规划、决策框架、迁移机制、混合集成、现代化模式、策略和多云考量，以及迁移后优化，并重点关注故障模式和权衡。

评估、就绪度和批次规划

• 发现和依赖性分析

  • 清点工作负载、版本、操作系统内核、存储、IAM 和数据分类。绘制跨 web→API→DB 流程、共享服务 (LDAP/AD, DNS, NTP)、批处理管道和外部 API 的依赖关系图。
  • 在迁移前环境中使用应用性能剖析和分布式追踪，以发现隐藏的依赖关系和长尾延迟。开启 VPC Flow Logs 和应用级检测（Cloud Logging、Cloud Monitoring、Cloud Trace）。
  • 识别状态边界和数据引力：大小、访问模式（读/写混合）、一致性预期和复制拓扑。

• 就绪度和技能

  • 评估云基础、IaC、CI/CD、SRE、安全、网络和数据库技能。定义一个基于角色的培训和认证路线图，并为技能提升和影子待命（shadow on-calls）预留时间。
  • 在第一个迁移批次开始前，建立一个落地专区（项目、文件夹、Shared VPC、组织策略、审计汇、CMEK 策略）。

• 迁移批次规划

  • 根据亲和性和爆炸半径将应用分组到不同批次：共享数据、同步依赖和变更窗口。将高风险依赖项拉入同一批次，或用定义良好的 API 合约对其进行存根处理。
  • 为每个批次定义 SLO、RTO/RPO、回滚标准和验证门控（模式检查、综合用户旅程、性能阈值）。
  • 准备运行手册和变更管理：切换步骤、检查点、回滚和用于签核的证据收集。

• 兼容性、许可和性能基线分析

  • 验证 Compute Engine 和托管服务中的操作系统及中间件支持。检查商业许可条款、BYOL 限制、内核模块要求和硬件亲和性。
  • 捕获 CPU、内存、IOPS、吞吐量和延迟的基线，包括峰值和第 95 百分位值，以确定目标资源规模并验证收益。

• 数据治理

  • 对 PII/PCI 数据进行分类。规划在采集时使用 Cloud DLP 进行去标识化或令牌化。在存储第一条生产日志之前，定义审计、保留和导出策略。

常见故障模式：未知的同步依赖在切换后导致级联超时；IP 范围重叠导致连接中断；许可合规性差距；缺乏回滚对等性，导致数据突变无法撤销。

迁移模式、数据移动和切换

• 决策框架 (6R)

  • 重新托管 (Rehost)：原样迁移至 Compute Engine。上云速度最快，变更最少。风险：会带来技术债和不合理的规模配置。
  • 更换平台 (Replatform)：进行少量更改以采用托管服务（例如 Cloud SQL、Cloud Load Balancing）。代码更改少，可更快获得运维优势。
  • 重构 (Refactor)：为 GKE/Cloud Run 进行分解或容器化；采用事件驱动模式。长期收益最高，但存在交付风险。
  • 淘汰 (Retire)：在证明使用率和依赖关系不存在后，移除未使用的系统。
  • 保留 (Retain)：因法规或延迟原因保留在本地；通过混合云集成。
  • 搬迁 (Relocate)：将 vSphere 工作负载迁移至 Google Cloud VMware Engine；保留工具并最大限度地减少变更。

• 计算和数据库迁移工具

  • Migrate to Virtual Machines 可加速到 Compute Engine 的重新托管过程，同时保留磁盘和网络配置。验证客户机操作系统支持和内核驱动程序。
  • Database Migration Service 为 Cloud SQL 提供同构在线复制（例如 MySQL、PostgreSQL），实现低停机时间迁移。确保 binlog/复制设置正确，且延迟支持近乎实时的追赶。
  • 选择与工作负载匹配的数据库：
    • Cloud SQL 满足托管关系型数据库需求；启用存储自动增长，监控每个核心的 CPU 使用率接近 75%；跟踪复制延迟，在接近阈值时进行分片或纵向扩容。
    • Bigtable 用于低延迟、高吞吐量的时间序列数据注入（例如传感器数据）。
    • Spanner 用于全球规模和强一致性；理解厂商锁定与可移植性之间的权衡。
  • 数据移动
    • Storage Transfer Service 用于持续或计划性的传输；支持并行化和重试。
    • Transfer Appliance 用于一次性批量加载（数十到数百 TB），以减少网络传输时间和风险。
    • gsutil 和并行复合上传用于中小型数据集。

• 在线与离线迁移

  • 在线：持续复制，切换时间短。优点：停机时间最短；缺点：需要稳定的延迟和带宽；需谨慎避免双写。
  • 离线：快照和批量导入。优点：简单且可预测；缺点：停机时间等于复制持续时间。

• 切换规划、回滚和停机时间控制

  • 在切换前几天降低 DNS TTL，冻结非必要变更，并安排维护窗口。
  • 执行验证关卡：模式一致性、校验和或行数检查、应用冒烟测试、金丝雀流量和性能探测。
  • 回滚：确保向后兼容的模式变更、功能标志，并保留真实数据源。在证明稳定性之前，避免不可逆的写入操作。
  • 以最小停机时间扩展虚拟机磁盘的示例：
    • 在控制台或 CLI 中调整磁盘大小：

undefined

- 在 Linux ext4 上：

undefined

• 在 GKE 上以最小影响进行应用滚动更新：

undefined

常见故障模式：Cloud VPN 上的数据包丢失中断数据库复制（应使用 Dedicated Interconnect 或 Partner Interconnect）、切换期间的双写数据不一致、缺少健康检查导致滚动更新中止。

混合身份、连接和本地集成

• 身份

  • 保留 Active Directory 作为唯一真实数据源。使用 Google Cloud Directory Sync 进行帐号和群组同步，并配置 SAML SSO 以便用户访问 Google Cloud。
  • 通过角色授予最小权限 IAM，为工作负载使用服务帐号，并优先选择 Workload Identity Federation 而非长期有效的密钥。

• 混合连接和路由

  • 对于初始的低吞吐量需求和测试，使用 Cloud VPN；为获得持续的带宽、更低的延迟和可预测的复制性能，迁移到 Dedicated Interconnect。部署冗余的 VLAN 连接和 HA VPN 或双互连以实现弹性。
  • 确保 Google Cloud 的 IP 范围不与本地 CIDR 重叠，以保持端到端的可达性。

  • 使用防火墙规则和标签强制执行分层访问。例如，仅允许 web→API 的访问：

undefined

• 使用 Private Service Connect 和专用 Google 访问进行服务间通信，无需公共出口；在适当情况下使用 VPC Service Controls 进行分段。

• 混合 DNS：使用 Cloud DNS 的转发以及入站/出站策略来解析本地和云端的名称。

• 本地集成和延迟

  • 保持状态与计算资源彼此靠近；如果本地数据库必须保持权威性，可考虑使用 App Engine flexible 或 Compute Engine，并通过 Cloud VPN/Interconnect 进行私有访问。
  • 引入缓存和队列来解耦同步路径并吸收延迟抖动；测量 p95/p99 延迟，而不仅仅是平均值。

常见故障模式：CIDR 重叠导致路由阻塞、BGP 会话冗余不足、公共 DNS 或出口泄漏暴露了私有服务、以及未预料到的“话痨”协议在高延迟链路上性能不佳。

现代化、运营模型与优化

• 遗留系统现代化模式

  • 绞杀榕模式：在单体应用前放置一个 API 外观层，然后逐步将各个域的路由指向新服务。
  • 容器化：标准化基础镜像（在兼容的情况下优先选择 Alpine 等精简镜像），优化 Dockerfile 层顺序以缓存依赖安装（在复制源代码之前），从而减少构建时间，并采用包含暂存环境自动化测试的 CI/CD 管道。
  • 托管数据：将操作型存储迁移到托管数据库；按域选择：Cloud SQL 用于事务性负载，Bigtable 用于时间序列数据，Spanner 用于全球一致性工作负载。

• 应用兼容性、一致性与性能验证

  • 确认操作系统和中间件支持、线程和连接限制以及文件系统语义。验证许可证的可移植性和使用计量方式。
  • 定义数据一致性要求（写后读、单调读、最终一致性 vs 强一致性）。使其与目标数据库和访问模式对齐。
  • 通过负载测试和综合用户旅程验证性能；确保迁移后 SLO 预算是可实现的。

• 可观测性与合规性

  • 使用 Cloud Logging、Monitoring 和 Trace 对应用进行插桩，以定位跨微服务的延迟。
  • 将审计日志和 IAM 策略变更导出到 BigQuery，并通过视图和数据集上的 IAM 与审计员共享。将长期指标导出到 Cloud Storage，以满足多年的保留要求。

• 运营模型与所有权

  • 采用 SRE 实践：SLO、错误预算、事件响应和无指责的事后复盘。定义服务所有权、运行手册和待命轮换。
  • 使用 IaC（例如 Terraform）来一致地配置基础设施。请注意，Deployment Manager 是 Google 特有的，可能会限制多云资源的自动化，并且许多工程师对此不熟悉。
  • 通过 Organization Policy、IAM Conditions、Config Sync 和 Policy Controller (OPA Gatekeeper) 在跨项目和环境中自动化策略一致性。

• 多云战略与厂商锁定的权衡

  • 通过 Kubernetes、12-factor 应用实践、OpenAPI 定义的契约以及数据出口抽象来提高可移植性。在可移植性与运营负担和性能之间取得平衡；托管服务可以减少繁琐工作，但可能会增加切换成本。

• 成本与性能优化；系统下线

  • 使用托管实例组和自动扩缩来扩展无状态的 Compute Engine；对于受益于缩容至零的突发性或 MVP 工作负载，选择无服务器（Cloud Functions 或 Cloud Run）。
  • 合理调整 VM 规模，在 GKE 上启用自动扩缩，应用承诺使用折扣，并停用未使用的构件。通过 KPI（可用性、延迟、服务成本）跟踪收益实现情况。
  • 在经过冷却期并确认依赖关系后，下线本地系统。根据保留策略归档或删除数据，并更新 CMDB。

实践问题场景

Acme 气象网络公司必须将其リアルタイム传感器平台和一个遗留的 J2EE 管理界面从本地数据中心迁移到 Google Cloud。该系统从 50,000 个传感器注入数据，每个传感器每秒发送 10 个读数，并存储五年的历史数据（75 TB）。在过渡期间，它必须保持对本地 ERP 和 Active Directory 的私有访问，最大限度地减少本地 MySQL 数据库的停机时间，并消除通过 VPN 观察到的间歇性复制失败问题。

1. 建立安全着陆区

   • 创建组织、文件夹以及生产/非生产项目。设置一个 Shared VPC，其 IP 范围不与本地重叠，以确保通过混合连接实现本地可达性。应用组织策略并将审计日志集中导出到 BigQuery，并配置最小权限访问。
   • 理由：在工作负载部署之前，防止路由冲突并强制执行基线治理。

2. 实施混合身份

   • 配置 Google Cloud Directory Sync 以同步 AD 身份和组，并设置 SAML SSO。为平台和工作负载使用服务账号和 IAM 自定义角色。
   • 理由：保留企业身份作为事实来源，并实现最小权限访问控制。

3. 配置连接并规划性能

   • 开发/测试环境先使用 HA Cloud VPN。对于生产数据库复制和稳定的传感器数据注入，配置 Dedicated Interconnect，并配备双 VLAN 连接和 BGP 会话。
   • 理由：Interconnect 提供比 VPN 更低的延迟和更少的数据包丢失，从而稳定 MySQL 复制和流式数据注入。

4. 高效迁移历史数据

   • 订购 Transfer Appliances，在本地加载 75 TB 数据集，然后运送并在 Cloud Storage 中恢复数据。如果需要，使用 Storage Transfer Service 进行持续的增量更新。在存入 Bigtable 或 BigQuery 之前，对支持日志运行 Cloud DLP 以对 PII 进行去标识化处理。
   • 理由：离线批量传输可降低切换窗口风险，并避免网络链路饱和。

5. Rehost J2EE 管理界面

   • 使用 Migrate to Virtual Machines 将 J2EE VM 直接迁移到 Compute Engine。将实例放置在 HTTP(S) 负载均衡器后面的托管实例组中。通过标签应用防火墙规则，以强制执行仅限 web→API→DB 的流量流向。例如：

undefined

• 理由：通过熟悉的运行时环境快速降低风险，同时强制执行最小权限网络路径。

6. 以最短停机时间将 MySQL 迁移到 Cloud SQL

   • 在源端进行性能基准测试并启用二进制日志。使用 Database Migration Service 设置到 Cloud SQL 的持续复制。启用存储空间自动增加，并为 CPU 接近 75% 和复制延迟低于 60 秒创建警报。
   • 理由：在线迁移可实现低停机时间；托管 SQL 可减少繁琐工作并强制执行运营 SLO。

7. 执行受控切换

   • 提前 48 小时降低 DNS TTL，冻结 schema 变更，并安排维护窗口。停止本地写入，确保 DMS 延迟为零，运行校验和及应用冒烟测试，然后将客户端指向 Cloud SQL。维护一个回滚计划，以便在验证失败时可以将写入重定向回本地。
   • 理由：确定性的步骤可限制 RTO 并保持数据一致性。

8. 构建实时遥测数据注入管道

   • 通过 Pub/Sub 注入数据，使用 Dataflow 进行处理，并将时间序列数据存储在 Bigtable 中以实现低延迟的写入和读取。通过 Interconnect 保持与 ERP 的集成是私有的。
   • 理由：Bigtable 匹配高吞吐量的时间序列场景，而 Pub/Sub 将突发性的生产者与消费者解耦。

9. 容器化服务并引入 CI/CD

   • 为 GKE 容器化无状态服务。通过使用精简基础镜像和优化层顺序（使依赖安装先于源代码复制）来优化 Dockerfile。实施一个 CI/CD 管道，包含在暂存环境的自动化测试和金丝雀部署。以最短停机时间进行更新：

undefined

• 理由：在无需进行颠覆性重构的情况下，提高部署速度、可靠性和可扩展性。

10. 增强可观测性与审计

    • 使用 Cloud Logging、Monitoring 和 Trace 进行插桩，以精确定位跨微服务的延迟。将审计日志导出到 BigQuery，并共享限定了审计员范围的视图。将长期指标导出到 Cloud Storage，以满足五年的保留要求。
    • 理由：全保真遥测数据为 SLO 和合规性提供支持。

11. 优化与下线

    • 在 MIG 和 GKE 上启用自动扩缩，合理调整实例规模，应用承诺使用折扣，并将非 24x7 的工作负载（例如辅助任务）安排在无服务器上（如 Cloud Functions）以实现缩容至零。在系统稳定并经过冷却期后，下线本地系统，更新 CMDB，并公布已实现的收益。
    • 理由：在消除双重运行开销的同时，实现成本和运营效率。

12. 投入运营与培训

    • 最终确定运行手册、RACI、待命轮换以及 SLO/错误预算。提供有针对性的培训和认证计划以弥补技能差距。优先使用 Terraform 作为 IaC 工具；注意 Deployment Manager 是 Google 特有的，可能无法处理非 Google 资源。
    • 理由：成熟的运营模型能够在迁移事件之后持续保持可靠性和开发速度。

← 可靠性、灾难恢复与业务连续性 · 所有领域 · 运维、可观测性与平台自动化 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Google →