性能分析优化的道与术

前言

之前有很多同学问我,性能测试中到底该如何去定位分析瓶颈并进行性能优化?感觉压测场景设计做的很全面,分析工具也用了很多,但一直无法快速的定位分析并进行优化。

性能分析和优化一直是技术领域热门的一个话题,无论是三高(高性能、高可用、高稳定),还是CAP(数据一致性、服务可用性、分区容错性),都强调了服务的性能和可用。

那么在工作中,该如何去测试并进行性能优化呢?这篇文章,我来谈谈我对于性能分析和优化的一些理解。

 

请求是如何被处理的?

“工欲善其事,必先利其器;欲利其器,必晓其理”。

在进行性能分析优化之前,先来看看一个请求处理的生命周期图。

如上图所示,是常见的一个微服务分布式架构下的请求处理过程。

我们经常谈的性能快和慢,实际上是一个相对的数值,它更多的是我们对于用户使用系统时访问速度体验的评估。

因此在进行性能定位分析之前,一定要清楚请求经过了哪些链路环节?它们的耗时分别是多少?是否是正常数值区间?如果数值异常,可能的原因是什么?

通过快速排除法,最终将性能分析和优化的点聚焦在一定范围内,这样才能快速的定位排查原因。

 

常见的性能问题与原因

看了上面的请求处理生命周期流程图,可以得到下面几点影响性能的因素。

网络带宽

网络对性能的影响不言而喻。

如果带宽不足,单位时间内的请求过多,就会导致数据包的传输延迟较大。

如果网络不稳定,也会导致RT的曲线抖动较为剧烈,产生毛刺甚至丢包,这个时候P90/P99的数值也可能变大。

因此稳定和足够的网络带宽,对系统的性能来说是很重要的。

负载均衡

现在的SLB层已经优化的足够好,但如果负载均衡出现问题,可能会导致流量分发不均匀,导致部分应用节点流量异常,健康检查不通过从而被踢下线。

甚至服务注册重试失败或者弹性扩容不够及时,还会导致可用的节点承受了较多的请求最终导致雪崩效应。

安全策略

现在的软件系统,常见的安全防护策略有ddos高防以及WAF,一般都是部署在SLB和流量网关之间或者更上层。

安全防护策略常见的场景有异常检测、输入验证、安全补丁、状态管理以及基于规则和异常的保护功能。

这些安全策略能够有效的保护系统不受到一些恶意的攻击和侵入,但这些策略生效也是需要耗费时间的。

流量网关

上面提到的几个部分都可以看做是互联网时代的基础通用层,而网关是伴随着微服务和容器化出现的,作为用户流量的系统入口,网关也承担了较多的功能,比如:

  • 日志
  • 身份鉴权
  • 灰度发布
  • 限流熔断
  • 可观测性metrics
  • 应用限流apm tracing

上述的功能,无论是身份鉴权还是可观测性的metrics的实现,都需要耗费一定时间。

特别是对于请求的RT比较敏感的业务,对流量网关功能的耗时要求更为严格。

相关文章基于Apache APISIX的全流量API网关统筹集群流量

Web应用层

近几年前后端分离的系统设计越来越多,web层更多的负责页面的渲染展示和部分讨好用户的交互设计。

如何让用户更快的感知到他所感兴趣的东西,这个时候CDN和缓存就派上用场了。

利用CDN和缓存的特性“就近加载”,让用户感知到的性能更快,也是性能优化领域很重要的一点。

APP应用层

前面讲了web层负责页面渲染展示和友好的交互,那App应用层(即我们常说的后端服务)则更多的负责逻辑计算。

逻辑计算是很吃资源的,当然和它的一些参数配置以及技术架构也有较大关联。

常见的影响后端服务性能的因素如下:

  • 硬件资源:如CPU/Memory;
  • 参数配置:如Activethreads/TimeOut;
  • 缓存配置:缓存中的大Key及缓存命中率;
  • 并行计算:请求下游依赖是串行还是并行?
  • 代码逻辑:最经典的例子——for循环无线套娃;
  • 日志处理:特别是异常日志的处理以及生产日志级别;
  • 处理机制:同步还是异步?如果是异步,MQ容量及消费能力如何?

推荐阅读认清性能问题

数据存储层

