序言
微博平台第一代架构为LAMP架构，数据库使用的是MyIsam，后台用的是php，缓存为Memcache。
随着应用规模的增长，衍生出的第二代架构对业务功能进行了模块化、服务化和组件化，后台系统从php替换为Java，逐渐形成SOA架构，在很长一段时间支撑了微博平台的业务发展。
在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。
我们先看一张微博的核心业务图(如下)，是不是非常复杂?但这已经是一个简化的不能再简化的业务图了，第三代技术体系就是为了保障在微博核心业务上快速、高效、可靠地发布新产品新功能。
第三代技术体系
微博平台的第三代技术体系，使用正交分解法建立模型：在水平方向，采用典型的三级分层模型，即接口层、服务层与资源层;在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台。下面是平台的整体架构图：
如上图所示，正交分解法将整个图分解为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由技术团队搭建框架，应用在所有业务场景中，运维基于此系统完善监控平台，业务和运维共同使用此系统，完成分布式服务治理，包括服务扩容与缩容、服务降级、流量切换、服务发布与灰度。
cache设计
这里简单说一下两个部分，一部分是Feed架构简介，第二是cache的设计。
微博技术核心主要三个，一条微博有很多关注的人，分别将你发表的微博分发到你所有关注的人，聚合就是打开微博首页这里看到我关注人的信息，以及这个微博信息的展现，微博在技术上也称之为status或者Feed，下面图就是一个典型的Feed。
Feed架构刚才是两种设计模式推或者拉，还有第三种方式叫做复合型。做到一定程度单纯推或者拉是不够的。推的话如果把Feed比喻成邮件，推就是inbo不惜是收到的微博，OUTPOX是已发表的微博，发表到所有的粉丝，查看就是直接访问到。PUSH优点就是实现简单，通常做一个种型是首选方案，缺点就是分发量。PULL发表是在自己的outbox，查看是所有关注对象的inbox。 优点节约存储，缺点是计算大量，峰值问题。当前访问量比较大是不是计算得过来，服务器是不是够用，假如说你的服务器是按照你峰值规划你的服务器，在平时时 候是非常多的空闲，这个是不合理，不管推和拉都有一些共同的难题比如说峰值的挑战，比如说世界杯活动在新浪微博每秒钟发表量达到2500条，可以使用异步处理2500个峰值，处理速度慢一点，你关注人不能马上看到，峰值过后保证系统不会被峰值压跨，下面就是cache，现在有一句话对于这种real—time就是说：传统硬盘已经不够用，很多东西要分放在硬盘里面才能满足需求。因此cache设计决定了一个微博系统的优劣。
里面是一种复合型，不是一个简单的推或者拉的类型，因为就是说像新浪微博到这个级别要做很多优化，从模型上就是一个推或者拉的模型，按照它的关系来说，把cache分成需要四种存储的东西，这两个里面跟索引比较类似，第三就是列表和客户自己资料。
看一下第一部分就是inbox微博首页开始ID列表，完全是内存里面，但是有一个缺点，要添加元素需要先AET再SET；第二部分outbox发出微博有存储最新ID在于聚合。为了高效，通常分两部分，第一就是说最新的一个ID列表比如说有100条内容，这个用户很久没有来，这个是空要过来取就要从我工作列表用ID地址聚合起来；第三部分是关注列表，这些都是纯ID，然后following，following加载开销比较大，上百万粉丝，越大的集合越容易变更，改变则需要deleteall减少使用followinglist场景；第四部分contetcache微博内容体里面有一个很重要的内容，热内容。这个用户有200万粉丝，这个内容是热内容，在线粉丝也非常多，多分防止单点访问瓶颈，最终格式预生成，apenAPI需要返回xml，json格式。
刚才说了介绍cache的架构，现在介绍cache的第二个方面就是使用流程。有一个典型的场景，比如说发表cache怎么操作，首页展现怎么操作。发表需要改变三个内容，首先要声称contentcache，对于常规contentcache也要做复制，如果对方粉丝在线会在inbox数值ID变更。
第三方面修改outbox，根据粉丝列表修改inbox数据列表，然后首页Feed操作流程。左边有两个：inbox，outbox。两个是可选的，如果inbox没有一个树型计算，会根据ID列表聚合起来反馈给I用户。
获取首页Feed的流程，首先间看inbocache是否可用，获取关注列表，聚合内容从following关系，根据idlist返回最终Feed聚合内容。最常用两个流程就是这样。
下面介绍微博cache经验谈，首先说流量。打开首页，这个时候打一个I来说，比如说contentcache为例，比如multigntn条Feed，cache大小等于N，并发清且如1000次/秒，总流量等于50，20K。假如微博机房里面有1万并发需要800MBPS贷款，如果不改变价格这个流量是实现不了。再一个1G内网做了很多压力测试，一般环境跑三四百兆已经不错了，你网内不光是访问cache开销，还有很多其他流量，因此微博需要优化带宽访问，可以把热门数据加载到localcache，要用压缩算法，可以做复制，有的时候将一个内部cache分组，不同的服务器组，访问不同的cache减少内网通信的开销。第一个问题就是带宽的问题，其中内销cache开销访问量大第一会碰到瓶颈。第二问题就是hotKeys，要访问姚晨的微博，要建设一个Ilocolcache，删除时间要把所有的都删除。
cache规划方面一些问题，将不同业务，不同长度KEY存储到不同的MEMcache，不同的业务有不同的生命周期，LRUcache小量，memorystorage大部分，更高效的内存利用。
mutex，什么情况会出现这个问题，比如说一个很热的内容，cache里面没有了，因为memcache不是很可靠的东西，你放在里面可能会消失，经常出现这样的情况：一个很热的cache没有了，因为微博系统有很多并发很热数据没有了，非常多的并发如果微博没有一个很好的策略，比如说几十个，几百个加一个内容这会是一个悲剧。给每个KEY加载MUTEX，这个并发连接取数据库，然后把mutex删除成规，这个时候我只需要一个连接，数据库加载到BD里面有可以了。
因为前面已经介绍很多内容，我今天介绍一个很简单的东西就是想关注更多微博平台的技术，有三个方向一个就是S2技 术沙龙，每个月举行一次，另外就是说对很多讲师光做讲座不过瘾，讲座只是传授别人东西，没有能够交流，所以微博对一线架构师有一个自己线下交流，一些实际中遇到的问题，对这些架构师有帮助提高，交流一下自己正在做，或者有一些东西还不成熟，不适合拿出来讲的东西，可以线下交流。另外微博有各新浪微博开发大会，会介绍更多微博平台架构分享的东西。
S2技术沙龙介绍了希望关注分享Web2.0技术，下面有一个它的网址，另外就是说介绍一下即将举行一个新浪微博开发者大会，主要除了宣传作用，希望更多分享新浪微博技术，比如说这个平台需要架构与存储，可能到时候讲比今天更深入一些，会讲一些sinaappengine技术，数据挖掘，合作与商业模式，开发者与平台。目前有一个开发平台的网站。
