高可用DevHa实践，告诉你生产环境0性能故障是如何作到的！

导读：近日，数列科技CTO陆学慧参加ArchSummit全球架构师峰会，并进行了题为《0性能故障是如何作到的：高可用性能领域的DevHA实践》的主题演讲，详细介绍了0性能故障的实践经验及对应解决方案，如下为演讲摘录。

在正式开始以前分享一个小故事 ：夏天来了，我前段时间在深圳发现已经有蚊子了，晚上睡觉灯一关，就听到身边有嗡嗡嗡的声音，想起来打死蚊子，但等我把灯打开，就找不到那个蚊子了。这种经历，你们应该都会有！

这跟我今天讲的性能瓶颈，它很是相似，咱们都知道系统里面必定有性能的瓶颈。但它具体在哪里，若是不画一个范围的话，很是难找到这个性能的瓶颈。找到以后去优化它，相信不少架构师同窗都是没有问题的，但这难就难在咱们找不到它。

从7次故障，到连续两年0故障

咱们能够先看一组性能实践数据！
这是咱们服务的一家客户从2018年到2020年的数据。在2018年的时候，它的生产环境性能故障有7次，影响时长超过500分钟。从2018年开始着手作生产环境的全链路压测，到2020年接入了全部的应用，一直在持续不断的进行这种全链路压测，保证在生产环境上没有了性能故障。接下来看看咱们是怎么作到的。

性能故障频发，核心问题在哪里？

这个客户2016年推出了一块新业务，增加比较快速，当时他面临的几个问题，第一个是系统老，第二个是它需求迭代特别快，第三就是新人比较多。

这个就是当时他们面临的一个现状。性能故障这么多，若是永远被动的去响应去解决，那可能永远都解决不完。因此咱们须要从这些复杂的现象里面抓住一些核心矛盾点，并持续地解决掉，才有可能把控整个的局面。

当咱们分析完整个的现状以后，就发现了他们最多见的故障缘由就是数据库，它数据库的性能故障占了一半以上。其中还发现了一个颇有意思的数据，可能你们日常都没怎么注意，就是数据库的硬件成本基本上会占整个除了大数据以外的其余硬件总和50%以上。但机器的数量并无那么多，因此数据库的计算资源是很是昂贵的，也是常常出问题地方。

第二个主要矛盾点，就是性能测试周期特别长，成本也很高。

当时这个公司它的性能团队有8我的，整个机器成本差很少是450万，3年均摊下来每一年差很少在150万的成本。早上顺丰科技架构委员会负责人刘潭仁有分享他们作压测的时候硬件成本差很少2000万左右，因此传统的性能测试，它成本是很高的。

另外，对于老板、CIO、CTO来讲，最关注最头疼的就是周期比较长，提一个性能需求排期排到两周以上，这就意味着只有提早规划好的大项目才能作性能压测。像平常迭代原本我只有一周的时间去开发，根本没有能力去作性能测试，致使生产环境的故障频发。

第三个主要矛盾的就是大促的这种性能的保障靠架构师团队的人拍脑壳。他缺少能够客观衡量生产环境我容量的手段，只能依靠经验判断难以找到性能瓶颈与优化方向。

3大核心问题，该如何解决？

跟大部分公司技术团队同样，内部相关人员作了不懈努力，架构师升级了分布式数据库，使得系统拥有超强计算力；业务端作了架构优化、系统重构，以此提升性能；针对核心链路资源提供独立保障……尽管你们作的很好，但是性能问题依旧存在。

咱们这边当时给出来的一个解决思路就是三步走：

第一步针对这种数据库的问题，咱们当时并无说把引入分布式的数据库做为一个核心原则，而是经过优化它的计算架构去给数据库减负，其实就跟给小学生减负同样，少布置点做业让他有更多的时间来处理好应该作的一件事情。

第二步就是作生产环境的全链路压测。

