Stategraph旨在解决Terraform状态管理的根本问题，即使用文件系统语义处理分布式系统问题所导致的效率低下和复杂性。Terraform状态管理表现出数据表示与访问模式之间的不匹配，团队不得不采用复杂的工作区来应对。Stategraph将状态视为有向无环图，支持ACID事务和子图隔离，从而更高效地处理资源更新和协调问题。

为什么我们要构建Stategraph：将Terraform状态视为分布式系统问题

摘要

Terraform状态管理存在分布式协调问题，但当前解决方案依赖于文件系统原语。Stategraph通过将状态视为有向无环图，引入ACID事务和子图隔离，解决了这一问题。

背景

Terraform生态系统在过去十年中一直在解决一个根本性的架构不匹配问题：使用文件系统语义来解决分布式系统问题。这导致了可预测且痛苦的后果。随着我们开始大规模构建基础设施自动化，我们发现Terraform的状态管理表现出数据表示与访问模式之间的阻抗不匹配的典型症状。团队实施了越来越复杂的工作区：状态文件拆分、包装器编排、外部锁定机制。这些并不是解决方案，而是我们在解决错误问题的证据。

文件状态的问题

Terraform状态本质上是一个协调问题。多个参与者（工程师、CI系统、漂移检测）需要并发地读取和修改基础设施状态的重叠子集。这是一个在分布式系统中被深入研究的问题，已有关于细粒度锁定、多版本并发控制和事务隔离的解决方案。然而，Terraform实现了最简单的解决方案：对JSON文件的全局互斥锁。

观察

共享状态文件中的锁争用概率随着团队规模和资源数量的增加而超线性增长。在100个资源和5个工程师的情况下，通过单个互斥锁协调500个潜在的交互点。考虑典型的Terraform操作中的实际数据访问模式：

• 当前模型：tfstate.json（2.3MB），读取：100%，锁定：100%，修改：0.5%
• 实际需求：VPC、子网、RDS、ALB、ASG、SG，读取：3%，锁定：3%，修改：3%

操作粒度与锁定粒度之间的不匹配是每个Terraform扩展问题的根本原因。它违反了并发系统中的隔离基本原则：非重叠操作不应相互阻塞。

状态作为图：自然表示

基础设施状态本质上是一个有向图。资源具有依赖关系，形成边。更改沿着这些边传播。Terraform已经知道这一点：内部表示是一个图，规划器执行图遍历。但在存储层，我们将这种丰富的结构扁平化为一个blob。

通过适当的抽象实现并发控制

分布式系统社区几十年前就解决了这些问题。多版本并发控制（MVCC）允许读者在不阻塞写者的情况下进行。预写日志提供了持久性而不牺牲性能。事务隔离级别让操作员选择其一致性保证。

刷新问题

Terraform刷新在资源数量上是O(n)，无论更改范围如何。更改一个安全组规则，您仍然需要遍历整个状态。这是一个算法瓶颈，而不仅仅是实现细节。

为什么我们构建这个

在Terrateam，我们目睹了数百个团队在相同的基本问题上挣扎。他们从一个单一的状态文件开始，遇到扩展限制，拆分他们的状态，发现协调复杂性，构建编排层，最终屈服于忍受痛苦。

技术实现

Stategraph实现为一个PostgreSQL模式，后端支持Terraform/OpenTofu远程后端协议。我们选择PostgreSQL是因为其强大的MVCC、经过验证的可扩展性和操作熟悉性。模式将状态规范化为三个主要关系：

• 资源：每个资源一行，具有类型、提供者和属性列。
• 依赖关系：表示资源依赖关系图的边表。
• 事务：所有状态变动的仅追加日志，具有完整的归因。

采用路径

Stategraph读取现有的tfstate文件并自动构建图表示。不需要更改Terraform配置。后端协议未更改。从Terraform的角度来看，Stategraph只是另一个后端，如S3或GCS。

技术预览

Stategraph正在积极开发中。我们正在与设计合作伙伴合作，以验证大规模的方法。

获取更新

评论主要围绕Terraform的状态管理问题展开，观点分为支持和质疑两派。

支持观点： 1. 简化状态管理：Stategraph的解决方案被认为能够简化大规模资源管理，避免用户因性能问题而进行重构。 - "The major motivation is just how small scale Terraform/Tofu start to breakdown and creates work for users when they have to refactor for performance issues that shouldn't exist." (sausagefeet) - "Something like this could lead to a large shift in how we manage infrastructure." (time0ut)

2. 分布式图系统：将状态迁移到分布式图系统有助于解决大规模资源和多团队协作中的复杂问题。
   • "Moving tfstate to a real distributed graph system would help solve a LOT of the nasty hacks they mention in this article." (VectorLock)
   • "This is awesome. Having a single state for all resources in an environment is critical for keeping all the moving pieces in check." (pst)

质疑观点： 1. 状态文件的透明性：现有状态文件的简单性和透明性使得故障排除更容易，而新方案可能使状态变得不透明。 - "Its simpleness makes troubleshooting easier: the state files are easy to read and manipulate or repair in the event of a drift, mismatch, or botched provider update." (eschatology) - "With the solution proposed it feels like the state becomes a black box I shouldn’t put my hands in." (eschatology)

2. 访问控制和权限管理：集中式数据库可能带来团队间的资源访问控制问题。

   • "How do we prevent teams from making changes to stuff that isn’t theirs?" (alance)
   • "And if the answer is 'well this team only has IAM access to resources xyz', well then might it be a little tricky to represent the Stategraph DAG permission boundaries in IAM policy?" (alance)

3. 迁移和兼容性：现有大规模Terraform状态如何迁移到新系统，以及新系统与其他工具的兼容性仍存疑问。

   • "Biggest question I have is how users with large setups where Terraform state has already been split would migrate to this." (solatic)
   • "I’m curious if this will be compatible with tools like Spacelift or Env Zero." (sylens)

总体而言，Stategraph的提议在简化状态管理和提升大规模资源管理效率方面受到认可，但在状态透明性、访问控制和迁移兼容性等方面仍存在质疑。