## 2 分层式的2.0
上一节介绍完独立的1.0，按照架构发展的道路，我们到了分叉路口，一边是流行的LAMP架构，另一边是符合广告、搜索的CELL架构。LAMP架构数据策略分离，脚本语言作为业务开发主要语言，项目快速开发和迭代的首选。CELL结构强调本地流程处理，数据与业务耦合性强，自研的服务以及数据库较多出现，适用于高性能效果型产品。最终我们选择兼容两者，倾向于业务的架构体系。为何如此呢？让我们再来看看当时的环境。
### 2.1 环境
微博推荐2.0的时间段是2013年3月份到2014年年底，这段时间内部环境因素是：
1) 当前团队成员合作已经很长时间，彼此相互熟悉，同时对于技术选型有了一定的共识。
2) 团队产品进行了聚焦，针对内容／用户／垂直类三类推荐进行了整理，同时对于场景分别进行了重点划分：feed流内、正文页以及PC首页右侧。这种聚焦有利于进行架构统一，同时也为技术争取了时间。
而外部因素是：
1) 公司对于推荐有了比较明确的定位，提高关系达成以及内容传播效率，同时为推荐型广告打好技术探索、场景介入以及用户体验的基础。
2) 推荐领域里，各个公司都纷纷有了对于架构的产出，对于微博推荐有了很好的指导意义。
### 2.2 架构组成与特点
团队在执行核心业务实现的时候，不断演进工具以及框架，构建2.0的目标呼之欲出。
1) 技术目标
与1.0不同，仅仅实现业务需求已经不是2.0的技术目标了，针对完整的推荐流程，我们需要解决：
* 首先要实现完整的推荐流程，架构覆盖候选、排序、策略、展示、反馈和评估。
* 以数据为先，提炼出数据架构。实现数据对比，效果以数据为准；实现数据通道，体现反馈；实现数据落地，承接业务需求。
* 提供算法方便介入的方式。
* 既能保证业务的快速迭代和开发，又能支持高效运算。
2) 架构组成
微博推荐2.0的架构如图5所示，它不再是一个个独立的系统，也不是会让开发人员使用不同的技术解决相似的问题。这个架构图主要包括几个部分的内容：
* 应用层：主要承担推荐策略以及展现方面的工作，其特点在于充分发挥脚本语言的特点响应迭代需求。大部分的推荐内容经过排序之后已经可以展示了，但是由于前端产品策略的设定需要融合、删选以及重排操作，需要这一层来完成，在技术层面属于IO密集型的。在技术选型上，早期在原有apache＋mod_python基础上进行了框架开发产生了common_recom_frame。该框架面向的是二次开发者，基于此框架可以很好的实现推荐业务流程。该框架的核心思想是提炼出project、work以及data的三层interface，project针对每一个推荐项目，work针对每个推荐项目中不同推荐方法，而data则是管理下游数据的访问方法。同时，设定了两个规范：一个是统一了推荐接口，无论是用户、内容还是垂直业务；另一个是屏蔽了不同协议数据库访问方法，极大提高了开发效率。common_recom_frame框架的诞生基本上解决了产品的各种推荐策略需求，走在了产品的前面。
图5 微博推荐2.0架构示意图
* 计算层：主要承担推荐的排序计算，主要消耗CPU，在这一层给算法提供介入方法，支持算法的模型迭代。在这一层的技术选型上，我们继承了原有的WOO协议框架，一种基于c/c++开发的内部高效通讯框架。当然也做了不少扩展，依然借用了上面提到的common_recom_frame的思想，在WOO框架基础上实现了对于project／work/data的管理，提供给二次开发者更为高效的开发工具。在团队的开源项目中包含这个工具：[https://github.com/wbrecom/lab_common_so](https://github.com/wbrecom/lab_common_so)
* 数据层：主要承担推荐的数据流以及存储工作。数据层的工作主要是解决数据的IN/OUT/STORE问题。其中IN数据如何进入系统，OUT表示数据如何访问，STORE表示数据如何存。当在进行数据层规划的时候，又分析了微博推荐的数据特点，可以将其分为两类：静态和动态。静态数据的定义为： 更新需要全量同时频次较低的大规模数据；动态数据的定义为：动态更新同时频次较高的增量数据。这样在IN/OUT/SOTRE的大方向下，同时区分对待静态和动态数据，产生了RIN／R9-interface、redis/lushan、tmproxy／gout代理的工具或者框架。在这里展开讲一下，RIN支持数据动态数据的接入，通过web服务的方式接收数据，后端使用ckestrel进行队列管理，辅以多服务集群的消费框架，使用者只需要进行自己业务的开发即可快速上线消费动态数据。R9-interface处理静态数据的接入，推荐的大量静态数据来源于Hadoop集群的运算，r9-interface框架勇来解决静态运算［MR、HIVE SQL以及SPARK 运算］的通知、管理以及数据载入。针对推荐数据的存储，动态数据大量使用了redis集群，静态数据则使用了lushan集群。对于lushan这个工具在团队开源项目中也包含了：[https://github.com/wbrecom/lushan](https://github.com/wbrecom/lushan)。tmproxy／gout用来解决数据的OUT问题，gout是一个代理中间件，用来处理推荐中对于数据的动静结合访问的需求，减少业务对于后端数据变化带来的影响。
* 基础服务：推荐系统的基础服务主要包括监控、报警以及评测系统，数据监控系统分为性能以及效果监控两类，评测系统主要用来进行下线评估，在上线之前对效果有一定预期以及减少无效上线。图6展示了基础服务的UI。
图6 基础服务系统的UI
3) 特点
优点是：
* 支撑完整的推荐流程，对于数据方面拥有统一的处理方法
* 在兼顾业务功能快速实现的同时保证了效果技术的不断深化
* 给算法提供了很好的支持
* 提出以数据为先的思想，可以全面对比效果，推荐效果不断得以提升
* 封层体系易于部署以及QA介入进行测试
而不足是：
* 和推荐核心有一定的距离，并没有完全为推荐量身定做
* 将推荐的策略算法完全交给了开发者，不利于推荐通用型
* 对于算法的训练并没有涉及，仅仅是一个线上投放系统，不足以构成完整的推荐体系
### 2.3 成果
微博推荐2.0的诞生产生很好的收益，其成果如下：
1) 微博推荐的核心业务均在该体系下完成：正文页推荐、趋势用户推荐、趋势内容推荐、各个场景下的用户推荐、粉丝经济的粉条、账号推荐等等产品
2) 诞生了lab_common_so的基础框架，并进行了开源
3) 诞生了静态存储集群解决方案lushan，并进行了开源
4) RUF框架的诞生极大提升了业务生产效率，同时也为openresty社区做出一定贡献
