1 独立式的1.0

最后更新于:2022-04-01 04:22:57

## 1 独立式的1.0 ### 1.1 环境 影响架构形成的环境因素可以分为内部环境因素以及外部环境因素。内部因素主要是团队及其成员相关内容,而外部因素主要来自于外部门、整个公司或者整个行业领域。 微博推荐1.0的这段时间是从2011年7月份到2013年2月份左右,其主要的目标就是实现当前的业务需求。对于独立式的解释:每一个业务项目都是一套完整架构流程,架构之间相对独立,甚至包括技术栈。之所以称之为独立式其内部因素有几点: 1)      当时团队是一个新团队,成员也相对较新,相互的合作不多,缺乏推荐领域整体性经验。 2)      团队成员对于推荐架构都有自己的一些或多或少的理解,但是对于在当前场景下的微博推荐架构,共识并没有形成。 当然起决定性因素的还是外部环境,是因为内部原因还是比较好协调和进化的。当时的外部环境因素包括: 1)      项目需求很多,在当时一个5人团队并行开发的项目平均在3-5个左右,当然最重要的因素是当时的微博产品正处于高速发展期,很多地方都需要微博推荐的支撑。同时,项目周期也很短,排期仓促,很难有时间进行细致的整理和抽象。典型产品包括:微吧、微群、微刊、微话题、用户以及内容排序等等。 2)      团队是一个支撑性的,绝大部分需求来自于外部团队,各个外部团队不同的产品方向也导致疲于应付需求。 3)      当时业内的推荐架构也有不同的发展方向,大家都在尝试摸索一些符合自身发展的架构思路。 由于上述的那些原因,通常我们面对一个接一个的项目时,都会根据自己的理解使用熟悉的技术栈来搭建流程,这样形成了一个又一个的独立架构。 ### 1.2 架构组成与特点 上节中提到了独立架构形成的原因,大家可能觉得架构组成没有必要去描述了,这是不对的,事实上后来的分层以及平台架构的基础恰恰都来源于这个阶段,没有这个阶段团队不断踩坑总结就没有因地制宜产生的后续进化。因此,我们需要为大家剖析一下推荐1.0的架构组成与特点。 1)      技术目标 参考图2所示,以业务实现为主要目标的微博推荐1.0,没有建立起完整的反馈以及评估体系,同时排序也是被策略取代,那么讲主要的重点体现到了候选、策略以及展现上。上述推荐流程被转化为:候选à策略à展现简单形态。 2)      架构组成 如图4所示,我们试图将每个项目的架构能够在图中表达出来,在真正的实施过程中,每一个项目负责人会选择使用apache+mod_python作为服务架构同时,使用redis作为存储选型。在一些特定的项目中,引入了复杂运算从而诞生了c/c++的服务框架woo;同时,对于数据的存储要求特型化的项目中又自己研发了一系列的db,比如早期存储静态数据的mapdb,存储key-list的keylistdb等等。当然,在部署中会比下图更加随意一些,一个项目几台服务器部署好微博服务提供http请求,然后再找几个服务器安装redis作为数据支撑,来源数据和业务方定好规则使用rsync传输就OK了,大部分策略在python中实现。 图中可以看到主要的技术栈: * web服务:apache+mod_python,后来发展成为社区更为完善的mod_wsgi。使用python作为WEB开发语言主要是因为平时处理数据使用的都是python,同时上手快,学习曲线平缓。 * 运算服务:c/c++,形成woo内部服务框架 * db:redis/mapdb/keylistdb等等,分为两种存储方法:redis以及自研型 * 数据来源:rsync文件传输,firehose作为微博相关内容来源[微博内部使用的一种数据队列] ![](http://wbrecom-wordpress.stor.sinaapp.com/uploads/2015/10/jia-4-1024x643.jpg "jia-4") 图4 微博推荐1.0架构简图 3)      架构特点 将架构特点划分为优点和缺点进行描述。那么优点是: * 简单,易于实现,不需要额外的基础支撑 * 利于业务的功能快速实现 * 利于多业务并行开展,相互不影响 而不足是: * 推荐流程不完整,缺乏反馈、评估等等重要内容,对于数据方面也极度缺乏统一处理方法 * 没有提供给算法相关的支撑,很难将推荐做的深入 * 几乎无法进行专业运维 * QA的测试仅仅能到功能层面,模块级别的测试几乎不可能,因为太过于分散 * 很难进行团队协作,不利于项目的分解 ### 1.3 成果 尽管存在诸多的缺点,但是在其发展的过程中,也给后面的架构优化奠定了基础,其成果如下: 1)      在微博高速发展的过程中,满足了微博对于推荐的业务支撑要求,在这段时期里面共完成二十多个独立项目。 2)      诞生了woo的基础框架,后面的内部高效运算框架来源于此 3)      诞生了mapdb的静态存储,成为后期微博推荐静态存储的雏形 4)      web应用层的不断需求的总结,组建形成推荐通用应用框架
';