📚 课程目录第3章 Terraform核心概念回顾

3. Terraform 核心概念回顾：Provider、Resource、Data Source、State、Module

在深入熔断器编排之前，必须牢固掌握 Terraform 的五大核心概念。它们是构建任何基础设施即代码（IaC）工作流的基石，也是实现容灾策略的基础设施抽象层。下面逐一拆解其定义、作用与协作关系。

3.1 核心概念总览与职责矩阵

下表从声明式配置的角度，对比了五个核心概念在 Terraform 生命周期中的角色与数据流向：

概念	声明方式	核心职责	是否可写	典型容灾场景
Provider	`required_providers`	封装云/服务 API，暴露资源类型与数据源	只读（插件）	多 Region 多 Provider 切换
Resource	`resource "type" "name"`	管理基础设施对象的完整生命周期（CRUD）	读写	熔断器、主备实例、DNS 记录
Data Source	`data "type" "name"`	查询外部只读信息，不创建或修改资源	只读	读取现有 VPC、镜像、熔断状态
State	后端配置（backend）	存储资源映射关系与属性快照	读写（后端）	远程锁、状态恢复、DR 备份
Module	`module "name"`	封装可复用的配置单元，支持输入输出	读写（调用）	标准化熔断器模板、多环境复用

3.2 Provider：基础设施的驱动层

Provider 是 Terraform 与目标平台之间的桥梁。每个 Provider 定义了一组 资源类型 和 数据源类型，并负责与云 API 进行认证与通信。在熔断器场景中，通常需要同时配置多个 Provider 实例以实现跨区域或跨云容灾。

  关键点： Provider 本身不管理状态，它只是声明“我能操作哪些资源”。通过 alias 属性可以在同一配置中定义多个同类型 Provider 实例，用于多区域部署。

# 多区域 Provider 配置示例
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
  alias  = "primary"
}

provider "aws" {
  region = "us-west-2"
  alias  = "dr"
}

3.3 Resource 与 Data Source：声明与查询

Resource 是 Terraform 配置的核心。每个 resource 块对应一个真实的基础设施对象，Terraform 负责其创建、更新、删除。在熔断器编排中，资源可以是计算实例、负载均衡器、DNS 记录或专门的熔断器配置对象。

Data Source 用于读取外部已有资源的信息，而不对其进行管理。例如，在创建熔断器之前，先通过 Data Source 查询当前主集群的健康状态或现有网络拓扑。

# Resource：创建一个 EC2 实例作为主节点
resource "aws_instance" "primary" {
  provider      = aws.primary
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  tags = {
    Name = "primary-app"
  }
}

# Data Source：查询当前可用区列表
data "aws_availability_zones" "available" {
  provider = aws.primary
  state    = "available"
}

容灾实践提示： 使用 Data Source 读取现有基础设施（如现有 VPC、子网、安全组），可以避免在 DR 配置中硬编码 ID，提升配置的可移植性。

3.4 State：基础设施的真相来源

State 文件是 Terraform 的核心状态数据库。它记录了每个被管理资源的 当前属性 与 Terraform 配置之间的映射关系。没有 State，Terraform 无法知道哪些资源已经存在，也无法执行增量变更。

在容灾场景中，State 的 远程存储 与 锁机制 至关重要：

远程后端（Backend）： 将 State 存储在 S3、GCS、Azure Storage 等共享存储中，确保团队协作与 DR 切换时状态一致。
状态锁（State Locking）： 防止并发操作导致状态损坏，DynamoDB 或 Consul 常被用作锁后端。
状态备份： 定期备份 State 文件，作为容灾恢复的基线。

# 远程 State 后端配置示例（S3 + DynamoDB 锁）
terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "dr/circuit-breaker.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

3.5 Module：可复用的容灾模板

Module 是 Terraform 实现代码复用的核心机制。一个 Module 可以包含一组相关的 Resource、Data Source 和变量定义，并对外暴露输入变量与输出值。在熔断器编排中，可以将 熔断器配置模板 封装为一个 Module，然后在主区域和 DR 区域分别调用，确保配置一致性。

# 调用熔断器 Module 示例
module "circuit_breaker_primary" {
  source = "./modules/circuit-breaker"

  providers = {
    aws = aws.primary
  }

  service_name    = "payment-service"
  failure_threshold = 5
  recovery_timeout  = 60
}

module "circuit_breaker_dr" {
  source = "./modules/circuit-breaker"

  providers = {
    aws = aws.dr
  }

  service_name    = "payment-service-dr"
  failure_threshold = 3
  recovery_timeout  = 30
}

3.6 概念协作关系图

下图展示了 Provider、Resource、Data Source、State 和 Module 在 Terraform 执行流程中的协作关系：

3.7 熔断器场景下的概念映射

将上述核心概念映射到熔断器容灾编排中，可以更直观地理解每个概念的实际用途：

Provider： 配置主区域（us-east-1）和 DR 区域（us-west-2）的 AWS Provider，或同时配置 AWS 与 GCP Provider 实现多云容灾。
Resource： 定义熔断器配置对象（如 AWS AppConfig 的 Feature Flag、自定义熔断器 Lambda 函数）、主备计算实例、健康检查端点。
Data Source： 查询现有 VPC 拓扑、当前熔断器状态（开启/关闭）、DNS 解析记录。
State： 存储所有熔断器相关资源的当前属性，支持远程锁防止 DR 切换时的并发冲突。
Module： 封装标准化的熔断器配置模板，包含输入变量（阈值、超时时间）和输出值（熔断器状态端点），在主区域和 DR 区域复用。

常见误区： 初学者常将 Data Source 当作 Resource 使用，试图通过 Data Source 修改外部资源。请记住：Data Source 是只读的，任何创建、更新、删除操作都必须通过 Resource 完成。