服务降级与服务熔断概述
服务熔断： 一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，熔断也可以称为过载保护
服务降级: 当服务压力剧增的时候根据当前的业务情况及流量对一些服务和页面有策略的降级，以此缓解服务器的压力，以保证核心任务的进行。同时保证部分甚至大部分任务客户能得到正确的响应。也就是当前的请求处理不了了或者出错了，给一个默认的返回。
服务降级举例
超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况
失败次数降级：主要是一些不稳定的api，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况
故障降级：比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）
限流降级： 比如当秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时我们会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）等等
服务熔断 VS 服务降级
两者其实从某些角度看是有一定的类似性的：
目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段
最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用
粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）
自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；
而两者的区别也是明显的：
触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑
管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
实现方式不太一样
服务降级要考虑的问题
- 核心和非核心服务
- 是否支持降级，降级策略
- 业务放通的场景，策略
Hystrix
具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包（request collapsing），以及监控和配置等功能
如何使用，请参考以前的博文
Spring Cloud【Finchley】-08使用Hystrix实现容错
Spring Cloud【Finchley】-09Feign使用Hystrix
Spring Cloud【Finchley】-10Hystrix监控
Spring Cloud【Finchley】-11Feign项目整合Hystrix监控
Spring Cloud【Finchley】-12使用Hystrix Dashboard实现Hystrix数据的可视化监控
数据库切库分库分表
数据库的瓶颈：
- 单个数据库数据量太大(1-2T)： 对应的策略—>拆分为多个库
- 单个数据库服务器压力太大，读写瓶颈：对应的策略—>拆分为多个库
- 单个表数据量过大：对应的策略—>分表
切库的基础：读写分离 ( 主库/从库)
自定义注解完成数据库切库：见以前的博文
Spring Boot2.x-09 基于Spring Boot 2.1.2 + Mybatis使用自定义注解实现数据库切换
Spring Boot2.x-10 基于Spring Boot 2.1.2 + Mybatis 2.0.0实现多数据源，支持事务
高可用的一些手段
任务调度系统分布式： elastic-job + zookeeper ， 请参考 elastic-job+zookeeper实现分布式定时任务调度的使用（springboot版本）
主备切换： apache curator + zookeeper 分布式锁实现 ，请参考 ZooKeeper + Curator 实现分布式锁
