亿级用户下的新浪微博平台架构

标签: 新浪微博 架构 | 发表时间:2015-01-21 08:34 | 作者:
出处:http://kb.cnblogs.com/

   序言

  新浪微博在2014年3月公布的月活跃用户(MAU)已经达到1.43亿,2014年新年第一分钟发送的微博达808298条,如此巨大的用户规模和业务量,需要高可用(HA)、高并发访问、低延时的强大后台系统支撑。

  微博平台第一代架构为LAMP架构,数据库使用的是MyIsam,后台用的是php,缓存为Memcache。

  随着应用规模的增长,衍生出的第二代架构对业务功能进行了模块化、服务化和组件化,后台系统从php替换为Java,逐渐形成SOA架构,在很长一段时间支撑了微博平台的业务发展。

  在此基础上又经过长时间的重构、线上运行、思索与沉淀,平台形成了第三代架构体系。

  我们先看一张微博的核心业务图(如下),是不是非常复杂?但这已经是一个简化的不能再简化的业务图了,第三代技术体系就是为了保障在微博核心业务上快速、高效、可靠地发布新产品新功能。

   第三代技术体系

  微博平台的第三代技术体系,使用正交分解法建立模型:在水平方向,采用典型的三级分层模型,即接口层、服务层与资源层;在垂直方向,进一步细分为业务架构、技术架构、监控平台与服务治理平台。下面是平台的整体架构图:

  如上图所示,正交分解法将整个图分解为3*4=12个区域,每个区域代表一个水平维度与一个垂直维度的交点,相应的定义这个区域的核心功能点,比如区域5主要完成服务层的技术架构。

  下面详细介绍水平方向与垂直方向的设计原则,尤其会重点介绍4、5、6中的技术组件及其在整个架构体系中的作用。

   水平分层

  水平维度的划分,在大中型互联网后台业务系统的设计中非常基础,在平台的每一代技术体系中都有体现。这里还是简单介绍一下,为后续垂直维度的延伸讲解做铺垫:

  1. 接口层主要实现与Web页面、移动客户端的接口交互,定义统一的接口规范,平台最核心的三个接口服务分别是内容(Feed)服务、用户关系服务及通讯服务(单发私信、群发、群聊)。
  2. 服务层主要把核心业务模块化、服务化,这里又分为两类服务,一类为原子服务,其定义是不依赖任何其他服务的服务模块,比如常用的短链服务、发号器服务都属于这一类。图中使用泳道隔离,表示它们的独立性。另外一类为组合服务,通过各种原子服务和业务逻辑的组合来完成服务,比如Feed服务、通讯服务,它们除了本身的业务逻辑,还依赖短链、用户及发号器服务。
  3. 资源层主要是数据模型的存储,包含通用的缓存资源Redis和Memcached,以及持久化数据库存储MySQL、HBase,或者分布式文件系统TFS以及Sina S3服务。

  水平分层有一个特点,依赖关系都是从上往下,上层的服务依赖下层,下层的服务不会依赖上层,构建了一种简单直接的依赖关系。

  与分层模型相对应,微博系统中的服务器主要包括三种类型:前端机(提供 API 接口服务)、队列机(处理上行业务逻辑,主要是数据写入)和存储(mc、mysql、mcq、redis 、HBase等)。

   垂直延伸技术架构

  随着业务架构的发展和优化,平台研发实现了许多卓越的中间件产品,用来支撑核心业务,这些中间件由业务驱动产生,随着技术组件越来越丰富,形成完备的平台技术框架,大大提升了平台的产品研发效率和业务运行稳定性。

  区别于水平方向上层依赖下层的关系,垂直方向以技术框架为地基支撑点,向两侧驱动影响业务架构、监控平台、服务治理平台,下面介绍一下其中的核心组件。

   接口层Web V4框架

  接口框架简化和规范了业务接口开发工作,将通用的接口层功能打包到框架中,采用了Spring的面向切面(AOP)设计理念。接口框架基于Jersey 进行二次开发,基于annotation定义接口(url, 参数),内置Auth、频次控制、访问日志、降级功能,支撑接口层监控平台与服务治理,同时还有自动化的Bean-json/xml序列化。

   服务层框架

  服务层主要涉及RPC远程调用框架以及消息队列框架,这是微博平台在服务层使用最为广泛的两个框架。

   MCQ消息队列

  消息队列提供一种先入先出的通讯机制,在平台内部,最常见的场景是将数据的落地操作异步写入队列,队列处理程序批量读取并写入DB,消息队列提供的异步机制加快了前端机的响应时间,其次,批量的DB操作也间接提高了DB操作性能,另外一个应用场景,平台通过消息队列,向搜索、大数据、商业运营部门提供实时数据。

  微博平台内部大量使用的MCQ(SimpleQueue Service Over Memcache)消息队列服务,基于MemCache协议,消息数据持久化写入BerkeleyDB,只有get/set两个命令,同时也非常容易做监控(stats queue),有丰富的client library,线上运行多年,性能比通用的MQ高很多倍。

   Motan RPC框架

  微博的Motan RPC服务,底层通讯引擎采用了Netty网络框架,序列化协议支持Hessian和Java序列化,通讯协议支持Motan、http、tcp、mc等,Motan框架在内部大量使用,在系统的健壮性和服务治理方面,有较为成熟的技术解决方案,健壮性上,基于Config配置管理服务实现了High Availability与Load Balance策略(支持灵活的FailOver和FailFast HA策略,以及Round Robin、LRU、Consistent Hash等Load Balance策略),服务治理方面,生成完整的服务调用链数据,服务请求性能数据,响应时间(Response Time)、QPS以及标准化Error、Exception日志信息。

   资源层框架

  资源层的框架非常多,有封装MySQL与HBase的Key-List DAL中间件、有定制化的计数组件,有支持分布式MC与Redis的Proxy,在这些方面业界有较多的经验分享,我在这里分享一下平台架构的对象库与SSD Cache组件。

   对象库

  对象库支持便捷的序列化与反序列化微博中的对象数据:序列化时,将JVM内存中的对象序列化写入在HBase中并生成唯一的ObjectID,当需要访问该对象时,通过ObjectID读取,对象库支持任意类型的对象,支持PB、JSON、二进制序列化协议,微博中最大的应用场景将微博中引用的视频、图片、文章统一定义为对象,一共定义了几十种对象类型,并抽象出标准的对象元数据Schema,对象的内容上传到对象存储系统(Sina S3)中,对象元数据中保存Sina S3的下载地址。

   SSDCache

  随着SSD硬盘的普及,优越的IO性能使其被越来越多地用于替换传统的SATA和SAS磁盘,常见的应用场景有三种:1)替换MySQL数据库的硬盘,目前社区还没有针对SSD优化的MySQL版本,即使这样,直接升级SSD硬盘也能带来8倍左右的IOPS提升;2)替换Redis的硬盘,提升其性能;3)用在CDN中,加快静态资源加载速度。

  微博平台将SSD应用在分布式缓存场景中,将传统的Redis/MC + Mysql方式,扩展为 Redis/MC + SSD Cache + Mysql方式,SSD Cache作为L2缓存使用,第一降低了MC/Redis成本过高,容量小的问题,也解决了穿透DB带来的数据库访问压力。

   垂直的监控与服务治理

  随着服务规模和业务变得越来越复杂,即使业务架构师也很难准确地描述服务之间的依赖关系,服务的管理运维变得越来难,在这个背景下,参考google的dapper和twitter的zipkin,平台实现了自己的大型分布式追踪系统WatchMan。

   WatchMan大型分布式追踪系统

  如其他大中型互联网应用一样,微博平台由众多的分布式组件构成,用户通过浏览器或移动客户端的每一个HTTP请求到达应用服务器后,会经过很多个业务系统或系统组件,并留下足迹(footprint)。但是这些分散的数据对于问题排查,或是流程优化都帮助有限。对于这样一种典型的跨进程/跨线程的场景,汇总收集并分析这类日志就显得尤为重要。另一方面,收集每一处足迹的性能数据,并根据策略对各子系统做流控或降级,也是确保微博平台高可用的重要因素。要能做到追踪每个请求的完整调用链路;收集调用链路上每个服务的性能数据;能追踪系统中所有的Error和Exception;通过计算性能数据和比对性能指标(SLA)再回馈到控制流程(control flow)中,基于这些目标就诞生了微博的Watchman系统。

  该系统设计的一个核心原则就是低侵入性(non-invasivenss):作为非业务组件,应当尽可能少侵入或者不侵入其他业务系统,保持对使用方的透明性,可以大大减少开发人员的负担和接入门槛。基于此考虑,所有的日志采集点都分布在技术框架中间件中,包括接口框架、RPC框架以及其他资源中间件。

  WatchMan由技术团队搭建框架,应用在所有业务场景中,运维基于此系统完善监控平台,业务和运维共同使用此系统,完成分布式服务治理,包括服务扩容与缩容、服务降级、流量切换、服务发布与灰度。

   结尾

  现在,技术框架在平台发挥着越来越重要的作用,驱动着平台的技术升级、业务开发、系统运维服务,本文限于篇幅限制,没有展开介绍,后续会不断地介绍核心中间件的设计原则和系统架构。

