📚 课程目录第3章 Google Cloud 概览

3、Google Cloud 概览：GCP 核心服务、项目与计费设置、IAM 基础、Cloud Console 与 Cloud Shell 使用

Google Cloud Platform（GCP）是 Google 提供的全球性云计算平台，其底层基础设施与 Google 搜索、YouTube 等产品同源，具备全球化的网络骨干网、领先的数据分析能力（BigQuery）以及强大的 Kubernetes 原生支持。对于 IoT 解决方案而言，GCP 提供了从设备接入（Cloud IoT Core）、流式数据处理（Pub/Sub、Dataflow）、存储（Cloud Storage、Bigtable）到机器学习（Vertex AI）的完整闭环。理解 GCP 的核心服务、资源组织方式、权限模型以及日常操作工具，是构建可靠、安全且成本可控的 IoT 应用的第一道门槛。本章将围绕这四个基础模块展开，帮助您建立清晰的 GCP 全局视图。

上图展示了 GCP 资源层级（组织-文件夹-项目）与核心服务、IAM、计费及操作工具之间的逻辑关系。在后续内容中，我们将逐一拆解这些模块，并重点说明它们在 IoT 场景下的应用方式。

3.1 GCP 核心服务：构建 IoT 解决方案的积木

核心原理：从设备到数据的全链路服务

GCP 提供了超过 100 种云服务，但对于 IoT 场景，我们通常关注以下五类核心服务：接入类（Cloud IoT Core 或 MQTT Broker）、传输类（Pub/Sub）、存储类（Cloud Storage、Cloud Bigtable）、分析类（BigQuery、Dataflow）以及可视化/行动类（Looker、Cloud Functions）。这些服务遵循“无服务器优先”的设计理念，允许开发者专注于业务逻辑而非基础设施运维。

服务类别	典型服务	在 IoT 中的角色	关键特性
设备接入	Cloud IoT Core	设备身份认证、注册、遥测数据上报	支持 MQTT/HTTP，自动扩展，与 Pub/Sub 原生集成
消息传递	Pub/Sub	解耦设备数据与下游处理系统	至少一次投递，支持消息重放，全球低延迟
数据存储	Cloud Storage / Bigtable	存储原始设备日志、图片或时序数据	Storage 适合冷热数据分层；Bigtable 适合高吞吐写入
流式处理	Dataflow / Pub/Sub Lite	实时清洗、聚合、窗口计算	基于 Apache Beam，支持事件时间处理
分析/ML	BigQuery / Vertex AI	离线分析、异常检测、预测性维护	BigQuery 按扫描字节计费，Vertex AI 提供 AutoML

判断方法：如何选择合适的数据管道

在 IoT 项目中，一个常见的困惑是“我应该把数据先存到 BigQuery 还是先经过 Dataflow？”判断依据是数据的时效性与查询模式。如果设备数据需要实时告警（如温度超限），则必须经过 Pub/Sub 触发 Cloud Functions 或 Dataflow 流式作业；如果数据仅用于每日报表，则可以直接通过 Cloud IoT Core 写入 BigQuery 的流式插入接口。此外，对于高频采样的传感器（如每 100ms 一次），建议使用 Bigtable 作为热存储，再通过导出作业将历史数据转存至 BigQuery 进行复杂分析。

经验提示：在项目初期，不要过度设计。先用 Cloud IoT Core + Pub/Sub + BigQuery 搭建最小可行链路，后续再根据延迟和成本需求引入 Dataflow 或 Bigtable。GCP 的托管服务可以随时升级，但重构数据管道代价较高。

案例拆解：智能工厂设备监控的 GCP 架构

假设某工厂需要监控 5000 台数控机床的振动、温度和功耗数据。每台设备每 5 秒上报一次 JSON 数据。初始方案是直接使用 Cloud IoT Core 将数据转发至 Pub/Sub，然后由 Dataflow 作业进行 1 分钟窗口的均值计算，结果写入 BigQuery 用于仪表盘展示。同时，Cloud Functions 订阅 Pub/Sub 中的异常主题（如温度 > 85°C），触发告警邮件。该架构在 5000 台设备并发上报时，Pub/Sub 的吞吐量稳定在 1000 条/秒，端到端延迟小于 2 秒。关键参数：Dataflow 作业使用 2 个 worker，每个 worker 4 vCPU，月度成本约 320 美元。复盘发现，若将原始数据直接写入 BigQuery 而不经过 Dataflow，查询成本会因扫描全量原始数据而增加 40%，因此流式预处理是必要的。

常见误区与总结

