浅析新浪微博的集群技术利用及网站业务架构

　据了解，随着用户数量的不断扩增，在高峰期，新浪微博的服务器每秒要接受100万以上的响应请求，压力可谓空前。童剑表示，面对如此高的并发访问量，新浪在技术上所遇到的挑战也相当大。比如整体的技术平台如何做性能扩展?局部技术单元如何做性能扩展?并设计系统使能通过增加服务器即可实现服务能力扩容。不过，服务器数量的增加，会带来服务器采购成本的激增，而大量服务器快速部署上线又会对效率提出新的挑战，新困难层出不穷。
　　对此，新浪也在不断地寻找更完善的解决方案来满足他们的需求。新浪网研发中心平台架构部的思路是：
　　1、先规划整体，从大的技术体系上来保证能有效解决性能问题、成本问题、效率问题、可靠性问题;
　　2、然后再从局部着手，保证每个技术单元都能够从性能、可靠性方面满足需求;
　　3、同时在应用和系统的设计上，增加对故障容错的处理能力;
　　4、在产品运维上，加强风险控制，提高监控的有效性。
　　而在海量数据的处理方面，新浪则分别利用hadoop的hdfs实现海量数据存储、用mapreduce实现分布式计算，有些数据还使用了hbase进行存储和查询。除此之外，也大量采用了hive、zookeepr等技术。

集群的运维管理和交互仍是hadoop应用瓶颈
　　hadoop源于互联网，也回馈于互联网，互联网企业可以说是当前hadoop技术应用最广泛、最深入的领域。如今大多数机构都已经部署了各自的it业务系统，hadoop技术与现有it架构如何实现无缝整合，成为了许多用户非常关心的话题。在童剑看来，目前互联网领域的hadoop应用在大规模的使用情况下，瓶颈还是比较多的。一方面是集群的运维管理和监控，这方面的工具现在还不够成熟，需要运维工程师有较为丰富的经验。运维工程师除了要掌握硬件的资源使用情况，还需要部署一些管理软件来实现管理。另一方面则是由于集群中各组件之间的交互响应性能较差，在集群达到一定规模后，要有针对性的对其进行改进和优化。

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

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

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

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

接口层主要实现与web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容（feed）服务、用户关系服务及通讯服务（单发私信、群发、群聊）。
服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，其定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都属于这一类。图中使用泳道隔离，表示它们的独立性。另外一类为组合服务，通过各种原子服务和业务逻辑的组合来完成服务，比如feed服务、通讯服务，它们除了本身的业务逻辑，还依赖短链、用户及发号器服务。
资源层主要是数据模型的存储，包含通用的缓存资源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由技术团队搭建框架，应用在所有业务场景中，运维基于此系统完善监控平台，业务和运维共同使用此系统，完成分布式服务治理，包括服务扩容与缩容、服务降级、流量切换、服务发布与灰度。

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