共计 6184 个字符，预计需要花费 16 分钟才能阅读完成。
导读：本文整顿自高可用架构与数列科技联结举办的技术沙龙，数列科技资深架构师徐汉彬的主题演讲。围绕“峰值流量下的高并发实际”，次要介绍了其在腾讯 QQ 会员流动平台的高可用架构实际。以下为演讲摘录。
明天分享的主题的是《面向大规模流量流动的高可用架构实际》，在开始之前先做个简略的自我介绍，我叫徐汉彬，在进入数列科技之前负责过 QQ 会员流动经营平台，把这个平台从日 PV 百万级别做到 10 亿级别，在应答大流量流动这一块积攒了肯定的教训，明天就这个主题方向跟大家做一个探讨。
分享的内容次要分为三个局部：
1. 大流量流动的零碎扩容评估办法
2. 零碎高可用架构设计实际
3. 大规模流量流动的实际案例
大流量流动的零碎扩容评估办法
大流量流动有多种形式，除了咱们常见的电商大促（双 11、618 等），近几年还衰亡了一种新模式——直播卖货。一个出名主播在比拟短的工夫里，疏导粉丝大量下单，这是一种典型的大流量场景，对系统的稳定性收回较高挑战。
另外一种比拟常见的流动模式是营销流动，例如春节红包、周年庆。
流动的流量起源，包含外部资源、内部付费购买的广告资源和第三方单干导流。公司在流动上投入了大量的资金，参加用户泛滥，如果流动中途呈现问题，不仅对产品口碑的影响十分负面，而且会有金钱损失，还波及到与第三方单干失败的问题。
举个例子，假如你的流动跟春晚单干，春晚到了某个环节让大家拿起手机现场扫码，这时零碎挂了，扫码失败，这种情景就十分难堪。遇到这种状况，第一个找你的可能不是你的领导，而是内部的第三方单干商，由此可见，关键时刻的零碎高可用有多重要。
大流量流动面临的挑战次要分为三个局部。
第一个挑战是流量评估难 ，扩容的量级并不是张口就来，如果你跟运维说要裁减 10 倍容量，他肯定会反诘你为什么，你要拿出扩容的正当根据。
第二个挑战是架构扩容难 ，即便咱们评估出了比拟精确的流量峰值，又该怎么进行零碎扩容呢？古代 IT 零碎架构的复杂度越来越高，尤其是当初风行的微服务架构，它的节点数越来越多，服务之间的调用关系非常复杂，链路的梳理自身也是一大难点。
第三个挑战是怎么进行高可用施行。咱们把流量评估和链路梳理扩容都做好了，流动在大流量到来的那天就没有问题了吗？当然不是，所以第三个问题就是怎么进行高可用施行。
想要解决上述挑战，绕不开业务和零碎的双重复杂度问题。
微服务架构的复杂性，加之业务的复杂性，使得整个零碎盘根错节、难以被人类了解。即便是公司的架构师、业务研发同学也很难讲清楚零碎整个链路的每一个细节和服务之间的调用关系，因为此时的零碎曾经是一张宏大又相互交织的的网络了。
要 解决流量评估的问题 就得进行精密的链路梳理，梳理的第一步就是画架构简图，把每个架构大的模块画进去，再依据架构简图进行业务性能链路拆解。
链路图梳理实现后，咱们就能够 开始预估扩容量 了，这里波及到三个重要的指标：推广量、环节转化率、单 UV 的申请总数。
第一个指标推广量，个别状况下会以每秒广告的曝光量计算。将不同广告渠道的曝光量加起来就能失去预估的推广量级了。
还有一种形式是计算 APP 利用顶峰每秒用户的登录数，这个数值约等于推广的每秒曝光量。
个别预测的每秒推广量都在零碎现有容量的 10 倍以上，按这个推广量去扩容，零碎根本没有问题，但会它会造成比较严重的资源节约。
这时则须要用 第二个参数来辅助咱们进行更粗疏的评估，它叫做环节转化率。以红包流动为例，用户看见红包流动，但不肯定会点击进入页面，进入页面也不肯定会支付红包，每一个环节都有环节转化率。
预估环节转化率个别有两种办法，一种是根据过往的教训数据进行估算；另一种就是提前演习，提前给局部用户推送流动，疾速精确地收集到每一个环节转化率，有条件的公司个别会采纳这种形式。
还有一个参数是咱们须要特地留神的，就是单 UV 的申请总数 ，为什么要特地关注呢？
因为用户进入一个流动页面，他可能会查问个人信息、查看流动记录，通常不止一个申请动作，所以你在计算后端压力时不能只算用户进入流动的每秒峰值，还要算上其余申请动作。假如用户均匀有 4 个申请动作，那你的流量就要乘以 4，它有一个放大效应。
通过后面 3 个指标咱们就能计算出后端会接受多少流量压力，进而得出扩容的预估值。最初把扩容容量设置为预估值的 3 倍，这个 3 倍并不是凭空臆想，而是从过往大量的流动扩容教训中总结得来的法则，流动当天的峰值通常是惯例均值的 3 倍。
具体怎么计算咱们来举个例子，假如咱们是 100/ S 的曝光量，只有 60% 用户进入了支付页面，这其中又只有 50% 点击了支付按钮，那后端收到的申请是 30/S，依据单 UV 的申请总数来说，整个后端起码要撑持 120/ S 的压力，加上 3 倍准则那么后端最终的扩容也就是 360/S。支付页面的流量峰值则为 180/S，这时你带着数据去找运维扩容就有理有据了。
某流动容量评估失去后果是 9.6W/S，依据三倍准则，整个业务链路要扩容到 30W/S，然而，在实操扩容过程中会发现局部利用很难扩容。举个例子，像 Web server 这种很容易做平行扩容，只有机器足够就能够扩容下来，但有些接口日常也就 2000-3000/ S 的 QPS，要扩到 10 万 QPS 根本就是不可能的，也没有那么多的资源和精力。这就波及到扩容的具体实际了，也是咱们接下来要说的零碎高可用架构设计的实际内容。
零碎高可用架构设计实际
通常来说，咱们零碎高可用架构实际有三大扩容因素：全链路 QPS、机器带宽、存储大小。
全链路 QPS 最容易被大家了解，咱们也最关注，就不做过多的开展。
机器带宽问题，流量越大越容易遇到。假如 CGI 申请达到 10W/S，通常它的申请存储不是一次，过后咱们的惯例业务申请存储高达 7 - 8 次，包含查问流动配置、查问用户参加记录、查问其余关联信息等。这个 10W/ S 就象征存储端须要接受大几十万每秒甚至百万每秒的量，如果一个存储占 1KB 或者大几百 KB，在这个量级下存储数据就相当宏大了，应用百兆级别网卡显然就会遇到网络带宽瓶颈问题。
接下来说说存储大小，这里说的存储大小通常不是指硬盘的存储大小，而是指内存，它也比拟容易遇到瓶颈。大多数公司有应用 Redis 类的 Key-value 存储，也有局部公司应用自研的 Key-value 存储，通常写入的数据会先写入内存，再通过定时淘汰机制，同步到本地的 SSD 或者磁盘。在大流量场景下，内存很容易被写满，如果没有事先评估，流动当天几百 G 的内存会霎时被写满。
还有一个不得不提的内容就是动态资源，它是咱们网页申请的图片、JavaScript 和 CSS 款式，通常它的瓶颈不在零碎自身。个别状况下，如果不思考带宽的限度，在一台配置很一般的机器上搭建一个 Nginx 来压测动态资源的申请性能，能够轻松达到数千 QPS。然而，如果思考到动态资源的大小，加上单个用户关上一个页面就会申请很多动态资源的理论状况，申请的动态资源的大小很较容易就超过 1M 了。这时第一个撑不住的就是机器的进口带宽，而不是动态资源服务器自身的性能。
针对动态资源问题，咱们有罕用的应答办法——离线包推送机制。在流动开始前几天就把动态资源推送到沉闷用户的的手机里，这样流动当天九成以上的流量都是本地的，他基本没有发动网络申请，以此来解决 CDN 的申请压力，解决带宽问题。
实现扩容只能说在实践上没问题，接下来说说高可用架构建设的要害要点。概括起来就是几个点：过载爱护、柔性可用、容灾建设、轻重拆散、监控体系、数据对账。
监控体系很重要，咱们须要探知这个零碎处于什么状态，并且呈现问题时须要一些计划去应答它。
后面的分享提到过一个问题，有些接口日常也就 2000-3000/ S 的量，没有那么多的资源和精力扩到 10 万 /s，那怎么办呢？
对于零碎链路架构优化，咱们罕用的形式有三种，第一种是异步化，这个好了解，临时没有这个能力执行完，就放到音讯队列里缓缓消化。第二种是内存级的缓存，把须要拜访的数据提前放到内存级的 Cache 里。第三种是服务降级，这个比拟罕用，就不做过多介绍了。
通过这些办法就能够把链路的性能晋升起来。
对于过载爱护它的的外围指标是局部不可用至多比彻底不可重要强，次要的实现伎俩是进行分层流量管制。这些层级蕴含推广层、前端层、CGI 层和后端服务层。针对推广层，只能在最坏的状况应用，因为它要对广告进行下架解决，不到万不得已，公司也不违心采纳这个形式，它也会影响流动的业务成果。针对前端层，能够实现随机弹出倒计时，限度用户 1 分钟内不能发动新的网络申请，有助于削平流量峰值。其余流量管制层的实现大同小异，不做过多的开展。
对于部署，咱们应该把重要的外围的一些操作给爱护起来，例如，在上述案例中，比拟重要的是发货，它不应该被其余操作影响。如果查问操作不可用，用户再刷新一次页面就好了，但如果发货不到账，用户会间接投诉，所以上述案例就把发货操作拆出来独立部署了一套异步发货集群。
柔性可用咱们应该怎么实现呢？
个别有两个方向，第一种是设置超短的超时工夫，例如，给平安接口设置超时工夫为 30 毫秒，假如那天平安接口真的挂了，30 毫秒对于一个百毫秒级别的申请来说，用户也不太能感知到，流动的体验还是好的。另外一种，就是间接不等网络回包的形式，例如 UDP 服务。
在容灾建设中，咱们要大胆提出假如，假如各个外围的服务和存储都可能挂掉，依据假如去制订对应的容灾和解决方案。比方应答机房停电、网络故障，咱们能够做跨机房跨网络部署，这样即便电信光纤被挖断，服务还能放弃根本失常。另外要做好应急预案，把所有要害节点故障的假如对应的解决计划全副做成开关模式，防止在流动当天还要去跑日志和写解决脚本。
针对监控与对账，咱们必须建设多维度的监控体系，在流量峰值的压力下局部监控可能会呈现问题，多维度的监控能帮忙咱们探知零碎的实在状态，有助于咱们采取正确的应答措施。
对于对账能力，如果发货失败了，当天值班的同学须要看跑线上日志和写补发脚本，那么半个小时、一个小时就过来了。值班同学通常都比较忙，所以最好的形式就是提开发好，当天如果发现问题，它就能主动去检测失败的日志并且进行补发。
大规模流量流动的实际案例
后面讲了比拟多对于大流量流动的架构筹备工作，这一部分咱们讲讲具体的实际案例。
第一个案例是某年某业务的春节红包流动，只管后期做了十分度多的筹备，流动上线时还是呈现了一系列问题，但好在都在咱们的预案之内，算是有惊无险。
预先咱们也进行了反思回顾，呈现那么多问题是为什么？首先就是没有遵循 3 倍扩容准则，再比如说链路梳理没有到位，上面就是咱们的一些总结内容。
依据咱们的过往教训，最危险的流动反而不是大型流动，因为为了确保大流动的顺利开展，公司会抽调很多骨干参加进来，即便呈现问题通常也是小问题。而中小型流动的流量不会太大，没有什么威逼。最容易出问题的恰好是那些中大型流动，接下来具体讲讲另一个中大型流动案例。
在某游戏的年度流动我的项目中，咱们做了一些评估和筹备工作，但不可能看待每个流动都像看待春节红包流动那样。过后咱们派了 2 集体看了一下，各个线上模块团队负责压测各自的模块，都反馈没问题，流动就上线了。流动当天凌晨我被电话叫醒，零碎出问题了，过后有很多用户曾经无奈加入流动了。
过后的 Web 零碎是基于 PHP 和 Apache，采纳 Apache 的多过程模式（perfork）。一个后端服务响应工夫个别在几十毫秒，一个 worker 过程 1 秒钟应该能够解决十多个申请，但到了顶峰期间，在大流量的压力下，后端服务的响应工夫从几十毫秒飙到了几百毫秒甚至是 1 秒。这个时候 1 个 wrker 过程 1 秒钟只能解决 1 个申请，无奈及时处理最终导致申请沉积。咱们趁着玩家在凌晨的休息时间去做了不少补救工作，包含降级及其他的动作，通过一个通宵的致力，用户能够失常进入流动了，但还没有齐全解决。第二天下午咱们又到公司持续，48 小时连轴转从新发版后终于解决了问题，安稳度过了那次流动危机。这种大中型的流动最容易出问题，因为通常咱们不会给与足够的关注度。
总结一下大流量流动后期须要做的一些总体的教训和流程，首先是绝对正当的评估 & 梳理计划，再进行架构上的优化和调整，最初就是整顿紧急预案。
我间断加入过三年春节红包流动流动，每一年都提前大略一个多月招集外围骨干来出具计划，每年都做很多筹备，可每年都有一些小问题。
反思为什么投入大量人力物力资源，零碎还是出问题？
究其实质，我感觉次要是三个方面：第一很多时候测试环境、甚至性能环境无奈代表实在的生产环境；第二，各个部分高可用不代表整体高可用；第三是零碎的成长性，简单的业务零碎在继续迭代、收缩，明天没性能问题，不代表今天没问题。
想让生产环境的性能取得保障，不出问题，从这个点登程咱们有一个明确的摸索方向——常态化的生产环境性能测试。
大量的筹备工作都是为了保障线上环境可能达到肯定的性能指标，所以最好的形式就是间接在生产环境去做最实在的性能测试。比方选在凌晨两三点钟没有什么业务流量的时候执行性能测试，看零碎能不能达到我的指标性能。
那想要真正做到在生产环境施行性能压测有哪些关键点呢？
次要有三点，测试流量辨认、测试流量标识的传递以及最重要的测试流量隔离。做生产环境压测防止不了波及一些写入申请，如果把大量虚伪的数据写入生产环境数据库必定不适合，后续还要去做数据清理。所以只有后面提到的三个关键点可能解决，在线性能测试就能实现。
这是咱们基于 JAVA 做的一套性能测试平台，因为咱们能够在 JAVA 有两头字节码这一层做加强，通过 agent 探针在不侵入用户业务代码状况上来做一些管制。正式流量放弃不变，咱们会对压测的流量做一些管制。举个例子，比如说零碎有一个 mysql 数据库，咱们就会在线上建一套影子数据库，跟原来数据库一样，只是数据可能少一点或是空的（只有表构造）。当有流量进来时 agent 就会进行辨认，辨认出压测流量时，agent 会把连贯的数据库替换成影子数据库。
无论是音讯队列还是 Cache 存储都能够用相似的形式来实现。
另外咱们还做了一个货色叫挡板，它是干嘛的呢？假如有个第三方的短信接口，业务流量去调用这个接口是能够的，但测试流量间接去调用必定是不行的，因为第三方不可能配合你做一个影子发短信的零碎。挡板的作用就是通过 agent 来实现一个 mock，在调用第三方接口时间接返回，避免测试流量调用第三方接口时对生产数据产生影响。
这是数列的生产环境全链路性能测试的计划，在此基础上咱们还研发了链路主动梳理的性能。对于简单业务以及简单零碎，它内含很多个微服务节点和业务节点，没有人能齐全搞清楚整个链路的所有的环节。咱们能够通过 agent 探针，利用技术手段搞清零碎链路流向，帮助进行链路梳理，与业务相结合就能梳理出业务调用的链路。联合 E2E 巡检平台不仅可能晓得这条链路的性能如何，还能定位到具体环节的具体性能瓶颈，不便及时精确地进行性能调优，梳理业务链路视图，最终实现零碎的高可用指标。
想要进一步进群交换或者对产品感兴趣想要申请试用，能够扫码增加【小树】企业微信，还会不定期分享干货内容哦～
数列科技成立于 2016 年，是国内当先的零碎高可用专家，由多名阿里巴巴资深专家发动成立。旨在以解决微服务架构治理及性能问题为外围，为企业零碎的性能和稳定性提供全方位保障，构建了笼罩全链路压测、E2E 巡检、故障演练等多模块的残缺产品矩阵，致力于帮忙企业将零碎可用性晋升至 99.99%。