误区一：认为 Cloud IoT Core 是唯一接入方式。实际上，如果设备已支持标准 MQTT 协议，也可以直接连接到 Cloud Pub/Sub 的 MQTT 端点（需自行处理鉴权）。
误区二：忽略 Pub/Sub 的“至少一次”投递特性。下游消费者必须实现幂等性，否则重复消息会导致数据重复计数。
误区三：将所有数据都存为结构化格式。对于图像或音频数据，应优先使用 Cloud Storage 存储原始文件，仅在 BigQuery 中保存元数据索引。

3.2 项目与计费设置：资源隔离与成本控制

核心原理：项目是资源隔离与计费的基本单元

在 GCP 中，项目（Project） 是所有云资源的容器。一个项目拥有独立的资源命名空间、IAM 策略和计费账户。项目可以归属于组织节点下的文件夹，形成层级结构。计费方面，每个项目必须关联一个结算账户（Billing Account），所有在该项目中创建的资源（虚拟机、存储桶、API 调用）都会按使用量产生费用，并汇总到该结算账户下。合理的项目规划是成本管理和权限控制的第一步。

操作流程：创建项目并设置预算告警

登录 Cloud Console，点击右上角项目下拉框，选择“新建项目”。
填写项目名称（如 iot-dev-project），系统会自动生成唯一的项目 ID（如 iot-dev-project-123456）。
在“结算”部分，关联一个有效的结算账户。如果没有，需先创建并绑定信用卡或公司账户。
启用必要的 API（如 Cloud IoT API、Pub/Sub API）。
进入“结算” > “预算和警报”，创建预算。例如设置月度预算 $500，并配置 50%、90%、100% 的阈值告警，通过邮件或 Pub/Sub 通知。

# 使用 gcloud 命令创建项目（Cloud Shell 中执行）
gcloud projects create iot-dev-project-123456 --name="IoT Development Project"
# 关联结算账户
gcloud billing projects link iot-dev-project-123456 --billing-account=0X0X0X-0X0X0X-0X0X0X
# 启用所需 API
gcloud services enable cloudiot.googleapis.com pubsub.googleapis.com

案例拆解：多环境项目规划

一家 IoT 初创公司需要管理开发、测试和生产三个环境。他们创建了三个项目：iot-dev、iot-staging、iot-prod。开发项目使用免费试用额度，测试项目关联月度预算 $200，生产项目预算 $2000 并设置了 80% 告警。通过使用标签（Labels）（如 env=prod、team=gateway），他们可以在结算报告中按标签维度分析成本。例如，发现生产项目中“Cloud IoT Core 连接时长”费用占比高达 60%，于是优化了设备的心跳间隔，从每 30 秒一次调整为每 5 分钟一次，月度成本降低了 35%。

风险提示：不要在生产项目中随意启用未使用的 API 或创建大规格虚拟机。GCP 的计费是按秒计费，但持续运行的资源（如 Compute Engine）会快速累积成本。建议为所有资源设置命名规范，并定期使用 gcloud billing projects describe 检查消费情况。

常见误区与总结

误区一：将多个环境（开发/生产）放在同一个项目中。这会导致权限无法隔离，且误操作可能影响生产服务。
误区二：忽略配额（Quotas）。GCP 对每个项目有默认配额（如 Pub/Sub 每秒发布消息数），超过配额会报错。需提前在 IAM 与管理 > 配额页面申请提升。
误区三：不使用预算导出。将账单导出到 BigQuery 可以实现自定义分析，例如按设备 ID 或区域分析成本，这是官方推荐的做法。

3.3 IAM 基础：最小权限原则

核心原理：谁在什么条件下能对哪个资源做什么

Cloud IAM（Identity and Access Management）是 GCP 的权限管理服务。其核心模型包含三个要素：成员（Principal）、角色（Role） 和 策略（Policy）。成员可以是 Google 账号、服务账号、Google 群组或 Cloud Identity 域。角色是权限的集合，分为三类：基础角色（Owner/Editor/Viewer，较为宽泛）、预定义角色（如 roles/pubsub.publisher，精细控制）和自定义角色（按需组合权限）。策略则绑定在资源层级（组织、文件夹、项目或单个资源）上，支持条件表达式（如仅允许在特定时间访问）。

操作流程：为 IoT 设备创建服务账号

设备通常不能使用个人账号访问 GCP，而应使用服务账号（Service Account）。以下是标准流程：

在 IAM 与管理 > 服务账号中创建服务账号，例如 iot-device-sa@project.iam.gserviceaccount.com。
为该服务账号授予必要的角色。对于仅上报数据的设备，只需授予 roles/pubsub.publisher（发布消息权限）。
生成密钥（JSON 格式），并安全地烧录到设备中。注意：密钥文件必须妥善保管，泄露可能导致恶意数据注入。
在 Cloud IoT Core 中注册设备时，绑定该服务账号，设备即可通过 JWT 或 OAuth2.0 令牌进行身份验证。