第三步你们可能以为很是更恐怖，就是暴力破解式高频压测。这主要就是为了持续的去保障线上没有性能问题，那咱们就必须保证一个高频的压测态势。就像咱们刚才说蚊子的这个问题，把这个门窗都关上，能够把我屋子里的蚊子都消灭掉，那一次性的没问题，可是，咱们平常生活中常常会开窗开门，你过几天发现蚊子又来了。 若是没有一个持续性灭蚊手段的话，是不可能作到屋子里没有蚊子的，在系统里面也是同样。

那下面咱们看看这三步咱们当时都是怎么走的？

1.优化计算架构进行数据库减负

其实最核心的就两步，第一步就是把TP类型的查询计算跟AP类型的作资源隔离。

经过各类各样的方式，能不用数据库的尽可能就不用，由于数据库的资源是很是宝贵。在作完这一步以后数据库的负载降了不少，性能问题也下来了不少。

那第二步呢， 就是咱们须要去作一个简单又可落地的SQL规范。这个SQL规范就是单SQL单表，作起来也很简单，可是从一个不遵循单SQL单表架构开始去作到这一步，它的阻力仍是很是大的。

我记得当时这个客户找上咱们，就是由于当时他们有一个系统上线上了一个礼拜都失败，缘由就是数据库资源竞争太厉害了。当时Oracl的专家提出上个XData花2000万问题就解决了。

这个客户经过朋友找到了咱们，咱们了解的状况以后就提出，咱们有办法能够帮你持续的解决这个问题，不须要花费2000万。咱们当时给出来的方案就是把他们那些几百行的这种SQL全都拆掉，历时一个多月，系统成功上线且数据库的资源还有不少的剩余。经过这个动做，咱们顺利帮客户省下了大约2000万。

咱们作完这两步以后，不少的性能问题已经被抑制下来了。

2.生产环境全链路压测

客户公司CTO当时提出了一个问题，今年的双11系统还会不会挂？若是只是作一些数据库层面架构优化，其实很难回答这个问题。因而咱们给出了在生产环境作全链路压测的第二步方案。好多人第一次听到这个概念的时候内心会很是的不安——在生产环境万一挂了怎么办？因此今天我会着重讲一下安全问题。

其实生产全链路压测的核心逻辑特别简单。

首先就是压测的流量要可识别，在任何一个节点均可识别，在任何处理的逻辑里面，我都要能知道如今我处理的，究竟是一个压测流量仍是一个生产流量。

第二点就是压测的这个标签，它要在微服务架构里面不停的传递下去，不能说传着传着断了，这时候也会出问题。

第三点很重要，就是压测的数据要能够隔离。不能把压测产生的任何的数据跟业务产生的的数据混到一块儿。

咱们要作压测流量可识别其实比较简单，以http流量为例，咱们只须要在http的head里面增长key value就能够有效识别了。可是它难在怎么在整个微服务的架构里面传下去，作到标签传递这一点是有一些技术难度的。须要技术人员对公司所使用的全部中间件很是了解，而且没有一个适用于全部中间件的一招鲜的方法，是须要根据不一样中间件去定制传递方案的。

最后说说这种数据怎么去作隔离，我这边列举了一些，不是很全。

好比消息系统能够经过Topic进行隔离、搜索能够经过索引进行隔离、数据库能够经过库/表进行隔离。原理是比较简单的，复杂与困难主要体如今一些技术细节上。

像咱们在作时候消息隔离时也出现过问题，这是一套消息系统rocket MQ的数据隔离流程，分为消息的生产者、消费者以及服务器三大块。经过Topic对正式和压测的消息数据进行隔离，将压测数据放进影子Topic里，方案思路很简单，后期对于压测数据清理也好，维护也好，都很是简单。但在试跑验证时咱们发现有条压测数据跑到线上去了，咱们也以为很奇怪，按方案来讲是不会出现这种状况的。

