如何实现秒级百万TPS？微博WAIC实时流计算平台架构演进

发布时间：2025-11-04 18:55:20 来源：技术快报 作者：域名

图片来自包图网

【.com原创稿件】WAIC 实时流计算平台为新浪微博提供可靠的何实毫秒级和秒级实时数据处理服务，通过提供统一的现秒数据源和配置化接入方式，帮助提高新浪微博实时作业的百进开发效率，降低部门开发与运营的微博成本。

2018 年 5 月 18-19 日，实时算平由 主办的流计全球软件与运维技术峰会在北京召开。

在“高并发与实时处理”分会场，台架新浪微博实时流技术平台负责人廖博带来了《WAIC 实时流计算平台的构演成长和繁衍》的主题演讲。

本文将按照如下四个阶段分享微博实时流计算平台的何实搭建历程，以及在创建过程中的现秒一些问题和解决方案：

初入实时流计算

首先介绍一下我们实时流计算平台开发历程：

上图是实时流计算的技术背景，常用的计算引擎有：Spark、Streaming、Flink、Storm、Flume 和 Kafka 等一些中间件。

我们 WAIC 实时流计算平台中，主要用到的计算引擎是：Storm、Kafka、Flume 和 Flink。

上图是实时流计算的第一阶段。这是一个经典的架构，它通过利用 Flume，将业务系统里的实时流日志数据写入 Kafka。

然后再利用 Storm 去读取 Kafka 里的数据，最后将数据进行相应的业务逻辑处理。

在该阶段，我们主要完成了如下两项工作：

上图是第一阶段相应的数据成果。彼时的数据量和集群个数都比较少，因此主要存在的问题包括：

上图是第一阶段所遗留的一些问题。

实时流计算平台初建

那么随着实时流计算的频繁使用、业务场景的增多、以及监控需求的提升，我们意识到需要搭建一个实时流的计算平台。

我们当时所提出的平台目标主要包括：

这是第二阶段实时流的初步架构图。在此，我们的接入日志方式丰富了许多。如图，我们既通过 Scribe 进行收集、又从 Kafka 以及 Mcq 里面读取数据。

然后通过 Scribe、或者其他的数据同步服务，将它们接入到实时队列之中，最后在不同的业务场景下，利用不同的实时集群进行处理。

自研 WeiPig 框架

为了降低开发人员上手实时任务开发的门槛，我们自行研发了一个 WeiPig 框架。

它具有如下四个主要特点：

同时，我们需要通过该 WeiPig 框架，让所有开发人员的工作模式“沉淀”下去，实现公司内各个部门的共享与协作。

统一监控平台

如前所述，在第一阶段，我们的监控实现方式基本上是：靠那些运行在不同服务器上的脚本，进行日志数据的采集，然后再发送报警邮件。

而进入第二阶段之后，我们利用如上图所示的实时流统一计算与监控平台，对作业情况予以了展示与配置。

即：该系统既可以展示相应的数据监控指标，又可以对数据监控指标进行相应的报警配置。

而这些监控指标数据都是通过不同的搜集工具进行采集，然后录入到 MySQL 数据库之中。

上图是第二阶段相应的成果。虽然此时已经有了 WeiPig 开发框架，但是我们的人工工作量依然不少。

由于 WeiPig 的插件主要是由平台方的几名开发人员来实现，因此插件数量不但较少，而且他们的工作量也达到了 80%。

另外，代码的重复率则仅占 50% 左右，这直接导致了异常排查的效率仍处于较低的水平。

同时，在监控配置上，我们仍需要手动配置，以及通过编写脚本，来搜集相关的指标数据。

在第二阶段之后，我们遗留下了不少问题，包括：

实时流计算平台发展

在步入实时流计算平台的第三阶段之后，我们提高了相应的宏观目标，即：

上图是当前实时流计算平台的架构图。数据流逻辑如下：

控制中心初现

由于前期各种作业(如 Storm)在向集群提交的时候，许多开发人员会自行配置一个本地环境，以实现直接提交，这就造成了平台方很难对集群进行有效的管控。

因此对于我们第三阶段的控制中心而言，其主要目标是：

上图是实时流计算平台的控制中心架构图。其流程如下：

上述提到过，一些开发人员可能会通过在自己的本机上配置相应的作业提交环境，以实现将作业提交到集群之中。

那么为了管控对应的业务组在集群上占用的资源量，我们在“资源决策服务”里，调用到了作业识别模块。

资源配置策略

为了提高公司的生产开发效率，我们在第三阶段实施了资源配置策略。同时，我们的核心目标点是：通过第二阶段的 WeiPig 开发框架，来鼓励各个业务团队贡献相应的插件。

其实 WeiPig 是一套规范协议，大家在贡献插件之前需要增加学习上的投入。因此，对于一些已经实施了计算能力的业务方来说，虽然有利于将旧平台迁移过来，但是他们不太愿意投入此类学习的成本。

