Feed架构-我们做错了什么
在过去几年，所在的微博技术团队在一定程度成功解决了feed架构的扩展性与性能的问题，大部分精力已经从应对峰值性能或者数据扩展中解放出来。
几天前，拿着上面这张架构图问内部一些架构师，目前完成的工作及存在的主要问题是什么？
完成的工作不出意料，大家的观点比较类似，主要在架构的工程成熟度方面。
- 解决了数据规模大且长尾访问的问题，通过按时间线的冷热分区设计，在MySQL等数据库上成功实现了低成本的长尾分区实现。由于社交产品 中大部分访问（90%以上）发生在最近的数据，而较旧的数据（长尾数据）相对访问偏少，因此在存储上利用时间维度进行不同存储区域区分，来达到性能及成本 的收益。
- 解决了数据存储可扩展的问题，可以满足3年左右数据扩展的需要。这个主要利用成熟的数据库拆分方案，简单的实现通常设计成倍扩容，在最初建表时候预留足够多的分表，当容量增长时将这些表迁移到更多服务器上去。
- 解决了百万QPS访问的问题，主要依赖缓存分区及复制机制的成功应用，通过缓存复制及分级，可以让每秒上十万次访问的数据获得非常好的访问性能，同时数据复制机制可以提高可用性，防止单点机器故障时给数据库带来范围压力。
- 解决了可用性及错误隔离问题，得益于历年来建设的SLA体系，服务之间有良好的服务契约及错误隔离手段，因此核心功能 有99.99%+的可用性。
但是对于不足呢？如果架构重新再来，你会怎么做？这个问题回答比较多元，经过整理一些主要观点如下。
首先是从解决架构的问题说起，上述feed架构主要解决了在社交媒体环境中，实时及可扩展的解决基于关注关系的数据分发问题。
由于微博是一个实时的网络，人们常把推ter/微博这种社交媒体产品比作是地球的脉搏，它确实无时不刻都在产生海量的数据，并且产生着不可预 测的大量随机峰值访问，业界也是首次随着社交网络的出现遭遇这种架构上的scalability问题，记得在2009-2010年左右，推ter由 于压力过大经常出现鲸鱼页面错误。经过几年的努力，包括微博在内的业界主要公司都已经成功解决了关系模型的数据分发架构问题。
但在用户的层面，使用社交媒体产品依旧被信息过载的问题所困扰。
- 虽然每天收到大量信息，但是大部分不是自己感兴趣的信息。
- 基于用户关注维度的兴趣阅读效率不高，用户关注了一个兴趣领域的同行，但这个同行却大部分时候在谈风花雪月。
- 由于传播的低成本，大号在过度的使用消息通道，生产大量用户未必感兴趣的低质内容。
- 广告及普通内容的界限很模糊。
- 由于利益关系，僵尸帐号及内容通过变换形式在大行其道。
- 内容同质化及雷同问题，内容被精英占领，小人物声音不能得到有效传递。
在社交网络中，上述问题，不可能全部像Google的使命那样，通过技术手段得到解决。但是大部分又跟技术密切相关。
- 基于用户维度组织内容高效满足兴趣阅读的难度。在上图中，绿色的框中是数据流经的主要通道，但在传统的SNS架构中，这些数据的组织都是 基于用户纬度。从用户纬度组织数据较好解决了传统feed模型基于关系聚合数据的问题。但正是由于数据是从关系维度来组织的结构，造成并不能给改进上述阅 读效率问题带来便利。由于在一定程度信息过载，兴趣阅读是发展方向，但是在架构上目前并没有清晰的解法。
- 信息识别及低质内容鉴定的技术挑战。虽然业界已经在大数据、自然语言处理等方面积累了不少经验，但在具体场景中，信息识别仍然还在比较初级的阶段。低质内容不一定是垃圾广告，只是当前浏览者不感兴趣。
- 反垃圾算法。
社交网络的信息架构和搜索引擎有很大的不同，在浏览feed是并不像使用搜索有明确的搜索意图，非死book曾经尝试使用EdgeRank来解决newsfeed算法的效率问题，但是结果并不如预期理想。由于社交关系的存在，用户对出现（及不出现）什么内容的可解释性非常敏感，不能接受好友的信息在排序结果不能看到。因此仅能说feed架构只是解决了初步的问题，更大的问题依旧在思考及寻找解决的途中。
PS：本文上述内容会在12月19日ArchSummit北京大数据环境的feed架构演讲中介绍，欢迎参会的同行前来交流。
如想及时阅读Tim Yang的文章，可通过页面右上方扫码订阅最新更新。
Similar Posts: