## 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作为微博相关内容来源［微博内部使用的一种数据队列］  图4 微博推荐1.0架构简图 3)      架构特点 将架构特点划分为优点和缺点进行描述。那么优点是： * 简单，易于实现，不需要额外的基础支撑 * 利于业务的功能快速实现 * 利于多业务并行开展，相互不影响 而不足是： * 推荐流程不完整，缺乏反馈、评估等等重要内容，对于数据方面也极度缺乏统一处理方法 * 没有提供给算法相关的支撑，很难将推荐做的深入 * 几乎无法进行专业运维 * QA的测试仅仅能到功能层面，模块级别的测试几乎不可能，因为太过于分散 * 很难进行团队协作，不利于项目的分解 ### 1.3 成果 尽管存在诸多的缺点，但是在其发展的过程中，也给后面的架构优化奠定了基础，其成果如下： 1)      在微博高速发展的过程中，满足了微博对于推荐的业务支撑要求，在这段时期里面共完成二十多个独立项目。 2)      诞生了woo的基础框架，后面的内部高效运算框架来源于此 3)      诞生了mapdb的静态存储，成为后期微博推荐静态存储的雏形 4)      web应用层的不断需求的总结，组建形成推荐通用应用框架