如何向流量暴击说不：揭秘微博|腾讯|京东高可用之道

一个无数工程师的女朋友钦定的男朋友，公开恋情的直接受害者居然还是工程师，宿命的轮回啊……这是上市公司私有化引发的股民恐慌，更是娱乐圈向技术圈的悍然入侵。网络洪峰如此可怕，抗洪抢险责任重大，让我们近距离观摩一下，技术圈复联如何筑起高可用大堤。

微博如何应对流量“暴击”

现在有越来越多的人选择用微博这一社交网络平台来公布消息，那么微博要如何应对众多的流量“暴击”呢？下面让我们一起来看一下。

1.对大规模、高负载系统问题的排查方法

微博主要面对的是高并发、大数据量、高负载的业务压力，并且伴随着热点事件会有突发的请求峰值。作为典型的互联网后端服务之一，微博平台部署了大规模的基于Linux系统的集群，使用 Java作为主要语言，使用了一些外部的框架比如Tomcat、Storm、Hbase等，也应用了一些自研的系统，比如RPC框架Motan、服务发现Config Service等。不同企业和行业采用的方案可能有区别，但从问题排查这个角度来说都是类似的。下面给大家总结一些系统设计方面的建议。

• 问题排查是复杂的、不可控的，所以不要把排查和解决混在一起，尽量先解决、再排查。
• 系统要尽可能地对外暴露内部状态和干预手段。
• 系统是不稳定的，因此高可用架构设计必须要隔离，不管是哪种依赖方式，都要考虑到“实在不行了”的情况。
• 问题的原因、传播路径和现象不是一一对应的。墨菲定律说如果有可能出问题，就一定会出问题。

2.基于Docker 的混合云平台设计与实践

• 微博的业务场景及混合云背景

针对产品功能迭代快、业务模块多等挑战，微博的技术团队基于 Docker 及公有云来构建一套具有弹性伸缩的混合云系统。利用过去的私有云加公有云，及公司内闲置的运算资源、混合云，兼具安全性与弹性扩展能力，其特点如下图所示。

• 混合云 DCP 系统设计核心：自动化与弹性调度

Docker Container 混合云平台包含4层架构：主机层、调度层及业务编排层，最上层则是各业务方系统，如下图所示。底层的混合云基础架构则架构了专线，打通微博内部资料中心以及阿里云。

• 引入阿里云为第3机房，实现弹性调度架构

微博机房的部署架构总共分为3层，依次是最上层域名以及负载均衡层。中间则是Web 层，包含各种前端框架，RPC 层以及中间件（Middleware）。而最下层则包含MySQL、Redis、HBase 等资源架构。微博核心服务主要分布在2个机房，两者互相作为灾难备份用途，而第3个机房则采用外部阿里云。

• 大规模集群操作自动化

微博DockerContainer 混合云DCP设计思想，核心目标就是透过自动化操作大规模集群，进行弹性调度资源的任务，要完成此任务，必须经过3个流程：设备申请、设备初始化及服务上线。总体来说，一键扩容的流程如下图所示。

• 不怕峰值事件

在用微博混合云DCP 时，会优先调度内部的共享池资源的运算资源。但是在红包飞、春晚时，则必须调度外部的运算资源。正常状况下，阿里云只需提供几百个运算节点，并且在5 到10 分钟内完成部署任务。但是面对春晚、红包飞的峰值流量，则要提供数千个节点。这对阿里云的机房也是有较高要求的。

腾讯云大禹系统进行DDoS防护

大禹是腾讯云自主研发、部署的一套分布式 DDoS 防护系统。三年前，大禹系统遭遇最大的攻击流量即已高达297Gbps，针对域名系统流量达1Gbps以上的DDoS攻击日均187起。

1.大禹系统设计理念

大禹系统的设计精髓：大禹治水，分为治之，而非堵而治之。

2.DDoS攻击

下面来举个通俗易懂的例子对 DDoS进行说明，城东开了一家牛肉面馆，生意红火，顾客络绎不绝。某天，一个地方恶霸召集了手下的一批小弟，一窝蜂地涌进牛肉面馆，霸占了所有座位，只聊天不点菜，导致真正的顾客无法进店消费。由此，牛肉面馆的生意受到影响，损失惨重。

如果把这家面馆看作一家互联网企业，那么这群地痞的恶行，就是典型的分布式拒绝服务，也就是我们所说的DDoS攻击。

3.大禹系统的应对方案

如机房带宽 <DDoS 带宽，那么就肯定无法承受攻击，因此大禹系统选择全国分布式（腾讯既有数据中心）做防护。既然是分布式部署，相当于把流量分摊开来，大禹系统就是这样以分布式来保证服务可用。

接入大禹系统后的流程如下所示：

• 需要把用户请求以cname的形式重定向到大禹系统
• 用户请求→域名→大禹系统→业务侧服务器
• 时延增加100ms，可用性不会降低

