这周继续研究微博架构，本篇随便的重点是微博架构的演变。
微博（Weibo）是一种通过关注机制分享简短实时信息的广播式社交网络平台。微博用户通过关注来订阅内容，在这种场景下，推荐系统可以很好地和订阅分发体系进行融合，相互促进。微博两个核心基础点：一是用户关系构建，二是内容传播，微博推荐一直致力于优化这两点，促进微博发展。
在微博推荐发展的过程中遇到体系方向的变化、业务的不断更迭、目标的重新树立，其产品思路、架构以及算法也随之进行变迁。本文主要阐述在这个过程中推荐架构的演进，从产品目标、算法需求以及技术发展等维度为读者呈现一个完整的发展脉络，同时也希望通过这个机会跟大家一起探讨业务与技术的相互关系。
为了便于理解微博推荐架构演进，在介绍之前需要陈述一下微博推荐在流程上的构成，其实这个和微博本身没有关系，理论上业内推荐所存在的流程基本都是相同的。如图2所示，推荐是为了解决用户与item之间的关系，将用户感兴趣的item推荐给他／她。那么，一个item被推荐出来会经过候选、排序、策略、展示、反馈到评估再改变候选等等形成一个完整的回路。
下面介绍微博架构的几个版本：
独立式的1.0
1.1 环境
影响架构形成的环境因素可以分为内部环境因素以及外部环境因素。内部因素主要是团队及其成员相关内容，而外部因素主要来自于外部门、整个公司或者整个行业领域。
微博推荐1.0的这段时间是从2011年7月份到2013年2月份左右，其主要的目标就是实现当前的业务需求。对于独立式的解释：每一个业务项目都是一套完整架构流程，架构之间相对独立，甚至包括技术栈。之所以称之为独立式其内部因素有几点：
1) 当时团队是一个新团队，成员也相对较新，相互的合作不多，缺乏推荐领域整体性经验。
2) 团队成员对于推荐架构都有自己的一些或多或少的理解，但是对于在当前场景下的微博推荐架构，共识并没有形成。
当然起决定性因素的还是外部环境，是因为内部原因还是比较好协调和进化的。当时的外部环境因素包括：
1) 项目需求很多，在当时一个5人团队并行开发的项目平均在3-5个左右，当然最重要的因素是当时的微博产品正处于高速发展期，很多地方都需要微博推荐的支撑。同时，项目周期也很短，排期仓促，很难有时间进行细致的整理和抽象。典型产品包括：微吧、微群、微刊、微话题、用户以及内容排序等等。
2) 团队是一个支撑性的，绝大部分需求来自于外部团队，各个外部团队不同的产品方向也导致疲于应付需求。
3) 当时业内的推荐架构也有不同的发展方向，大家都在尝试摸索一些符合自身发展的架构思路。
由于上述的那些原因，通常我们面对一个接一个的项目时，都会根据自己的理解使用熟悉的技术栈来搭建流程，这样形成了一个又一个的独立架构。
分层式的2.0
微博推荐2.0的时间段是2013年3月份到2014年年底，这段时间内部环境因素是：
1) 当前团队成员合作已经很长时间，彼此相互熟悉，同时对于技术选型有了一定的共识。
2) 团队产品进行了聚焦，针对内容／用户／垂直类三类推荐进行了整理，同时对于场景分别进行了重点划分：feed流内、正文页以及PC首页右侧。这种聚焦有利于进行架构统一，同时也为技术争取了时间。
而外部因素是：
1) 公司对于推荐有了比较明确的定位，提高关系达成以及内容传播效率，同时为推荐型广告打好技术探索、场景介入以及用户体验的基础。
2) 推荐领域里，各个公司都纷纷有了对于架构的产出，对于微博推荐有了很好的指导意义。
2.2 架构组成与特点
团队在执行核心业务实现的时候，不断演进工具以及框架，构建2.0的目标呼之欲出。
平台式的3.0
微博推荐3.0的时间段是2014年底至今，当前的内部环境因素是：
1) 推荐产品不在扩张，对效果更为看重，将工作重点从业务开发和迭代转化为以效果为目标的技术迭代。
2) 新项目或者迭代推荐业务的时候发现重复的事情很多，而架构没有解决，工作存在冗余。
而外部因素是：
1) 公司也从业务扩展转变为效率为先，提升用户体验以及内容质量上来。
2) 微博推荐在推荐技术环节距离领域内有一定距离，当下有条件进行追赶。
3.2架构组成与特点
当前的环境也能体现出3.0的技术目标：
1) 技术目标
与2.0不同，全覆盖推荐流程已经不是3.0的目标，其目标是：
- 抽象出推荐流程中对于候选／排序／训练／反馈的通用方法来
- 推荐是一个算法数据问题，应该以一个算法的角度构建推荐系统，因此需要更为贴近算法策略
2) 架构组成
微博推荐3.0的架构，也是当前实行的架构体系，大家其实可以发现，这是基于2.0 发展起来的，既然还保留了大量2.0中使用的分层体系以及工具框架。
本文参考文献：架构师《微博推荐架构的演进》