三、服务降级与熔断
1.服务降级
1.1 概念
当服务器压力剧增时，根据业务情况及流量，对部分服务及页面有策略的降级，保证核心任务的正常运行
从系统功能优先级角度考虑
1.2 降级服务特征
（1）原因
整体符合超出整体负载承受能力
（2）目的
保证重要或者基本服务正常运行，非重要服务延迟使用或暂停使用
（3）大小
降低服务粒度，要考虑整体模块的粒度大小，将粒度控制在合适范围内
（4）可控性
- 在服务粒度大小的基础上增加服务的可控性
-
需要配置后台服务开关功能
单机可配置文件，其他可连数据库或缓存
- 可分为手动和自动控制
（5）次序
- 一般从外围延伸服务开始降级，重要性低的优先降级
- 需要配置降级等级等
1.3 服务降级分类
1.3.1 人工开关
针对秒杀、电商大促等
1.3.2 自动开关
针对限流、超时、失败次数、故障等
（1）限流
- 秒杀或抢购限购商品，限流来限制访问量，达到限流阈值则后续请求会被降级
-
降级处理方案
排队页面（将用户导流到排队页面等一会儿重试）
无货（直接告知用户没货了）
错误页（活动太火爆稍后重试）
（2）超时
配置好超时时间和超时重试次数及机制，并使用异步机制探测回复情况
（3）失败次数
一些不稳定的Api，失败次数达到一定阈值自动降级，使用异步机制探测回复情况
（4）故障
-
如调用的远程服务挂掉了
网络、DNS故障，HTTP服务返回错误状态码，RPC服务抛出异常
-
降级后处理方案：
默认值（如库存服务挂了返回默认现货）
兜底数据（如广告挂了，返回提前准备好的静态页面）
缓存（之前暂存的缓存数据）
1.4 大规模分布式系统降级
（1）搭建降级平台
手动降级开关、批量降级顺序、限流阈值动态设置、熔断阈值动态设置等
（2）降级准备
- 如大促前根据业务重要程度和业务关系批量降级
-
技术和产品提前对业务和系统梳理
确定哪些服务可以、不可以降级，降级策略、降级顺序
2.服务熔断
2.1 概述
是应对微服务雪崩效应的一种链路保护机制
类似股市、保险丝
- 当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断
- 服务熔断后不再有该节点的微服务调用，快速返回错误响应信息
- 检测该节点微服务调用响应正常后恢复调用链路
2.2 降级和熔断区别
- 降级目的在于应对系统自身的故障
- 熔断目的在于应对当前系统依赖的外部系统或者第三方系统的故障
2.3 熔断解决方案
SpringCloud官方推荐熔断组件:
（1）Sentinel
（2）Hystrix
（3）Resilience4J
（4）Spring Retry
详细如下链接：
Guideline: 从 Hystrix 迁移到 Sentinel
四、超时与重试
1.超时机制
1.1 概念
当一个请求超过指定时间还未被处理就直接被取消并抛出指定异常或错误
1.2 超时分类
1.2.1 连接超时（ConnectTimeout）
客户端与服务端建立连接的最长等待时间
1.2.2 读取超时（ReadTimeout）
建立连接后客户端等待服务端处理完请求的最长时间
备注： 一些连接池客户端框架中可能还有获取连接超时、空闲连接清理超时。
1.3 如何设置
通常读取超时设置为1500ms，可以根据服务对延迟敏感度增减，建议控制在1000 ~ 5000ms。
备注： 可将超时参数配置化，如放在配置中心，可参考美团的Java线程池参数动态配置。
2.重试机制
2.1 概念
多次发送相同的请求来避免瞬时故障和偶然性故障。
- 瞬时故障：某一瞬间系统偶然出现的故障，不会持久
- 偶然性故障：某些情况下偶尔出现的故障，频率较低
-
重试核心思想：
通过消耗服务器的资源来尽可能更大概率成功处理处理请求
2.2 次数设置
通常建议3次，并且设置重试的间隔。
2.3 重试幂等
2.3.1 超时与重试使用注意
注意保证同一个请求没有被多次执行
2.3.2 多次执行情况
客户端等待服务端完成请求超时但请求已经被执行了，只是由于短暂的网络波动导致响应在发送给客户端过程中延迟了。
如：用户购买课程支付请求由于重试导致用户购买了两次，所以执行用户购买课程请求时需要判断用户是否已经购买过。
五、性能测试
思维导图
1.不同角色看网站性能
1.1 用户
网站响应速度快慢
1.2 开发人员
速度：网站处理用户请求的速度
根据网站架构、基础设施：
- 项目架构是分布式吗？
- 用到了缓存和消息队列吗？
- 高并发业务特殊处理了吗？
- 数据库设计合理吗？
- 系统用到的算法还能优化吗
- 系统存在内存泄露吗？
- 项目使用Redis缓存多大？
- 服务器性能怎么样？
- 机器硬盘还是固态硬盘？
1.3 测试人员
根据性能测试工具测试报告：
- 响应时间
- 请求成功率
- 吞吐量
1.4 运维人员
根据基础设施和资源利用率：
- 服务器资源使用合理吗？
- 数据库资源使用合理吗？
2.性能测试注意点
2.1 了解系统的业务场景
测试前一定要了解系统业务场景
2.2 重视历史数据
通过历史数据判断调用最多、承受压力最大的接口
3.性能测试指标
3.1 响应时间
用户发出请求到用户收到系统处理请求后的结果所需要的时间
-
2-5-8原则
2-5秒页面体验会比较好，5-8秒还可以接受，超过8秒就很难接受了
但是导入导出大数据量、生成系统报告等除外
3.2 并发数
并发数是系统能同时处理请求的数目即同时提交请求的用户数目。
3.3 吞吐量
吞吐量是系统单位时间内系统处理的请求数量
重要参数：
（1）QPS（Query Per Second）
服务器每秒可以执行的查询次数
（2）TPS（Transaction Per Second）
服务器每秒处理的事务数
事务可理解为客户发出请求到收到服务器的过程
（3）并发数
并发数是系统能同时处理请求的数目即同时提交请求的用户数目
（4）响应时间
一般取多次请求的平均响应时间
-
QPS（TPS） = 并发数/平均响应时间
即：并发数 = QPS*平均响应时间
备注： 访问一个页面会请求服务器2次 — 2个QPS，一次访问 — 1个TPS
3.4 性能计数器
性能计数器是描述服务器或者操作系统的一些数据指标如内存使用、CPU使用、磁盘与网络I/O等情况。
4.常见的性能测试
4.1 性能测试
- 通过测试工具模拟用户请求系统，目的是为了测试系统的性能是否满足要求。
- 需再对系统性能有了解并且有明确的性能指标
4.2 负载测试
- 对被测试的系统继续加大请求压力，直到服务器的某个资源已经达到饱和了，。
- 简单理解就是测试系统上限
4.3 压力测试
不去管系统资源的使用情况，对系统继续加大请求压力，直到服务器崩溃无法再继续提供服务。
4.4 稳定性测试
模拟真实场景，给系统一定压力，看看业务是否能稳定运行。
5.常用性能测试工具
5.1 后端常用
-
Jmeter
JAVA 开发的性能测试工具
详见我另一篇文章：
项目部署测试之jemeter
-
LoadRunne
商业的性能测试工具
-
Galtling
一款基于Scala 开发的高性能服务器性能测试工具
-
ab
全称为 Apache Bench 。非常实用一款测试工具。
5.2 前端常用
-
Fiddler
抓包工具，它可以修改请求的数据，甚至可以修改服务器返回的数据，功能非常强大，是Web 调试的利器。
-
HttpWatch
可用于录制HTTP请求信息的工具
6.常见的性能优化策略
性能优化前需要对请求过程的各个环节分析，排查出可能出现性能瓶颈的地方，定位问题。
问题如下：
- 系统是否需要缓存？
- 系统架构本身是不是就有问题？
- 系统是否存在死锁的地方？
- 系统是否存在内存泄漏？
- 数据库索引使用是否合理？
上一篇跳转—高可用（一）
本篇文章主要参考链接如下：
参考链接1-JavaGuide
持续更新中…
随心所往，看见未来。Follow your heart，see light！
欢迎点赞、关注、留言，一起学习、交流！