所以我们想出了用资源去换取 WeiPig 前向发展的方法。我们将所有的平台资源按照基础资源、弹性资源、奖励资源和平台资源，四个方向进行划分。

其中基础资源仅占 1%，基本上只有一、两台机器。弹性资源有 20%，各个公司根据业务量和业务等级进行划分，当业务量多的时候，每一个业务都可以有自己的重要程度和优先级。

值得一提的是：奖励资源为 30%。它通过两方面标准：WeiPig 里贡献的 Function 数量，和这些通用 Function 会被多少业务方所使用到，来进行公式算法上的衡量。

如果你贡献的多，而且被其他业务方使用的也比较多，那么我们就会从所有平台资源的 30% 中，给你划分出更多的资源。

实时对账系统

为了满足某些高成功率场景的需求，我们在第三阶段自行设计了一个实时对账系统。

该系统的主要成绩是：满足实时计算平台完成 6 个 9 的数据成功率需求。

上图是实时对账系统的一个简单架构图。在数据处理开始时，我们会将数据写入实时对账系统，并打上开始标志。

同时，实时对账系统会将该数据的开始处理、和结束处理的标志，存放到存储服务上。

而图中下方的离线定时服务，会定时查询实时对账系统，并进行如下判断：

稳定性服务平台

另外，在第三阶段，我们将第二阶段的“统一监控平台”升级成了“稳定性服务平台”。

其目标有如下三点：

但是在第三阶段的稳定性服务平台上，一个作业被提交到集群上之后，稳定性服务平台会对集群上处理的数据量、处理延迟、错误量等通用指标进行统一生成。

因此，它在自己做管理资源时，会出现在一个集群中，某个服务器的 CPU 利用率已达 90%，而其他服务器的 CPU 利用率只占有 50%～60% 的情况。所以我们自行研发了对集群资源负载均衡的监控。

这里展示的是实时流计算平台稳定性服务的架构图。左侧的数据采集平台包括：Storm 指标项目数据收集、Kafka 数据堆积量的数据收集、日志收集平台、监控脚本运行平台、和服务器硬件资源的收集。

这是一个比较简易的、便捷的资源负载均衡的监控服务。完成统一采集之后，系统调用数据存储服务，经由服务平台的管理服务平台、运维服务平台、和第三方服务平台，对外面开发人员提供相应的服务。

上图是第三阶段相应的成果。目前，我们的平台每天能处理大约一千多亿的数据量，TPS 大约有百万每秒，作业个数则每天约有 150～200 个。

如今无论是多媒体相关的数字计算需求，还是微博相关的处理需求，我们的人工工作量已相对较少了，主要的工作量集中在编写 WeiPig 相应的配置文件上。相应的代码重复率也比较低，同样主要集中在 WeiPig 文件上。

另外，由于我们主要是到 HDFS 上去搜集和管控相应的日志，因此异常排查的效率适中。

而对于监控方式而言，我们大部分采用的是自动生成的方式，所以只对一些特殊要求才进行监控配置。

当然，目前的实时流计算平台仍有两个遗留问题：

目前我们采用的一种简易方式是：搜集各台服务器上的资源情况，然后用自己的程序进行判断和处理。如果某一台机器利用率高于其他服务器20%的话，那么我们认为其负载是不均衡的。

总结 DQRA 设计模式

我们在实时流计算开发的过程中，一边搭建业务平台，一边解决了不少问题。因此我们总结出了一套 DQRA 的设计模式。

DQRA 详解

它们分别是：

因此，我们认为：面对大多数的需求，我们可以把问题的实现拆解为上述四个属性中的某种。

例如：逻辑复杂度有难、中、易;数据量有大、中、小;可靠性是高、中、弱;等方面。

上述便是 DQRA 可能出现的不同组合，以及所对应的不同解决方法。

DQRA 案例分析

下面我们会介绍一个简单案例，它包含如下特性：

具体来说，它是一个图像分析与处理类系统，需要具有持续稳定的服务保证。因此，系统稳定是第一位的。

其次，它要求数据处理的成功率大于 6 个 9，从而能应对单日 5000 万的数据量。

因此，我们通过上述三个方面来实现该系统的需求：

因此，为了避免可能出现的图片分析失败，我们采用了实时对账系统，实现了必要的重试处理。

廖博，新浪微博实时流技术平台负责人，曾就职于搜狐、雅虎研究院、支付宝等公司参与 Data Highway、大数据系统、数据仓库、UUS(User Understanding Service)等第一代大数据生态系统的搭建工作;现就职于新浪微博，主导和开发实时流计算平台，基于该平台之上完成多媒体分析平台、物料池系统、样本生成平台等多个子系统的开发和建设。

【原创稿件，合作站点转载请注明原文作者和出处为.com】

相关文章