微服务高效运维，从性能保障谈起
| 编辑推荐: |
| 文章主要从微服务核心价值：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数据自动汇聚到应用。
调用链跟踪：下钻获取应用调用链，定位到具体出错方法
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
