1亿用户以下的新浪微博平台架构

新浪微博在2014年3月发布了1.43亿月度活跃用户，在2014年新年的第一分钟发送了808，298条微博

是如此庞大的用户规模和业务量，以至于它需要高可用性(h a)、高并发访问和低延迟的强大后台系统支持。< br>

微博平台的第一代架构是LAMP架构，数据库使用MyIsam，后台使用php，缓存是Memcache

随着应用规模的增长，衍生的第二代架构已经将业务功能模块化、服务化和组件化，后台系统已经被php的Java所取代，逐渐形成SOA架构，长期支持微博平台的业务发展。

在此基础上，经过长时间的改造、在线操作、思考和沉淀，该平台形成了第三代架构体系。

让我们看看微博的核心业务图(如下)。很复杂吗？

，但这已经是一个不能再简化的简化业务图了。第三代技术系统是为了保证微博核心业务中新产品和新功能的快速、高效、可靠发布。

第三代技术系统

微博平台的第三代技术系统采用正交分解法建立模型:

横向采用典型的三级分层模型，即接口层、服务层和资源层；

在垂直方向上进一步细分为业务架构、技术架构、监控平台和服务治理平台

下方是平台的总体架构图:< br>

如上图所示。正交分解法将整个图分解成3*4=12个区域每个区域

代表水平维度和垂直维度的交集，并相应地定义了该区域的核心功能点，例如，区域5主要完成服务层的技术架构

下面详细描述了水平和垂直方向的设计原则，重点介绍了4、5和6中的技术组件及其在整个体系结构系统中的功能。

水平分层

水平维度的划分在大中型互联网后台业务系统的设计中非常基础，并体现在平台的每一代技术系统中。

这里是一个简单的介绍，为后续垂直维度的扩展铺平了道路:< br>

接口层主要实现与网页和移动客户端的接口交互，并定义了一个统一的接口规范。该平台的三个核心界面服务是内容(Feed)服务、用户关系服务和交流服务(单封私人信件、群信和群聊)

服务层主要是模块化和服务核心服务。这里，它被分为两种类型的服务。

类型是原子服务，它被定义为不依赖于任何其他服务的服务模块。例如，常用的短链服务和发射机服务都属于这种类型。泳道隔离在图中用来表示它们的独立性。

是另一种类型的组合服务，它通过各种原子服务和业务逻辑的组合来完成服务，例如Feed服务和通信服务。除了他们自己的业务逻辑，他们还依赖短链、用户和发射机服务。

资源层主要是数据模型的存储，包括通用缓存资源Redis和Memcached，以及持久数据库存储MySQL、HBase或分布式文件系统TFS和新浪S3服务

级别层次结构有一个从上到下依赖的特性。上层服务依赖于下层，而下层服务不依赖于上层，因此构建了简单而直接的依赖关系

对应分层模型，微博系统中的服务器主要包括三种类型:

前端机(提供API接口服务)、队列机(处理上行业务逻辑，主要是数据写入)和存储(mc、mysql、mcq、redis、HBase等)。)

垂直扩展技术架构

用于支持核心业务。这些中间件由业务驱动程序生成。随着技术组件越来越丰富，形成了完整的平台技术框架，大大提高了平台的产品研发效率和业务运营稳定性< br>

不同于上层在水平方向上依赖于下层的关系。在纵向上，以技术框架为基础支撑点，驱动和影响双方的业务框架、监控平台和服务管理平台。以下描述了核心组件

接口层网络V4框架

接口框架简化和规范了业务接口的开发，将通用接口层功能打包到框架中，并采用了Spring的AOP设计概念

接口框架基于泽西岛进行二次开发。接口(url、参数)是基于注释定义的。它具有内置的身份验证、频率控制、访问日志和降级功能。它支持接口层监控平台和服务治理。同时，它还具有自动化的Bean-json/xml序列化。

服务层框架

服务层主要涉及RPC远程调用框架和消息队列框架，这是微博平台在服务层应用最广泛的两个框架

消息队列

消息队列提供了先进先出的通信机制

位于平台内部。最常见的情况是异步地将数据的登录操作写入队列，队列处理程序成批地将数据读取和写入数据库。消息队列提供的异步机制加快了前端机器的响应时间。

其次，批量数据库操作间接提高了数据库操作性能。另一个应用场景是，该平台通过消息队列向搜索、大数据和商业运营部门提供实时数据。

mcq(memcache上的简单队列服务)消息队列服务广泛应用于微博平台

