解析新浪微博的网站整体架构

微博平台的第一代架构是LAMP架构，数据库使用Myisam，后台使用php，缓存为Memcache。随着应用程序规模的增长，衍生出的第二代架构模块化、服务化和组件化了业务功能。后台系统从php取代Java，逐渐形成SOA架构，长期支持微博平台的业务发展。在此基础上，经过长时间的重构、在线运行、思考和沉淀，平台形成了第三代架构体系。我们先来看看微博的核心业务图(如下)。很复杂吗？然而，这已经是一个简化的无法简化的业务地图。第三代技术系统旨在确保新产品和新功能的快速、高效、可靠地发布在微博的核心业务中。微博平台第三代技术系统采用正交分解方法建立模型：在水平方向，采用接口层、服务层、资源层等典型的三级分层模型；在垂直方向，进一步细分为业务架构、技术架构、监控平台和服务治理平台。以下是平台的整体架构图：如上图所示，正交分解将整个图分解为3*4=12个区域，每个区域代表一个水平维度和一个垂直维度的交点，并定义该区域的核心功能点。例如，区域5主要完成服务层的技术架构。下面详细介绍水平方向和垂直方向的设计原则，特别是4、5、技术组件及其在整个架构系统中的作用。在大中型互联网后台业务系统的设计中，水平分层水平维度的划分非常基础，体现在平台的每一代技术体系中。这里是一个简单的介绍，为后续垂直维度的扩展铺平道路：接口层主要实现与Web页面和移动客户端的接口交互，定义统一的接口规范。平台的三个核心接口服务是内容(Feed)服务、用户关系服务和通信服务(单发私信、群发、群聊)。服务层主要模块化核心业务和服务，分为两类服务，一类是原子服务，定义为不依赖任何其他服务的服务模块，如常用的短链服务和发号机服务。使用泳道隔离图表示其独立性。另一种是组合服务，通过各种原子服务和业务逻辑的组合，如Feed服务和通信服务，它们除了自己的业务逻辑外，还依赖于短链、用户和发号机服务。资源层主要存储数据模型，包括通用缓存资源Redis和Memcached，以及MySQL的持久数据库存储、HBase，或分布式文件系统TFS和SinaS3服务。层次分层有一个特点，依赖关系从上到下，上层服务依赖下层，下层服务不依赖上层，构建了简单直接的依赖关系。与分层模型相对应，微博系统中的服务器主要有三种类型：前端机器（提供API接口服务）、队列机(处理上行业务逻辑，主要是数据写入)和存储(mc、mysql、mcq、redis、HBase等。).垂直延伸技术架构随着业务架构的发展和优化，平台研发实现了许多优秀的中间产品，用于支持核心业务，由业务驱动，随着越来越丰富的技术组件，形成了完整的平台技术框架，大大提高了平台的产品研发效率和业务运营稳定性。与上层依赖下层关系的水平方向不同，垂直方向以技术框架为基础支撑点，驱动影响业务结构、监控平台和服务治理平台的两侧。以下是核心组件。界面层Webv4框架界面框架简化规范了业务界面开发，将一般界面层功能包装到框架中，采用Spring面向截面(AOP)设计理念。基于Jersey的界面框架进行二次开发，基于annotation的界面定义(url,参数)，内置Auth、频率控制、访问日志、降级功能，支持接口层监控平台和服务治理，以及自动化Bean-json/xml序列化。服务层框架服务层主要涉及RPC远程调用框架和消息队列框架，这是微博平台在服务层中应用最广泛的两个框架。MCQ消息队列消息队列提供了先入先出的通信机制。在平台内，最常见的场景是将数据的登陆操作异步写入队列，批量读取并写入DB。消息队列提供的异步机制加快了前端机器的响应时间。其次，批量DB操作间接提高了DB操作性能。另一个应用场景，平台通过消息队列，实时数据提供给搜索、大数据和商业运营部门。MCQ广泛应用于微博平台内部。(SimpleQueueServiceOverMemcache)基于Memcache协议的消息队列服务，将消息数据持续写入BerkeleyDB，只有两个命令，同时也很容易监控(statsqueue)，clientlibrary丰富，在线运行多年，性能比普通MQ高很多倍。MotanRPC框架微博MotanRPC服务，底层通信引擎采用Netty网络框架，序列协议支持Hessian和Java序列，通信协议支持Motan、http、tcp、mc等，motan框架广泛应用于内部，在系统健壮性和服务治理方面，技术解决方案较为成熟，健壮性较强，基于Config配置管理服务，Highavailability和LoadBalance策略(支持灵活的Failover和FailFastha策略，以及RoundRobin、LRU、LoadBalance策略，如consistenthash)，在服务治理方面，生成完整的服务调用链数据，服务请求性能数据，响应时间(ResponseTime)、QPS和标准化Erroror、Exception日志信息。资源层有很多框架，包括包装MySQL和HBase的Key-ListDAL中间件、定制计数组件、支持分布式MC和Redis的Proxy。在这些方面，业界有更多的经验分享。在这里，我将分享平台架构的对象库和SSDCache组件。对象库对象库支持便捷的序列化和反序列化微博中的对象数据:序列化时，将JVM内存中的对象序列化写入HBase，生成唯一的ObjectID。当需要访问对象时，通过ObjectID读取。对象库支持任何类型的对象和PB、JSON、二进制序列化协议，微博中最大的应用场景统一定义了微博中引用的视频、图片和文章，总共定义了几十种对象类型，并抽象了标准对象元数据Schema，将对象内容上传到对象存储系统（SinaS3），并将SinaS3的下载地址保存在对象元数据中。随着SSD硬盘的普及，SSDCache的优越IO性能越来越多地用于替代传统的SATA和SAS磁盘。有三种常见的应用场景：1）更换MySQL数据库的硬盘。目前，社区还没有SSD优化的MySQL版本。即便如此，直接升级SSD硬盘也可以带来大约8倍的IOPS升级；2）更换REDIS硬盘，提高其性能；3)在CDN中使用，以加快静态资源的加载。在分布式缓存场景中，微博平台将SSD应用于传统的Redis/MC Mysql模式扩展到Redis//MC SSDCache 作为L2缓存，SSDCache首先降低了MC/Redis成本高、容量小的问题，解决了穿透DB带来的数据库访问压力。垂直监控和服务治理随着服务规模和业务变得越来越复杂，即使业务架构师也难以准确描述服务之间的依赖，服务管理和维护变得越来越困难，在此背景下，参考谷歌和谷歌，平台实现了自己的大型分布式跟踪系统谷歌。与其他大中型互联网应用程序一样，WatchMan的大型分布式跟踪系统由许多分布式组件组成。用户通过浏览器或移动客户端的每个HTTP请求到达应用服务器后，将通过多个业务系统或系统组件，并留下足迹(footprint)。与其他大中型互联网应用程序一样，WatchMan的大型分布式跟踪系统由许多分布式组件组成。用户通过浏览器或移动客户端的每个HTTP请求到达应用服务器后，将通过多个业务系统或系统组件，并留下足迹(footprint)。然而，这些分散的数据对问题调查或流程优化有有限的帮助。汇总、收集和分析这类日志对于这样一个典型的跨过程/跨线程场景尤为重要。另一方面，收集每个足迹的性能数据，并根据策略对每个子系统进行流量控制或降级，也是确保微博平台高可用性的重要因素。能够跟踪每个请求的完整调用链路；收集调用链路中每个服务的性能数据；跟踪系统中的所有Eror和Exception;通过计算性能数据和比较性能指标(SLA)回馈控制过程(controlflow)基于这些目标，微博的Watchman系统诞生了。该系统设计的核心原则之一是低侵入性(non-invasivenss)：作为非业务组件，应尽量少入侵或不入侵其他业务系统，保持对用户的透明度，可以大大降低开发人员的负担和接入门槛。基于此，所有日志收集点都分布在技术框架的中间件中，包括接口框架、RPC框架和其他资源中间件。WatchMan由技术团队构建框架，应用于所有业务场景。运维基于该系统完善监控平台，业务和运维共同使用该系统，完成服务扩展和缩减、服务降级、流量切换、服务发布和灰度等分布式服务治理。这里简单说一下cache设计的两部分，一部分是Feed架构简介，二是cache设计。微博技术主要有三个核心。一个微博有很多关注的人，把你发表的微博分发给你所有关注的人。聚合是打开微博主页，看看我关注的人的信息和微博信息的展示。微博在技术上也叫status或者feed。下图是典型的feed。Feed架构只是推或拉两种设计模式，第三种方法叫复合型。在一定程度上简单地推或拉是不够的。如果把Feed比作电子邮件，推送就是inbo毫不犹豫地收到的微博。OUTPOX是已发布的微博，发布给所有粉丝，直接查看。PUSH的优点是实现简单，通常做一种类型是首选方案，缺点是分发量。PULL发表在自己的outbox上，查看inbox是所有关注对象。节约存储的优点，缺点是计算大量，峰值问题。目前的访问量是否可以计算，服务器是否足够，如果你的服务器是根据你的高峰计划你的服务器，通常是很多空闲，这是不合理的，无论推动和拉动有一些共同的问题，如高峰挑战，如世界杯活动在新浪微博每秒发布2500，可以使用异步处理2500高峰，处理速度慢，你关注的人不能马上看到。峰值过后，确保系统不会被峰值压跨。以下是cache。现在有句话说传统硬盘不够用，很多东西要分在硬盘里才能满足需求。因此，cache设计决定了微博系统的优缺点。因此，cache的设计决定了微博系统的优缺点。它是一种复合型，不是一种简单的推或拉类型，因为也就是说，像新浪微博到这个水平做很多优化，从模型是一个推或拉模型，根据它的关系，cache分为四个存储，两个类似于索引，第三是列表和客户自己的信息。看第一部分是inbox微博首页的ID列表，完全是内存，但是有一个缺点，需要先AET再SET添加元素。；第二部分outbox发布微博，最新ID存储在于聚合中。为了高效，它通常分为两部分。首先，最新的ID列表有100个内容。这个用户已经很久没来了。如果你想来取它，你必须从我的工作列表中使用ID地址来聚合它；第三部分是关注列表。这些都是纯ID，然后following。following的加载成本相对较大。有数百万粉丝。收藏越大，变化越容易，变化要求deleteall减少followinglist场景的使用；第四部分contetcache微博内容体中有一个非常重要的内容，热门内容。这个用户有200万粉丝。这个内容是热门内容，有很多在线粉丝。多点防止单点访问瓶颈，最终格式预生成。apenAPI需要返回xml和json格式。这个用户有200万粉丝。这个内容是热门内容，有很多在线粉丝。多点防止单点访问瓶颈，最终格式预生成。apenAPI需要返回xml和json格式。我刚才说过介绍cache的架构。现在介绍cache的第二个方面是使用过程。有一个典型的场景，比如如何操作cache发布，如何操作主页显示。发布需要更改三个内容。首先要声称contentcache，复制常规contentcache。如果对方粉丝在线，他们会在inbox数值ID上更改。第三方面修改outbox，根据粉丝列表修改inbox数据列表，然后主页Feed操作流程。左边有两个:inbox，outbox。如果inbox没有树型计算，两者都是可选的，将根据ID列表聚合反馈给I用户。获取首页Feed的过程首先取决于inbocache是否可用，获取关注列表，聚合内容从following关系中返回最终Feed聚合内容。这是最常用的两个过程。下面介绍一下微博cache的经验，先说流量。打开主页，这个时候打个I，比如contentcache，比如