除了DDoS基础功能外，大禹系统已完美支持：

• CC防护
• WEB漏洞扫描
• WAF

京东如何应对618、双11

京东交易系统基本情况如下图所示。

下面是京东的交易结构图，从左到右依次展示了首页、单品列表、购物车、结算等购物信息流端。在移动端、微信、手机QQ等入口进行交易时都遵循此规则。

如上图所示，以购物车为例，它是典型的分服务分层结构，数据从入口进入后经过功能接口再到基础业务功能接口。其中的强依赖服务是经过关键路径时要调用的服务，是主流程中不可缺少的一部分。

1.应对大促的第1 步：全链路全流量线上压测

技术团队对上次大促时系统的整体调用量有了整体的了解，往年大促的峰值数据也可被用作参考。但是经过半年的业务跟进，京东系统在结构、数据等方面已经发生了很大的变化，其承受量也相应改变了，此时需要知道此时的系统能承受多大的订单量，所以压测成为了重要的一环。

2.应对大促的第2 步：根据压力表现进行调优

下面给出了4 种调优方法。

• 多级缓存
• 善用异步
• 超热数据的缓存
• 数据压缩

3.异步和异构

• 接单系统的异构

这是异步异构用得最多的一个系统。在一次性提交订单、购物车的接单过程中，我们选择直接提交一份数据，这样做是十分高效的。如果按照传统的做法，即直接写到表里面，会有很多张表需要写入，如订单明细表、促销明细表、优惠券表等等，这样就造成了瓶颈。

如果先写到XML中，再异步，调动某一个状态机，通过管道服务后衍生出来拆分成订单中心数据，自己的开发的异步工具去拆分到表里，同时异构到针对功能的订单存储，如下图所示，异构之后，单个系统应对峰值的能力都得到了提升。

• 订单中心的异构

我们对提交订单、接单页做了异步处理。细分订单中心又会有很大的异构，可分成4个子系统来分别调用，如下图所示。订单中心会产生列表服务数据，列表服务数据根据PIN的维度用户维度看到数据存储，通过同步写不校验结果，用异步补全、拉取机制，写一份存储。

订单中心有一个列表服务的存储，及订单详情的存储，订单详情的存储是根据订单维度去存的，这一块是根据PIN存的。

第 3、4部分是特意单拎出来的状态服务及跟踪服务，后续的物流生产跟它直接挂钩，对其异构之后，订单中心应对峰值的能力得到了提升。

• 商品页的异构

在商品页中商品数据服务的整体异构概况如下图所示，后端数据运营人员通过系统录入到管理系统中，再通过发布系统将消息发布出去。商品前端系统接到消息后会调用数据服务生成商品页。这个消息会写自身的存储，我们会装A包（基础数据）、B包（扩充数据）、C包（特殊标识等）。

商品服务会根据不同的调用方进行个性化的优化部署，如订单系统只想知道调用的商品是否是生鲜、易碎品，促销时只需要与价格有关的特殊属性等。

访问量特别大的可以通过接收商品的变更通知，然后异步调用商品服务，存自身系统需要的商品属性。

如果一个商品服务真正做大了，可以参考一个大的系统进行拆分异构，当然，如访问量和数据量都不是很大，且在近期内也达不到，此时不建议盲目地进行细分。

4.应对大促的第3 步：分流与限流

如果系统超过最高承受流量，我们将直接拒绝超出的流量，以便保护后端的服务，这就是限流。

Web 通过利用 IP 加 PIN 风控数据，根据某个业务逻辑（一个商品一天内的订单量或者一位用户一天内的下单量）来限流。渠道可以按App、PC、微信等分开，如下图所示。下面讲秒杀系统是怎么来的。秒杀系统是限流和分流的典型实例。

5.应对大促的第4 步：容灾降级

如果做了分流、限流，系统还是没抗住，在高压下出现了问题，那么就要准备做容灾降级。容灾降级有多种方向，如机房级容灾、网络容灾、应用容灾，托底容器，还需要保证基础服务是正常的。

6.应对大促的第5 步：完善监控

每当临近双11、618 时，京东系统都需要有运维基础的网络监控、机器性能监控，业务监控、订单量监控、登录量监控等应用级监控。

下图展示了方法监控，每个方法会监控到TP99（即当满足99%的网络请求时所需要的最低耗时，还会有对成功率、失败率、总的调用次数等的监控）。

我们有对订单量的监控，如下图所示，一旦发现问题就会报警，我们自己还会衍生出对应用的监控。比如对库存来说，预算是最重要的；在提交订单时，保证提交订单成功是最重要的。针对库存，可以写一套监控系统出来，针对优惠券、购物车，可以写一个小的监控系统去监控。可以说，监控在大促期间起到了“眼睛”的作用。

本文采摘自烫手新书《高可用架构（第1卷）》，下图扫码或点击 阅读原文 可以继续了解详情。