基于MemCache协议。消息数据被永久写入BerkeleyDB。只有两个命令，get/set。它也很容易监控(statsque)。它拥有丰富的客户端库，并且已经在线运行多年。它的性能比MQ高出许多倍

Motan RPC框架

微博Motan RPC服务，底层通信引擎采用Netty网络框架

序列化协议支持Hessian和Java序列化，通信协议支持Motan、http、tcp、mc等

Motan框架广泛用于室内。在系统健壮性和服务治理方面有相对成熟的技术解决方案。在健壮性方面，基于配置的配置管理服务实现了高可用性和负载平衡策略(支持灵活的故障转移和故障快速高可用性策略，以及负载平衡策略，如循环调度、LRU、一致哈希等)。)对于

服务治理，将生成完整的服务呼叫链数据、服务请求性能数据、响应时间、QPS以及标准化的错误和异常日志信息。

资源层框架有许多

资源层框架:

有密钥列表DAL中间件

，它封装了MySQL和HBase

具有定制的计数组件

；和Proxy

，它支持分布式MC和Redis。该行业在这些领域有很多经验可以分享。我想在这里分享平台架构的对象库和固态硬盘缓存组件。

对象库

对象库支持对微博中的对象数据进行方便的序列化和反序列化:当

被序列化时，JVM内存中的对象被序列化并写入到HBase中，生成唯一的ObjectID。当需要访问对象时，通过ObjectID读取

对象库支持任何类型的对象，并支持PB、JSON和二进制序列化协议。

微博中最大的应用场景统一将微博中引用的视频、图片和文章定义为对象，共定义了几十种对象类型，并抽象出标准的对象元数据模式。对象的内容被上传到对象存储系统(新浪S3)，新浪S3的下载地址被存储在对象元数据中

固态硬盘高速缓存

随着固态硬盘的普及，卓越的io性能使其越来越多地用于取代传统的SATA和SAS磁盘。有三种常见的应用场景:

1)来替换MySQL数据库的硬盘。目前，社区中没有针对固态硬盘优化的MySQL版本。即便如此，直接升级固态硬盘也能带来8倍左右的IOPS增长。

2)取代了Redis的硬盘以提高其性能；

3)在CDN中用于加速静态资源的加载< br>

微博平台将固态硬盘应用于分布式缓存场景，将传统的重发/移动+Mysql模式扩展为重发/移动+固态硬盘缓存+Mysql模式

固态硬盘高速缓存作为L2高速缓存，首先减少了大容量硬盘的高成本和小容量问题，同时也解决了数据库渗透带来的数据库访问压力。

垂直监控和服务治理

随着服务规模和业务变得越来越复杂，即使是业务架构师也很难准确描述服务之间的依赖关系

服务的管理和运营越来越困难。在这种背景下，参照谷歌的dapper和twitter的zipkin，该平台实现了自己的大规模分布式跟踪系统WaNguar。

WaNguard大规模分布式跟踪系统

与其他大中型互联网应用一样，微博平台由许多分布式组件组成

用户将通过许多业务系统或系统组件，并在通过浏览器或移动客户端的每个HTTP请求到达应用服务器后留下足迹。

，但这些分散的数据对故障排除或流程优化的帮助有限。

对于这种典型的跨流程/跨线程场景，收集和分析此类日志尤为重要

另一方面，收集每个足迹的性能数据，并根据策略对每个子系统进行流量控制或降级，也是保证微博平台高可用性的重要因素

应该能够跟踪每个请求的完整呼叫链接；

收集呼叫链路上每个服务的性能数据；

可以跟踪所有错误和异常；在系统中；

通过计算性能数据和比较性能指标(SLA)反馈到控制流。基于这些目标，微博守望系统应运而生。< br>

系统设计的核心原则是非侵入性的:

+

作为一个非业务组件，应该尽可能少地侵入或不侵入其他业务系统，保持对用户的透明性，并且可以大大降低开发人员的负担和访问门槛。

基于这种考虑，所有日志收集点都分布在技术框架中间件中，包括接口框架、RPC框架和其他资源中间件

WaNguard是由技术团队建立的框架，应用于所有业务场景。运行维护完善了基于该系统的监控平台。该系统由业务和运维共同使用，完成分布式服务治理，包括服务扩展和容量缩减、服务降级、流量切换、服务发布和灰度级。截至

年底，

技术框架在平台中发挥着越来越重要的作用，推动着平台的技术升级、业务开发、系统运维服务。本文篇幅有限，尚未介绍。核心中间件的设计原则和系统架构将在接下来的几天中不断介绍。