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

　据了解，随着用户数量的不断扩大，在高峰期，新浪微博的服务器每秒都要接受超过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由技术团队构建框架，应用于所有业务场景。运维基于该系统完善监控平台，业务和运维共同使用该系统，完成服务扩展和缩减、服务降级、流量切换、服务发布和灰度等分布式服务治理。最后，技术框架在平台上发挥着越来越重要的作用，推动了平台的技术升级、业务开发和系统运维服务。本文仅限于空间限制，未进行介绍，并将继续介绍核心中间部件的设计原则和系统结构。