多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
## 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框架的诞生基本上解决了产品的各种推荐策略需求,走在了产品的前面。 ![](http://wbrecom-wordpress.stor.sinaapp.com/uploads/2015/10/jia-5-1024x735.jpg "jia-5") 图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。 ![](http://wbrecom-wordpress.stor.sinaapp.com/uploads/2015/10/jia-6-1024x857.jpg "jia-6") 图6 基础服务系统的UI 3)      特点 优点是: * 支撑完整的推荐流程,对于数据方面拥有统一的处理方法 * 在兼顾业务功能快速实现的同时保证了效果技术的不断深化 * 给算法提供了很好的支持 * 提出以数据为先的思想,可以全面对比效果,推荐效果不断得以提升 * 封层体系易于部署以及QA介入进行测试 而不足是: * 和推荐核心有一定的距离,并没有完全为推荐量身定做 * 将推荐的策略算法完全交给了开发者,不利于推荐通用型 * 对于算法的训练并没有涉及,仅仅是一个线上投放系统,不足以构成完整的推荐体系 ### 2.3 成果 微博推荐2.0的诞生产生很好的收益,其成果如下: 1)      微博推荐的核心业务均在该体系下完成:正文页推荐、趋势用户推荐、趋势内容推荐、各个场景下的用户推荐、粉丝经济的粉条、账号推荐等等产品 2)      诞生了lab_common_so的基础框架,并进行了开源 3)      诞生了静态存储集群解决方案lushan,并进行了开源 4)      RUF框架的诞生极大提升了业务生产效率,同时也为openresty社区做出一定贡献