序文微博渠道榜首代架构为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技能，数据发掘，协作与商业形式，开发者与渠道。现在有一个开发渠道的网站。