编辑发布分离

在过去一年左右的时间里，我与 Thoughtworks 项目团队的交谈中，一个经常出现的主题是内容管理系统 (CMS) 的日益增长的影响。它们通常不被认为是有帮助的，事实上，有一个明显的迹象表明它们正在成为一个令人担忧的侵入性工具——被用于超出其核心目的，以至于阻碍了整体开发。

除了其他令人恼火的事情之外，一个常见的缺陷是它们保留了每篇文章的单个副本[1]。这个单一副本在创建内容时被编辑，并发布给读者（通常是在某种状态更改标志上）。

保留一些数据片段的单个副本的想法很常见。这是关系概念规范化的基本原则，企业架构师经常试图确保关键数据具有唯一的权威副本。

然而，对于 CMS 来说，有一个明显的缺点——编辑和发布的数据访问模式非常不同。编辑涉及少量人员频繁访问文章，进行读写操作。发布涉及更多的人（我们希望）访问文章，但所有操作都是读取操作。有一些编辑是为了修复已发布文章中的问题，但这些编辑远少于读取操作，并且来自一个受良好控制的人员组。

由于存在两种不同的访问路径，一些 CMS 保留了文章的单独副本，由相对独立的模块控制。编辑模块围绕着频繁的更新而设计，它提供了对编辑、跟踪更改和监控编辑过程工作流的支持。当文章发布时，它会被复制到发布模块。

发布模块将文章视为基本上只读的，很少更新，并且仅由编辑模块更新。因此，发布模块的设计围绕着向大量读者提供该文章。至少这涉及数据存储的不同配置。发布模块可以在集群中的许多节点上自由复制，而编辑模块通常最好集中在一个节点上。对于不同的数据存储技术也存在争论，允许每个模块使用适合其访问模式的技术。

文章也可以存储在不同的格式中。通常，文章以一种形式编辑，但以另一种形式发布，例如以 Markdown 编辑，以 HTML 发布。在这种情况下，编辑模块应该存储 Markdown 格式，而发布模块应该存储 HTML。发布模块还可以对存储的副本进行一些页面组合工作。因此，如果您有一个静态标题，它可以在文章发布时添加到存储的文章的 HTML 中，从而节省了为每次读取重新组合它的工作量。[2]

分离这些模块还可以帮助编辑工作流。人们通常希望在发布到全世界之前预览更改，这在分离的情况下很容易做到，因为您可以发布到暂存区中的私有发布模块。这可以很好地解决其他情况下难以处理的逻辑，以确定从单个存储中发布什么。

用户生成的内容确实为这种方法增加了一些皱纹。维基完全由用户生成，它将拥有比策划网站更大且控制更少的编辑人员组。同样，读者评论将来自更广泛的作家范围。但即使是用户生成的内容，您也应该获得比作家更多的读者，因此将处理更新与提供已发布页面分开是有意义的。

使用支持编辑发布分离的稀有系统的团队发现它非常有效，大多数使用没有这种风格的工具的团队认为它会改进事情。如果您正在评估 CMS 或为自己的需求构建 CMS，您当然应该将编辑发布分离视为要寻找的关键功能。