相关 [新浪微博 架构] 推荐:

新浪微博图床架构解析

- - CSDN博客架构设计推荐文章
可以先看一下  http://c.blog.sina.com.cn/profile.php?blogid=a466bf9189000rsw 新浪微博官方发出来的文章. 以下我们来解析一下如何构建高可用的图片存储系统 以满足现在日益增长的图片量,保证系统稳定高效的运行. 图床系统 ,我们先来分析下基于此类系统的一个特性.

新浪微博技术架构分析-转载

- 盛开 - 人月神话的BLOG
中国首届微博开发者大会在北京举行,这是国内微博行业的首场技术盛宴. 作为国内微博市场的绝对领军者,新浪微博将在此次大会上公布一系列针对开发者的扶持政策,以期与第三方开发者联手推动微博行业的整体发展. 图为微博平台首席架构师杨卫华演讲. 大家下午好,在座的大部分都是技术开发者,技术开发者往往对微博这个产品非常关心.

[转]新浪微博的架构发展历程

- - 小彰
新浪科技讯 11月16日下午消息,由 新浪微博( http://t.sina.com.cn)( http://t.sina.com.cn)主办的中国首届微博开发者大会在北京举行,这是国内微博行业的首场技术盛宴. 作为国内微博市场的绝对领军者,新浪微博将在此次大会上公布一系列针对开发者的扶持政策,以期与第三方开发者联手推动微博行业的整体发展.

亿级用户下的新浪微博平台架构

- - 博客园_知识库
  新浪微博在2014年3月公布的月活跃用户(MAU)已经达到1.43亿,2014年新年第一分钟发送的微博达808298条,如此巨大的用户规模和业务量,需要高可用(HA)、高并发访问、低延时的强大后台系统支撑.   微博平台第一代架构为LAMP架构,数据库使用的是MyIsam,后台用的是php,缓存为Memcache.

新浪微博混合云架构实践挑战之容器编排设计与实践

- - IT瘾-tuicool
《微博混合云架构》专栏是InfoQ向新浪微博技术团队的系列约稿,本专栏包含8篇内容,详细阐述以DCP设计理念为指导思想的混合云架构实践. 本文是该系列的第五篇,主要介绍容器编排的设计与实现. 《微博混合云架构》专栏主要包括以下8篇内容:. DCP的容器编排设计与实践. 最近由于个人原因,与InfoQ约稿的专栏《微博混合云架构》很久没更新了,在此深表歉意.

围攻新浪微博

- Jos - 望月的博客
在国内的门户微博中,新浪微博无疑是目前用户数量最多、媒体属性最强的,但是,最近,却连续看到一些互联网的知名人士高调宣布退出或者关闭新浪微博的博文,使用和不使用某个产品本就是个人的自由,但如此高调的宣布,并进行口诛笔伐,就值得关注了. 本文试图通过分析谷奥事件,宋石男和贾葭两位老师离开新浪微博的事件分析新浪微博的是与非.

新浪微博连接 2.3

- leeking001 - 我爱水煮鱼
新浪微博连接是我使用新浪微博 API 接口开发的一个 WordPress 插件,它的主要功能是能让用户使用新浪微博账号登陆 WordPress 博客,并且可以直接使用新浪微博的头像,同步博客日志到 WordPress 博客. 经过几天的测试,新浪微博连接插件升级到 2.3,主要修正:同步博客到新浪微博的问题,并且同步内容更为丰富,规则改为:【日志标题】+ 日志内容摘要 + 日志链接.

新浪微博n大傻

- suki - broom's blog
看不到follow的人之间的交互这类产品本身的问题就不提了,就说说用户行为的傻. 其中有些行为也是产品本身纵容的. 三天两头换id的,搞个巨长的id既占字数又让别人压根没法手动@的,带个公司前缀的,用流行语的. 完全没有网络时代id就是个人身份的概念,意识还停留在QQ时代,以为随便改昵称呢. 某些专门发垃圾小段子的帐号尤甚.

新浪微博不是Twitter

- 马克叔叔 - 月光博客
  Twitter是互联网短信,新浪微博以微博客Twitter式弱关系切入,正在转型SNS. 转型的挑战在于:1.如何融合弱关系和强关系. 2.如何用弱关系倒逼中国社会的强关系和潜关系.   国内有一些Twitter的拥趸,认为微博抄Twitter都抄不到点子上.   “Twitter 是四两拨千斤的艺术.

V5后的新浪微博

- - It Talks--上海魏武挥的博客
正是在这个内外交困的时刻,新浪微博展开了它的商业化之旅,前途如何,尚未可知. 近日新浪微博发布了它的第五个版本,称为“V5”,在这个版本中,一个很明显的变化是:它长的有点像Facebook,用户不仅可以设置较大的头像,也可以在顶部自定义一张大图. V5版本的一些细节做得很用心,无论是提示语,还是版式的细微之处.