后来经过排查发现那条数据造的有问题致使订阅者在消费时失败了，在RocketMQ里消费失败三次就会被放进重试队列里。在这以前咱们没有考虑到这块，只作了业务消息的影子Topic，因此这条数据在接收回来以后就被认定为正常的业务消息，跑到线上去了。为此咱们增长了重试队列的影子Topic，问题顺利解决。

讲这个细节就是为了说明数据隔离以及数据标签传递当中都有许多技术细节，是须要技术人员对公司全部的中间件的细节都很是了解，否则就容易出现问题。

为了保障系统的安全与稳定，除了刚才说的在技术设计上的这种安全保障，整个全链路压测前中后针对不一样的点，咱们都有作不少的安全校验。

我这边就挑几个例子给你们分享一下。好比说有一个叫作白名单的功能，它是干吗的呢？假设当咱们在作全链路压测上线的时候，个人一条链路是 a 调b 调c 调 d，但因为资源协调问题abcd并不能所有同时上线，只能a和b先上线，这时候就会出现问题，a和b能够识别压测流量，但c和d识别不了，那这部分流量就会成为真实流量跑到线上去，白名单就是用来处理这种状况的。咱们会把全部支持压测的服务列表所有收集回来，再经过一个聚合的服务把它变成一些白名单的列表的配置，而后再分发下去，防止b的压测流量进入c。

除此以外咱们还能够提供监测的服务，E2E巡检平台能够针对不一样的场景设置RT值、错误率值等，一旦达到限定值就会自动中止压测，作到一边压测一边巡检，出现问题就当即中止。

那经过这些手段，你们就能够放心地在生产环境作这种全链路压测，也能够勇敢地回答前面CTO的问题——今年双11不会挂！

3. 暴力破解式高频压测

除了双十一、618这些大促节日以外，平常也可能会出现性能问题，咱们要去找出问题并优化，这时就要用到咱们说的暴力破解式高频压测。这里面其实有一个很是重要的转变，全链路压测的同窗须要从支撑方变成运营方。这二者的区别在于支撑方是你给我提需求我去作，而运营方是我给你定标准你去作，而后我来检查。

第一点须要去先去争取到高层CTO或者说架构组领导的一些支持，让你们愿意去作这件事情，去成立一个性能运营的小组。第二点就是在初期推广的阶段，咱们要从一个支撑者变成一个倡导者，在公司里面推广这样的新技术，架构师必定要多帮助业务线的同窗去帮他处理问题，去创建信任。

在高频压测的时候，咱们必定要想各类办法去下降研发同窗的使用成本，好比说经过探针的方式，可让开发同窗他不用去改任何代码就能够作压测。

使用过程当中会遇到不少的问题，咱们将这些些问题所有沉淀到产品中开发了一系列工具去帮助开发快速上手完成工做。像压测报告里面内置了分析的模块，能够明确的告诉开发如今的性能与目标是否有差距。

这是我一开始给你们看的数据，还多加了2列数据——生产压测接入数量和生产压测次数。不难发现相比2018年，后两年有一个很是大的数量提高，因此它能作到持续的生产环境性能零故障。

DevHa高可用展望

在将来高可用相关的技术、产品必定会蓬勃发展，以研发为中心去构建整个生态。往后在生产仿真技术上确定也会有很大的提高，对于性能问题的处理方式也会由过后发现转变为事前主动发现故障并作出应对。平常会作相似暴力破解式高频压测这样的事情，去保证系统持续的健壮，去保证一个准确高频的反馈，好让研发的同窗不断的去优化。

数列科技成立于2016年，是国内领先的系统高可用专家，由多名阿里巴巴资深专家发起成立。旨在以解决微服务架构治理及性能问题为核心，为企业系统的性能和稳定性提供全方位保障，构建了覆盖全链路压测、E2E巡检、故障演练等多模块的完整产品矩阵，致力于帮助企业将系统可用性提高至99.99%。