4、默认并行度分析：默认10并行的行为、适用场景、常见性能问题

Terraform 在默认情况下，对资源的创建、更新和删除操作采用 10 并行度（max_parallel = 10）。这意味着在执行 terraform apply 或 terraform destroy 时，最多允许 10 个资源同时进行状态变更。理解这一默认值的行为、适用边界以及潜在的性能陷阱，是进行服务目录性能调优的第一步。

4.1 默认10并行的行为机制

并行度控制的是 Terraform 工作线程的数量，每个线程负责处理一个资源的完整生命周期操作（包括与 Provider API 的交互）。其核心行为如下：

• 非严格并发：Terraform 不会同时启动所有 10 个线程。它会根据资源依赖图（DAG）逐步释放可并行执行的资源。只有那些没有相互依赖的资源才会被分配到空闲线程。
• 操作类型统一：并行度同时作用于创建、更新和删除操作。如果一个资源正在被删除，它同样占用一个并行槽位。
• 状态锁定：在并行执行期间，Terraform 会持有状态锁（通常存储在 S3/DynamoDB 或 Consul 中），防止其他执行计划干扰。

4.2 适用场景分析

默认 10 并行度并非万能配置，它在特定场景下表现良好，但在另一些场景下可能成为性能瓶颈或稳定性隐患。

4.3 常见性能问题

默认 10 并行度在实际生产环境中暴露出的问题主要集中在以下三个方面：

4.3.1 API 限速（Rate Limiting）

这是最常见且破坏性最强的问题。当 Terraform 的 10 个线程同时向同一个 API 端点发送请求时，云服务提供商会将其识别为异常流量，返回 HTTP 429 状态码。Terraform 默认会进行指数退避重试，但频繁的重试会进一步加剧 API 负载，形成恶性循环。

4.3.2 资源争抢与状态冲突

虽然 Terraform 的状态锁机制可以防止多个执行计划同时修改同一个状态文件，但在单个执行计划内部，10 个线程可能同时操作同一类共享资源（如同一个 VPC 下的子网、同一个 Kubernetes 集群下的命名空间）。这会导致：

• 隐式依赖未声明：资源 A 和资源 B 在 HCL 中没有显式 depends_on，但实际共享同一个底层 API 对象，并行操作可能导致竞态条件。
• Provider 端限流：即使 Terraform 自身没有报错，Provider 的 API 客户端也可能因为内部并发过高而抛出 ThrottlingException。

4.3.3 资源碎片化与执行时间不可预测

默认 10 并行度下，资源执行的顺序和完成时间高度依赖 DAG 的拓扑结构。如果依赖链中存在一个“瓶颈资源”（如一个需要 30 秒才能创建完成的数据库实例），那么即使其他 9 个线程空闲，整个执行计划也必须等待该资源完成。这导致：

• 长尾延迟：大部分资源在几秒内完成，但整个 apply 过程被少数几个慢资源拖长。
• 资源碎片化：频繁的并行执行会导致云账户中出现大量“半创建”或“半删除”的中间状态资源，增加运维复杂度。

4.4 默认并行度的性能基线

为了量化默认 10 并行度在不同场景下的表现，我们基于一个标准服务目录（包含 50 个资源，其中 30% 存在依赖关系）进行了基准测试：