昨天讲了一下服务流量控制的可行性方案，这只讲了应对大流量解决方案的上半部分，今天将讲一下下半部分，如何来执行服务降级和动态扩展。并且在实际工作中，我们是将流量控制和服务降级混合使用的，所以今天的话题会建立在昨天的讨论之上。
什么是服务降级
服务降级是在服务器压力陡增的情况下，利用有限资源，根据当前业务情况，关闭某些服务接口或者页面，以此释放服务器资源以保证核心任务的正常运行。
流量控制本质上是减小访问量，而服务处理能力不变；而服务降级本质上是降低了部分服务的处理能力，增强另一部分服务处理能力，而访问量不变。
服务降级方式
服务降级在操作上，是前后端联动，相互配合来做到的，意味着，在代码设计阶段，前后端必须要共同考虑服务降级的方案。根据事态的严重性，会制定不能级别的降级方案：
1. 按比例执行API：预先设定一定的比例，将这部分流量带来的API请求，不做处理，直接返回默认值，其余请求能继续正常返回。
2. 关闭非核心服务API：前端页面能继续访问，但是将与核心功能无关的API关闭掉，保证主流程能继续执行，前端隐藏对应的信息展示。
3. 延迟返回，结果转异步返回：页面能正常访问，但是涉及到记录变更，会提示稍晚更新结果，将数据记录更新的返回转到异步MQ。
4. 将前端页面切到静态页：通过Nginx设置，将页面跳转到一个静态页面。例如“目前系统正在维护，blabla”这样的页面。
为了执行以上4点操作，需要预先做好埋点操作，例如 通过NGINX+LUA脚本来动态触发页面跳转，或者在DB层阻断一切写操作，只允许读操作等等。对于服务层，由于是微服务的架构，为了避免重复造轮子，毕竟不是在大厂，没有那么多人力资源来自行开发中间件，所以考虑采用第三方的服务降级组件来执行，在这里，我将简单介绍一下Netflix Hystrix。
利用Hystrix来做服务降级
提到Netflix，对看美剧的朋友，可以说是大名鼎鼎，现在最热的《纸牌屋》就来自于Netflix, 我们这里说的Hystrix ，也是 Netflix 开源的组件(请大家自行在GitHub中搜索)。 Hystrix能够帮助服务之间调用超时，出错时，阻止问题进一步扩散，避免服务崩溃。在用户无感知的情况下对服务进行降级处理。
举个栗子：当系统试图为访问我们App的用户进行可以购买的定期产品推荐时，前端向后端发送了获取推荐列表的请求，但由于某种原因服务调用一直没有返回，Hystrix 可以根据预先定义的多种策略来判断服务是否健康。例如：通过Hystrix 为服务预设一个 timeout超时时间，如果调用该服务的返回结果超过这个时间，Hystrix 会自动触发熔断机制，放弃对该服务的调用，并返回一个预设的产品列表返回到前端，避免了大量请求持续等待，消耗光连接池，导致服务堵塞，乃至引起整体功能不可用。
（本插图来源于Hystrix Github Wiki）
Hystrix 内部建立了一套Circuit Break 的机制，可以实时检查各个微服务工作状态。当某个服务的请求量过大时，导致大量请求失败，Circuit Break 会对线程进行隔离，或者对资源访问做限制，确保服务能正常服务。
Circuit Break 的决策流程如下：
（插图来源于Hystrix Github Wiki）
简单来说，我们可以根据预先设定一个服务调用能容忍的失败率（error percentage）。如果请求该服务API的失败率大于这个阈值，Circuit-breaker 的状态会变成 OPEN状态。这个时候，所有访问该服务的请求会被直接拒绝访问。一段时间后，会让一些Single Request 恢复访问（Half-Open），如果该服务调用仍然失败，Circuit-breaker 会再次进入 OPEN 状态，如果请求成功，Circuit-breaker 状态变为 CLOSED。
由于我们是采用的是Dubbo来作为微服务的框架，Hystrix能轻松和Dubbo整合，所以使用起来还是很顺畅。
如何做动态扩展
正如前文所说，光依赖服务降级是不够的，服务还需要预备动态扩展的能力，才能真正保证我们的业务持续运行。动态扩展指的是在流量超过系统服务能力时，能支持服务集群的横向扩展，通过自动和手动的方式部署并上线运行；当流量过去后又回收多余机器，做到如插头一样，插拔自如，完全弹性。
由于我们现在是用的第三方的云服务，总体来说，动态扩展还是比较方便的。具体做法目前看是比较原始的，提前准备好机器，由于服务base在Dubbo上，采用分布式缓存，服务启动后即可接入。找一个夜神人静的时候，将多余的服务下掉即可。随着系统微服务化不断深入下去，关于动态扩展这块，会有一些自动化和智能化的方案做出来。
扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes
欢迎转载，带上以下二维码即可
