了解一下新浪微博的集群技术利用及网站业务架构

　据了解，随着用户数量的不断扩大，在高峰期，新浪微博的服务器每秒都要接受超过100万的响应请求，压力前所未有。童剑表示，面对如此高的并发访问量，新浪在技术上也面临着巨大的挑战。例如，如何扩大整个技术平台的性能？如何扩大局部技术单位的性能？通过增加服务器，设计系统可以扩展服务能力。然而，服务器数量的增加将导致服务器采购成本的激增，大量服务器的快速部署将对效率提出新的挑战，新的困难源源不断地涌现。　　在这方面，新浪也在不断寻找更完善的解决方案来满足他们的需求。新浪网研发中心平台架构部的思路是：　　1、首先从大型技术体系中规划整体，确保性能问题、成本问题、效率问题和可靠性问题得到有效解决；　　2、然后从局部开始，确保每个技术单位在性能和可靠性方面都能满足需求；　　3、同时，在应用和系统设计中，提高了处理故障容错的能力；　　4、加强产品运维中的风险控制，提高监控的有效性。　　在海量数据处理方面，新浪利用HadopHDFS实现海量数据存储和Mapreduce分布式计算，部分数据也使用HBase进行存储和查询。　　在海量数据处理方面，新浪利用HadopHDFS实现海量数据存储和Mapreduce分布式计算，部分数据也使用HBase进行存储和查询。此外，Hive也被广泛使用、Zookeepr等技术。集群的运维管理和交互仍然是Hadoop应用的瓶颈　　Hadoop起源于互联网，也回馈于互联网。互联网企业可以说是Hadoop技术应用最广泛、最深入的领域。如今，大多数机构都部署了自己的IT业务系统。如何实现Hadoop技术与现有IT架构的无缝集成已成为许多用户非常*的话题。在童剑看来，目前互联网领域的Hadop应用在大规模使用中，瓶颈还是比较多的。一方面是集群运维管理和监控，这方面的工具还不够成熟，需要运维工程师有丰富的经验。除了掌握硬件资源的使用外，运维工程师还需要部署一些管理软件来实现管理。另一方面，由于集群中各组件之间的交互响应性能较差，集群达到一定规模后，应有针对性地进行改进和优化。微博平台的技术系统采用正交分解方法建立模型：在水平方向，采用接口层、服务层、资源层等典型的三级分层模型；在垂直方向，进一步细分为业务架构、技术架构、监控平台和服务治理平台。以下是平台的整体架构图：如上图所示，正交分解将整个图分解为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框架广泛应用于内部，在系统健壮性和服务治理方面，技术解决方案较为成熟，健壮性较强，Highavailability和Loadbalance策略是基于Config配置管理服务实现的(支持灵活的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由技术团队构建框架，应用于所有业务场景。运维基于该系统完善监控平台，业务和运维共同使用该系统，完成服务扩展和缩减、服务降级、流量切换、服务发布和灰度等分布式服务治理。最后，技术框架在平台上发挥着越来越重要的作用，推动了平台的技术升级、业务开发和系统运维服务。本文仅限于空间限制，未进行介绍，并将继续介绍核心中间部件的设计原则和系统结构。

以上就是关于了解一下新浪微博的集群技术利用及网站业务架构的相关介绍，更多了解一下新浪微博的集群技术利用及网站业务架构相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对了解一下新浪微博的集群技术利用及网站业务架构有更深的了解和认识。