共计 4359 个字符，预计需要花费 11 分钟才能阅读完成。
导读：近日，数列科技 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. 暴力破解式高频压测
除了双 11、618 这些大促节日之外，日常也可能会呈现性能问题，咱们要去找出问题并优化，这时就要用到咱们说的暴力破解式高频压测。这外面其实有一个十分重要的转变，全链路压测的同学须要从撑持方变成经营方。这两者的区别在于撑持方是你给我提需要我去做，而经营方是我给你定规范你去做，而后我来查看。
第一点须要去先去争取到高层 CTO 或者说架构组领导的一些反对，让大家违心去做这件事件，去成立一个性能经营的小组。第二点就是在初期推广的阶段，咱们要从一个撑持者变成一个倡导者，在公司外面推广这样的新技术，架构师肯定要多帮忙业务线的同学去帮他解决问题，去建设信赖。
在高频压测的时候，咱们肯定要想各种方法去升高研发同学的应用老本，比如说通过探针的形式，能够让开发同学他不必去改任何代码就能够做压测。
应用过程中会遇到很多的问题，咱们将这些些问题全副积淀到产品中开发了一系列工具去帮忙开发疾速上手实现工作。像压测报告外面内置了剖析的模块，能够明确的通知开发当初的性能与指标是否有差距。
这是我一开始给大家看的数据，还多加了 2 列数据——生产压测接入数量和生产压测次数。不难发现相比 2018 年，后两年有一个十分大的数量晋升，所以它能做到继续的生产环境性能零故障。
DevHa 高可用瞻望
在将来高可用相干的技术、产品肯定会蓬勃发展，以研发为核心去构建整个生态。日后在生产仿真技术上必定也会有很大的晋升，对于性能问题的解决形式也会由预先发现转变为事先被动发现故障并做出应答。日常会做相似暴力破解式高频压测这样的事件，去保证系统继续的强壮，去保障一个精确高频的反馈，好让研发的同学一直的去优化。
数列科技成立于 2016 年，是国内当先的零碎高可用专家，由多名阿里巴巴资深专家发动成立。旨在以解决微服务架构治理及性能问题为外围，为企业零碎的性能和稳定性提供全方位保障，构建了笼罩全链路压测、E2E 巡检、故障演练等多模块的残缺产品矩阵，致力于帮忙企业将零碎可用性晋升至 99.99%。
