网易传媒统一内容生产流程的架构实践（一）

前言

　　传媒早期内容生产主要依赖编辑团队，后台团队可以较为集中的从数据库中获取到所需数据；后续内容战略升级，增加了网易号自媒体平台新的生产方，内容生产源头也逐步增加了短资讯、小视频、公开课等多种新的内容形式，每日新增内容量不断增加，导致需要从越来越分散的系统中获取数据，工作重复繁琐易于出错。

　　同时，整体业务形态也从编辑维护改为Feeds流，在针对用户进行个性化推荐之前，对于不同类型数据既要调用通用的功能模块：比如分类、标签、安全审核等，又要针对特殊业务类型进行个性化处理：比如图文的头图提取、视频的封面提取等。

　　基于以上，我们希望有一套统一对接多内容源、处理流程可配置、具有良好扩展性的内容处理系统。通过接入各种内容处理服务（机器+人工），完成对内容的加工处理，输出给订阅方。

　　内容处理服务涵盖了内容安全质量（安全审核、质量评价，暴力色情，低俗，标题党等）、内容建模特征（分类，兴趣点，标签等），内容理解生成（封面图，摘要，结构化等）。

通用框架

流程处理
我们自研了工作流框架，将内容处理过程中独立的环节抽象为处理节点，单个节点可以是一次http接口调用，也可以是与另外一个独立系统做多次的复杂信息交互。通过配置文件定制环节顺序，即内容数据处理流程，流程框架功能特点：

　　1.处理流程可配置，根据业务需要新增、删除处理环节，环节顺序可任意编排。
2.处理环节支持“前置|后置”拦截器，可以方便的在流程中加入自定义逻辑。
3.制定内容订阅标准，将业务需求转化为数据订阅脚本，可以从任意环节输出业务订阅数据。
4.热部署动态更新流程，无需重启服务。

数据多版本

　　同一环节支持多种实现类，可根据分支判断脚本决定处理类，主要解决在流程中实现ABTest，支持两种方案：

　　1.根据条件判断，单条数据只过其中一种实现（节点B或节点B1），将结果记录并发给订阅方。

　　（数据多版本配置）

消息系统
内容处理流程需要跟内容生产方、内容订阅方、审核系统、各种AI服务进行数据交互，并且内容数据生产具有一定的潮汐性，存在阶段峰值（下午三至五点为发文高峰期），为了更好应对线上压力并与各业务系统解耦，我们引入了消息系统。
消息系统的选型在对比rabbitmq和kafka之后最终采用kafka，kafka相对于rabbitmq来说有几大优势：

　　1.topic分区，支持高并发写入和消费
2.单topic能够同时支持多个consumer group消费，不用为每个消费者新建消息队列
3.消息回溯

容错与补偿

　　随着处理环节不断增多，过程中可能出现问题的概率也不断升高，由于前后环节存在数据依赖，当环节执行出错时需要将当前数据的流转暂停直到环节服务恢复为止，这种情况出现时手工处理的成本是极高的。

　　针对以上问题，我们设计了以下方案：

　　1.流程框架自动记录数据当前处理环节及状态，一旦环节执行失败，就会通过定时任务重新调度直到成功。通过这样的监控方式我们能够达到：任何代码或依赖服务异常引起的故障都可以在修复后自动进行数据恢复。
2.由于部分服务有可能更新，例如：个性化推荐的标签服务算法改变，需要将至少近半年数据重新执行标签处理环节保证推荐准确，框架支持工具可以指定数据重新调用指定环节并将数据推送给数据订阅方。

数据统计

　　原有生产模式下，不同数据源都存储在各业务系统的数据库中，数据字典定义也各自为政，这就给统计功能实现带来了很大的困难，需要考虑数据拉取、映射等复杂场景，需求的实现成本极高，无法快速满足频繁变更的统计诉求，被业务团队诟病。

　　内容处理流程作为连接内容生产和消费的中间环节，将各处理服务的处理结果、开始结束时间、处理状态等各种数据进行详细的记录并统一存储，非常有利于进行精细化的数据统计来指导运营方把握内容生产方向，最终我们实现了灵活细致的统计服务。

　　实现过程中首要难点在于：产品要求不能只对数据的最终态进行计算，还要将不断变化且被覆盖掉的中间状态统计在内。

　　通常的根据数据库从库来统计的解决方案不再适用，为记录字段的中间状态，传统方式是在所有修改db操作时进行日志记录或采用其他持久化方式，这样的问题在于随着业务不断累积需要增加记录的代码位置会越来越多，非常不利于后续维护。

　　针对这一问题，我们选用了canal对数据库的binlog进行监控，将业务开发与数据变化的记录解耦，每次单条数据修改的字段和修改值以kafka消息方式发送给数据统计服务，区分新增、修改、删除操作并附带修改前和修改后的值，以多条数据方式存储于临时表中，这样就记录下相同id的相同字段下值的变化过程，后续真正的统计是基于临时表内的记录。这样做会生成大量的临时表数据，占用磁盘空间，所以在统计完成后会把结果记录到统计表中，临时表会定期删除，清理磁盘空间。

　　统计数据存在数据量大、增长快、统计维度复杂等业务特点，最终存储选型是Tidb，主要解决大数据量下有高并发实时写入、实时查询、实时统计分析的需求并支持水平扩容，避免了分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的 Sharding 方案。

监控告警

　　常规的系统和中间件监控之外，在掌握了各处理环节的详细统计数据后，我们可以对各环节业务数据的异常变化进行报警，比如：对网易号自媒体平台图文每日生产量进行同比或环比比较，当生产量降幅超过20%时，报警通知技术和运营同学，第一时间从技术和运营多个角度定位原因，减少流量损失。后续计划支持可定制化的监控规则和阈值设计，运营和产品同学可以不依赖于技术进行操作。

结语

　　我们最终将项目命名为阿波罗，它整合了传媒内部所有关于内容处理的各类服务，通过配置化方式将新类型的内容数据接入的开发成本降低到原来的10%，内容生产团队不再关心后续的加工处理，内容订阅团队拿到的是开箱即可使用的成熟数据，运营产品团队可以拿到更准确的统计数据来指导内容生产和投放，达到了整个系统最初设计的目标。

　　灵活的内容处理流程控制实现后，技术团队又踏上了对中间环节的优化之路，安全审核系统作为整个流程处理环节的重中之重，是保证安全生产的关键一环：面对每天几百万各类新增内容数据，内容审核团队需要足够时间确保安全无遗漏，运营团队希望内容尽快投放给用户。这两个矛盾的需求如何平衡成为了下一个挑战，攻城狮们如何应对，敬请期待。

作者简介

　　王怡然，2011年加入网易传媒，目前带领团队专注于基础服务及中间件开发