# 创建服务账号
gcloud iam service-accounts create iot-device-sa --display-name="IoT Device SA"
# 绑定角色（仅授予发布权限）
gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:iot-device-sa@my-project.iam.gserviceaccount.com" \
  --role="roles/pubsub.publisher"
# 生成密钥文件
gcloud iam service-accounts keys create ./sa-key.json \
  --iam-account=iot-device-sa@my-project.iam.gserviceaccount.com

案例拆解：权限过大导致的故障

某团队在开发阶段为了方便，给所有设备使用了同一个拥有 roles/editor 权限的服务账号。上线后，一台被黑客入侵的设备利用该账号的权限，删除了项目中的 Cloud Storage 存储桶，导致历史数据丢失。复盘发现，该设备本应只拥有 roles/pubsub.publisher 权限。修复措施包括：为每台设备或每组设备创建独立服务账号，并启用 IAM 条件（如仅允许从特定 IP 范围访问）。这次事故的教训是：最小权限原则不是可选项，而是安全底线。

  最佳实践：使用 IAM 建议器（IAM Recommender）定期检查项目中的过度授权角色。该工具基于机器学习分析实际使用情况，提示哪些权限在过去 90 天内未被使用，可安全移除。

常见误区与总结

误区一：使用基础角色（Owner/Editor）代替预定义角色。基础角色权限范围过大，例如 Editor 可以修改所有资源，包括删除数据库。
误区二：将服务账号密钥放在代码仓库中。应使用 Secret Manager 存储密钥，或使用 GKE Workload Identity 等更安全的机制。
误区三：忽略 IAM 条件。对于 IoT 场景，可以设置条件如 resource.service == "pubsub.googleapis.com" 来限制服务账号只能操作 Pub/Sub。

3.4 Cloud Console 与 Cloud Shell：日常操作双引擎

核心原理：图形界面与命令行互补

Cloud Console 是 GCP 的 Web 管理界面，适合浏览资源状态、配置可视化策略、查看日志和监控图表。它提供了上下文感知的帮助面板，对于新手友好。Cloud Shell 是一个基于浏览器的 Linux Shell 环境，预装了 gcloud、kubectl、docker 等工具，并提供了临时的 5GB 主目录。Cloud Shell 的最大优势是无需本地安装 SDK，且自带认证信息，开箱即用。两者互补：Console 适合“看”，Shell 适合“做”。

操作流程：使用 Cloud Shell 管理 IoT 资源

在 Cloud Console 顶部点击激活 Cloud Shell 按钮（图标为 >_），等待环境初始化。
验证身份：gcloud auth list 确认当前账号。
设置默认项目：gcloud config set project iot-dev-project-123456。
使用命令查看 IoT 设备注册表：gcloud iot registries list --region=us-central1。
使用 Cloud Shell 编辑器（cloudshell edit）直接修改配置文件，并部署到 Cloud Functions。

效率技巧：Cloud Shell 支持 Web Preview 功能，可以预览运行在 Cloud Shell 虚拟机上的 Web 应用（如 Dataflow 的 UI）。此外，Cloud Shell 的临时性意味着不适合存放长期数据，但可以用于快速测试脚本。

案例拆解：通过 Cloud Shell 批量更新设备配置

假设需要将 1000 台网关设备的固件版本从 v1.0 升级到 v1.1。在 Cloud Shell 中，可以编写一个 Bash 循环，调用 gcloud iot devices update 命令，为每个设备更新元数据或配置。关键点：使用 --device-config 参数推送新的配置数据（如 MQTT 主题映射）。该操作在 10 分钟内完成，而如果通过 Console 手动操作，每台设备需要约 2 分钟，总计超过 3 小时。此外，Cloud Shell 的日志输出可以重定向到文件，便于后续审计。

常见误区与总结

误区一：在 Cloud Shell 中运行长时间任务（如持续的数据流作业）。Cloud Shell 有 20 分钟空闲超时限制，适合短时操作，长任务应使用 Compute Engine 或 Cloud Build。
误区二：忽略 Console 的“活动日志”功能。所有操作（包括通过 Console、Shell、API 执行的操作）都会记录在 Logging 中，这是排查误操作的关键线索。
误区三：不使用 Console 的“导航菜单”搜索功能。直接输入服务名称（如“IoT Core”）可以快速跳转，比手动浏览菜单更高效。

通过本章的学习，您已经掌握了 GCP 的全局框架：核心服务如何协同工作、项目与计费如何规划、IAM 如何保障安全，以及如何利用 Console 和 Shell 高效操作。这些知识是后续深入学习 Cloud IoT Core 设备接入、数据流处理以及边缘计算的基础。请务必在您的 GCP 环境中动手实践，创建第一个项目并部署一个模拟设备，以巩固这些概念。