高可用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 值、错误率值等，一旦达到限定值就会自动停止压测，做到一边压测一边巡检，出现问题就立即停止。
E2E巡检平台截图
那通过这些手段，大家就可以放心地在生产环境做这种全链路压测，也可以勇敢地回答前面 CTO 的问题——今年双 11 不会挂！
3.暴力破解式高频压测
除了双 11、618 这些大促节日之外，日常也可能会出现性能问题，我们要去找出问题并优化，这时就要用到我们说的暴力破解式高频压测。这里面其实有一个非常重要的转变，全链路压测的同学需要从支撑方变成运营方。这两者的区别在于支撑方是你给我提需求我去做，而运营方是我给你定标准你去做，然后我来检查。
第一点需要去先去争取到高层 CTO 或者说架构组领导的一些支持，让大家愿意去做这件事情，去成立一个性能运营的小组。第二点就是在初期推广的阶段，我们要从一个支撑者变成一个倡导者，在公司里面推广这样的新技术，架构师一定要多帮助业务线的同学去帮他处理问题，去建立信任。
在高频压测的时候，我们一定要想各种办法去降低研发同学的使用成本，比如说通过探针的方式，可以让开发同学他不用去改任何代码就可以做压测。
ForceCop 产品页面截图
使用过程中会遇到很多的问题，我们将这些些问题全部沉淀到产品中开发了一系列工具去帮助开发快速上手完成工作。像压测报告里面内置了分析的模块，可以明确的告诉开发现在的性能与目标是否有差距。
这是我一开始给大家看的数据，还多加了 2 列数据——生产压测接入数量和生产压测次数。不难发现相比 2018 年，后两年有一个非常大的数量提升，所以它能做到持续的生产环境性能零故障。
DevHa 高可用展望
在未来高可用相关的技术、产品一定会蓬勃发展，以研发为中心去构建整个生态。日后在生产仿真技术上肯定也会有很大的提升，对于性能问题的处理方式也会由事后发现转变为事前主动发现故障并做出应对。日常会做类似暴力破解式高频压测这样的事情，去保证系统持续的健壮，去保证一个准确高频的反馈，好让研发的同学不断的去优化。
数列科技成立于 2016 年，是国内领先的系统高可用专家，由多名阿里巴巴资深专家发起成立。旨在以解决微服务架构治理及性能问题为核心，为企业系统的性能和稳定性提供全方位保障，构建了覆盖全链路压测、E2E 巡检、故障演练等多模块的完整产品矩阵，致力于帮助企业将系统可用性提升至 99.99%。