微服务高效运维,从性能保障谈起

编辑推荐:

文章主要从微服务核心价值:3S,带来的运维的挑战,服务性能保障解决方案设计以及性能测试实施策略等等。

本文来源testwo.com,由火龙果Anna编辑推荐。

一. 微服务架构面临的挑战

1 微服务核心价值:3S

微服务高效运维,从性能保障谈起

2 微服务架构带来的运维挑战

1. 单服务流量激增时扩容

2. 调用链条变长,调用关系更加复杂

3. 微服务拆分导致故障点增多

微服务高效运维,从性能保障谈起

1. 单服务变更性能影响如何评估?

2. 性能瓶颈在各微服务间漂移,如何做好性能测试?

3. 应对突发流量需求,扩容能否解决问题,如何扩容?

4. 服务实例数量众多,如何收集信息,快速定位性能问题

二. 华为云微服务性能保障解决方案设计

华为云微服务性能保障解决方案介绍

微服务高效运维,从性能保障谈起

1 什么是ServiceMesh

一种基础设施层,服务间通信通过Service mesh转发

一种TCP/IP之上的网络模型

一个轻量的网络代理,与业务部署在一起

可靠的传输复杂网络拓扑中的服务请求,将服务变为现代的云原生服务

微服务高效运维,从性能保障谈起

2 华为ServiceMesh整体架构

微服务高效运维,从性能保障谈起

3 管理面服务治理能力

微服务高效运维,从性能保障谈起

可人工介入,未运行时的mesher和侵入式框架提供配置下发

注册中心

下发配置

监控服务

调用引擎

4 数据面支持侵入式与非侵入式Mesher

微服务高效运维,从性能保障谈起

即侵入式框架与非侵入式mesher

注册发现

执行路由策略

负载均衡

透明TLS传输

生成监控数据

5 微服务架构的关键性能瓶颈点

1. Mesher的性能损耗(1ms)

2. 单服务的接口性能

3. 全链路调用性能

4. 服务伸缩能力

微服务高效运维,从性能保障谈起

6 关于性能我们需要做哪些

微服务高效运维,从性能保障谈起

6.1 开展分层验证,掌握服务的能力基线

1 单服务接口测试

验证单服务的各个接口能力基线以及组合接口的能力基线

2. 全链路测试

验证全链路场景以及多链路组合场景的性能,优化链路中性能不足的服务

3. 伸缩能力验证

验证单服务的水平扩容能力,验证既定模型下的多链路组合场景的资源模型

6.2 性能测试服务化,提升验证效率

微服务高效运维,从性能保障谈起

关键设计1:模块化管理,事务灵活组合与复用

抽象性能测试所需的元素并模块化,实现灵活复用和配置修改

微服务高效运维,从性能保障谈起

关键设计2:可扩展的高性能执行集群

微服务高效运维,从性能保障谈起

三. 性能测试实施策略

1 关键度量指标

制定测试目标,要求测试指标结果达到用户预期目标。

指标数据一般包括并发用户数、Response Time、TPS、通过率等。

系统的吞吐量要和响应时间关联(SLA),如至少90%以上的请求在正常合理响应时间内。

微服务高效运维,从性能保障谈起

2 全链路调优测试策略

性能是一个逐步提升的过程,测试过程中需要找到扩容的模型,从不足50的TPS提升至万级

微服务高效运维,从性能保障谈起

3 测试报告分析解读

如何从测试工具侧快速分析被测对象可能存在的问题

存在部分响应超时:

a) 服务器繁忙,如某个服务节点CPU利用率高

b) 网络IO超过VM/EIP带宽

c) 等待后端微服务、数据库的超时时间设置过长

运行一段时间后全部响应超时或者检查点校验不通过:

a) 大压力导致系统中某个微服务奔溃

b) 后端数据库无响应

TPS未随着并发数增长而上升:

a) 系统性能到达瓶颈,持续并发加压过程中响应时延增加(可观察响应区间统计

b) 可通过进一步加压是否会出现非正常响应验证

TP90响应时延较短,TP99时延高:

a) 系统性能接近瓶颈

b) 可通过进一步加压是否会出现非正常响应验证

微服务高效运维,从性能保障谈起

微服务高效运维,从性能保障谈起

微服务高效运维,从性能保障谈起

4 一些常见的性能优化手段

1. 扩容,链路中的某一应用可能出现cpu使用率较高或者连接池资源不够用(rpc、jdbc、redis连接池等)但本身对于拿到连接的请求处理又很快,这一类需要横向扩展资源。

2. 应用逻辑优化,比如存在慢sql、 逻辑的不合理如调用db或者redis次数过多、没有做读写分离造成写库压力过大。

3. 超时时间的合理设置,对于应用之间的rpc调用或者应用与其他基础组件之间的调用,均需要设置合理的超时时间,否则过长的等待将造成整个链路的故障。

4. 缓存的应用,请求尽可能从前端返回,而不是每一个都要让后端应用处理后再返回,减轻后端应用及数据库压力,提高系统吞吐能力。

5. 限流,对于超出承载能力的QPS或并发,可以进行拦截并直接返回提示页面。

6. 降级,对于非核心链路上的应用,允许故障关闭而不影响核心链路

7. 扩容和优化也是有限度的,在评估容量内,保障核心交易链路正常是重中之重,对于非核心功能模块考虑降级场景

5 面对复杂网络架构如何做性能测试

一个典型的互联网平台:突发事件高流量突发,如瞬间由百级用户增长到万级

微服务高效运维,从性能保障谈起

对于网络架构复杂的应用,可以拆分压力的入口点,进行分段验证,屏蔽对应网元带来的性能影响,如分别从最外端的CDN入口(1)、中间的ELB(2)、业务层(3)分别做测试,验证复杂网络架构情况下,各网元的瓶颈和影响

6 应用内部的性能瓶颈如何提升定位效率?

6.1 资源、应用、业务一站式监控与分析

立体运维全景图

微服务高效运维,从性能保障谈起

6.2 应用拓扑与异常展示、故障下钻

应用发现与依赖关系:非侵入采集应用KPI数据,并通过服务间接口自动生成依赖关系,展现应用拓扑。

应用KPI汇聚:微服务实例汇聚到应用(数字表示XX个实例),KPI数据自动汇聚到应用。

调用链跟踪:下钻获取应用调用链,定位到具体出错方法

微服务高效运维,从性能保障谈起

原文 

http://www.uml.org.cn/itil/202001172.asp?artid=22887

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 微服务高效运维,从性能保障谈起

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址