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