微服务架构下，如何高效运维？

微服务架构下，如何高效运维？

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

1 微服务核心价值：3S

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

1）单服务变更性能影响如何评估？2）性能瓶颈在各微服务间漂移，如何做好性能测试？3）应对突发流量需求，扩容能否解决问题，如何扩容？4）服务实例数量众多，如何收集信息，快速定位性能问题？

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

1 什么是ServiceMesh

2 华为ServiceMesh整体架构

3 管理面服务治理能力

注册中心下发配置监控服务调用引擎

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

注册发现执行路由策略负载均衡透明TLS传输生成监控数据

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

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

三. 性能测试实施策略

1 关键度量指标

2 全链路调优测试策略

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）扩容和优化也是有限度的，在评估容量内，保障核心交易链路正常是重中之重，对于非核心功能模块考虑降级场景

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

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

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

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