7.7 完整架构总览

通过对内容发布系统的全部功能的设计，我们可以看到这是一个较为复杂、高度依赖监听内容各种状态变更事件的系统，内容的创建、修改、审核、发布、删除都属于内容状态的变更。图 7-10展示了内容发布系统的完整架构视图，希望能让我们更直观地感受整个内容发布系统的运转原理。

下面结合图7-10来系统性地复习内容发布系统的完整运转流程。

1. 创作者创建内容。客户端先将图片、音频、视频等文件上传到对象存储系统（在存储音视频文件前通常会进行音视频转码），然后在关系型数据库的item_info表中创建内容元信息，并将内容存储到item_record表中。如果内容文本较短（短文本），则直接将其存储到分布式KV存储系统中；而如果文本内容过长，则以文本文件的形式将其存储到对象存储系统中。新创建的内容可能需要审核，对于满足审核条件的内容，内容发布系统与审核中心建立送审消息队列，并向审核中心发送所创建的内容的消息，实现新创建的内容与审核服务的异步交互。
2. 创作者修改内容。创作者修改内容与创作者创建内容的业务架构流程是高度类似 的。如果此次内容修改涉及图片、音频和视频的改动，则客户端先将新的图片、音频、视频文件上传到对象存储系统，然后将此次的内容变更存储到item_record表中，这样做是为了实现内容变更的多版本控制。满足审核条件的内容，在修改后依然需要走内容审核流程，因此也要向审核中心发送消息，实现内容的修改与审核服务的异步交互。
3. 内容审核。内容需要审核，但并不是所有的内容都有必要进行审核。我们需要对浏览量、互动量达到阈值的内容和粉丝量巨大的创作者的新内容进行审核，这样可以在某内容有广泛传播的苗头时对其加强监管。我们也需要对注定高危的内容进行审核，比如内容的创作者最近被投诉较多或者其创建的内容被若干用户投诉 ，这样可以对大概率会违规的内容进行有效监控。
4. 内容审核完成与内容上线。当一条新创建的内容、被修改后的内容的某版本、触发审核条件的内容被审核中心执行审核完成时，审核中心会将审核结果通过消息队列通知到内容发布系统。如果审核结果是“审核通过”，则检查审核通过的内容版本号是否大于线上版本号；如果是，则表示可以覆盖已上线的内容，于是将item record表中的内容修改信息替换到item_info表中。在内容更新后，需要以发布内容事件的形式告知应用内的各种内容分发渠道，以便实现内容在各种内容分发渠道的快速曝光。
5. 内容对外展示。用户在读取内容详情时，实际上是先读取关系型数据库中的内容元信息，然后从分布式KV存储系统和对象存储系统中读取内容主体，同时会结合缓存策略来应对高并发的读取请求。内容元信息（动态数据）以及短文本被缓存到中心化缓存Redis和服务节点缓存Local Cache中，而长文本、图片、音频、视频等作为静态数据被缓存到CDN边缘节点中。
6. 内容分发。为了使内容对大众可见，需要将已发布的内容通知到各种内容分发渠道 ，同时内容分发渠道也会关注内容元信息的变更。如果内容被删除或下架，那么为了达到实时消失的效果，需要通知所有的内容分发渠道和缓存系统删除这条内容。为了让内容发布系统和内容分发渠道解耦，我们采用消息队列的形式完成两者之间的通信。

本章小结

本章从一条内容整个生命周期的角度出发，详细介绍了内容发布系统的核心要素。

首先，内容元信息和内容主体应该分开存储，对内容主体要根据各种存储系统的特点做出合适的存储选型。其次，由于内容审核的存在，对内容的创建或修改场景需要进行版本控制；对内容进行审核，并不是只要内容发生变更就送审，而是需要设计审核时机策略，考虑节约审核资源；内容发布系统还需要对接各种内容分发渠道。最后，内容生产是典型的读多写少的场景，对内容数据可以使用CDN技术、缓存和多副本策略来应对高并发的读取请求。

另外，需要注意的是，本章中的内容发布系统设计讨论更多的是通用能力建设，我们难免会忽略对各产品的一些个性化需求，比如有的产品在内容送审条件上有更合理的考虑，以及在内容审核交互流程上会更复杂，可能有多轮审核、多种维度审核策略……总之，各种个性化需求都需要读者朋友另行思考，这里仅仅是对可能的方案做出一些推断，但万变不离其宗。

总结

内容发布系统的完整运行流程？

1. 创作者创建内容。客户端先将图片、音频、视频等文件上传到对象存储系统（在存储音视频文件前通常会进行音视频转码），然后在关系型数据库的item_info表中创建内容元信息，并将内容存储到item_record表中。如果内容文本较短（短文本），则直接将其存储到分布式KV存储系统中；而如果文本内容过长，则以文本文件的形式将其存储到对象存储系统中。新创建的内容可能需要审核，对于满足审核条件的内容，内容发布系统与审核中心建立送审消息队列，并向审核中心发送所创建的内容的消息，实现新创建的内容与审核服务的异步交互。
2. 创作者修改内容。创作者修改内容与创作者创建内容的业务架构流程是高度类似 的。如果此次内容修改涉及图片、音频和视频的改动，则客户端先将新的图片、音频、视频文件上传到对象存储系统，然后将此次的内容变更存储到item_record表中，这样做是为了实现内容变更的多版本控制。满足审核条件的内容，在修改后依然需要走内容审核流程，因此也要向审核中心发送消息，实现内容的修改与审核服务的异步交互。
3. 内容审核。内容需要审核，但并不是所有的内容都有必要进行审核。我们需要对浏览量、互动量达到阈值的内容和粉丝量巨大的创作者的新内容进行审核，这样可以在某内容有广泛传播的苗头时对其加强监管。我们也需要对注定高危的内容进行审核，比如内容的创作者最近被投诉较多或者其创建的内容被若干用户投诉 ，这样可以对大概率会违规的内容进行有效监控。
4. 内容审核完成与内容上线。当一条新创建的内容、被修改后的内容的某版本、触发审核条件的内容被审核中心执行审核完成时，审核中心会将审核结果通过消息队列通知到内容发布系统。如果审核结果是“审核通过”，则检查审核通过的内容版本号是否大于线上版本号；如果是，则表示可以覆盖已上线的内容，于是将item record表中的内容修改信息替换到item_info表中。在内容更新后，需要以发布内容事件的形式告知应用内的各种内容分发渠道，以便实现内容在各种内容分发渠道的快速曝光。
5. 内容对外展示。用户在读取内容详情时，实际上是先读取关系型数据库中的内容元信息，然后从分布式KV存储系统和对象存储系统中读取内容主体，同时会结合缓存策略来应对高并发的读取请求。内容元信息（动态数据）以及短文本被缓存到中心化缓存Redis和服务节点缓存Local Cache中，而长文本、图片、音频、视频等作为静态数据被缓存到CDN边缘节点中。
6. 内容分发。为了使内容对大众可见，需要将已发布的内容通知到各种内容分发渠道 ，同时内容分发渠道也会关注内容元信息的变更。如果内容被删除或下架，那么为了达到实时消失的效果，需要通知所有的内容分发渠道和缓存系统删除这条内容。为了让内容发布系统和内容分发渠道解耦，我们采用消息队列的形式完成两者之间的通信。