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

微博平台的第一代架构是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，比如

以上就是关于解析新浪微博的网站整体架构的相关介绍，更多解析新浪微博的网站整体架构相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对解析新浪微博的网站整体架构有更深的了解和认识。