数据存储层我们通常理解为数据库。数据库层面影响性能的因素应该是最常见也是最多的。比如:

  • 锁:不合理的锁使用导致的请求等待;
  • 索引:未加索引或索引未生效导致慢SQL;
  • 数据量:表数据量过大导致的读写变慢等问题;

针对业务扩张以及数据量变大的问题,常见的优化策略有分表、数据库垂直拆分、读写分离等;

 

压测不是发现问题的唯一手段

回到性能定位分析和优化的话题上,关于性能优化,如下三点是必须铭记的。

性能优化的目标

在保持和降低系统99%RT的前提下,不断提高系统吞吐量,提高流量高峰时期的服务可用性。

性能优化的挑战

  1. 日益增长的用户量(带来访问量的提升,大数据量的存储和处理);
  2. 越来越多样的业务(业务的不断迭代和发展,会使其复杂性指数提升);
  3. 越来越复杂的系统(为了支撑业务迭代发展,系统架构会变得很复杂);

性能优化的路径

  1. 降低响应时间;
  2. 提高系统吞吐量;
  3. 提高服务可用性;

PS:三者关系在某些场景下互相矛盾冲突,不可兼得

性能优化的道法术器

基于上述关于性能优化的几点内容,结合我个人的实践经验和看法,性能定位和分析分为下面四个境界。

  • 道:熟悉业务逻辑,了解系统架构;
  • 法:掌握技术原理,熟知问题定位和分析优化的软件工程方法论;
  • 术:不断实践踩坑,总结归纳性能验证、定位分析的方法和经验;
  • 器:熟练使用性能测试、监控追踪、问题分析和优化的各种工具并擅加利用;

 

如何让系统运行的更快更稳定

时间空间

软件系统的三高(高性能、高可用、高稳定)要求,归根结底实际上需要在成本、收益、风险之间做取舍,我们很难做到用最低的成本达到最好的效果。

有个很早之前的优化理论,叫做“时间换空间,空间换时间”,讲的就是在响应时间和硬件资源消耗之间做平衡。性能优化的关键在于平衡各部分组件的性能平衡点,

如果CPU资源有空闲,但是内存使用紧张,便可以使用时间换空间的策略,达到整体的性能优化;反之CPU资源紧张,内存资源有空闲,则可以使用空间换时间的策略,提升整体性能。

分层优化

请求的处理过程要经过多个链路环节,除了优化耗时最长难度和成本较低的环节之外,在每个环节都进行一定优化,则对整体性能的提升有很大帮助。下面是流量高峰时的一些优化或者说应对案例:

数据库

  1. 扩容:DB是有状态服务,计算层便于扩容,将DB节点放到容器中,有需要扩容;
  2. 灾备:对于大流量读场景可通过流量切换方式,将部分流量迁移到备份集群分流;
  3. 巡检:慢SQL是常见的问题,可通过自动监控和历史数据分析,提供辅助式决策;

应用层(计算层)

  1. 限流:控制访问应用的流量在系统承载范围内
    1. 在业务请求入口(网关)限流,避免内部互相调用放大流量;
    2. 限流是个演进状态,从连接池、IP、指定SQL到更细的层级粒度做限流;
    3. 每个调用层都做限流,每个应用先保证自己可用,对其他依赖调用要做到“零信任”;
  1. 降级:强依赖通过熔断做紧急处理,弱依赖提前主动降级
    1. 主动降级:提前进行风险识别,然后针对性的降级,可降低已知的风险;
    2. 紧急降级:假设出现重大的问题,才需要决策是否启用的方案(风险较大);
    3. 预案平台:预案平台的目的是留痕,方便后续把限流降级等配置恢复回来;
  1. 熔断:熔断下游强依赖的服务
    1. 双十一零点的前半小时, 做一个动态推送,把日志关掉;
    2. 真正流量来的时候,留一台机器来观察错误和异常的日志;
  1. 隔离:核心和非核心业务做隔离

身份识别和业务隔离案例如下:

    1. RPC group分组:假设有100个节点,40个给核心业务(交易),60个给其他业务;
    2. 业务身份:中台架构可通过业务身份把订单秒杀等应用打上标记,便于隔离区分;

 

 3 total views,  1 views today

页面下部广告