上期说到一个问题：
当某个系统(如财务ERP系统负担)过重的时候，我们期望优先保障某些关键业务(如销售管理系统SMS，明天要投标，去ERP申请价格)。
在没有API网关的时候，SMS的应用层，本身是没有办法区分哪些请求来自关键业务，哪些请求来自非关键业务的，除非在程序代码中做修改——
这又增加了大量的开发验证工作量，并且每次变更都需要重新修改验证。程序媛们的发际线又面临着新的危机——
幸好，我们在企业IT系统中引入了API网关，可以将这种限流工作交给API网关来实现，运维同学们只需要在API网关上设置好限流策略，就可以保证关键业务的可用性(Availability)。
如上图所示，finance业务的性能只能扛住1000QPS。而关键业务请求一般不超过400QPS，非关键业务请求的压力有可能到2000QPS以上。为了防止非关键业务请求把finance业务打死，运维同学们可以对非关键业务请求做限流，让这些请求的性能限制到500QPS，给关键业务留下1000-500=500QPS的性能，防止着急投标的时候无法完成申请价格和测算利润等关键动作。
限流功能可以对业务系统提供基本的QoS保障，但功能过于刚性，只要超出了限流的QPS数，就会有一部分用户看到的是http 500或http 502页面。如果某个业务的关键性没有那么强，有没有办法让系统动态调整业务承载能力，实现容纳更多用户呢？
答案是肯定的。API网关可以检查对后端的业务请求是否成功。如果后端出现http 5xx这样的错误信息，说明后端业务忙不过来了，API网关会让它休养生息一会儿——这叫做熔断。
如图，假设运维同学在API网关上设定的熔断策略为：
当HTTP 5xx响应超过5%时，对业务进行熔断，3秒钟后恢复。
在某个时刻，有较大的突发访问请求被finance业务的apached前端接收，但后端的tomcat负担过重，无法及时响应来自apached前端的请求。使得apached向API网关返回HTTP 5xx错误。API网关发现，来自finance业务的HTTP 5xx错误率上升到熔断阈值5%，执行熔断策略，对于所有指向finance业务的请求暂时返回HTTP 5xx，从而保护finance的tomcat后端不被彻底打死，得以休养生息。3秒钟的熔断时间过后，finance业务又可以重新营业了。
显然，熔断机制对业务的保护效果是显而易见的。但是，熔断本身是一种简单粗暴的保护，在业务熔断期间，所有用户见到的是这个业务不可用(如HTTP 5xx错误)。有没有颗粒度更细的保护方式呢？
答案是肯定的。
让我们穿越回童年的记忆：电视机偶尔能收到邻居家小霸王学(you)习(xi)机发射的无线信号，但由于房屋结构的遮挡和衰减，画面往往是黑白的……
方老师的青春回来了！
这实际上就是PAL彩色制式的一种服务降级机制：在信噪比恶劣的情况下，牺牲颜色来保障画质的还原。
那么，我们如果引入这种服务降级机制，也可以通过牺牲业务质量，在业务峰值期间让更多用户能够使用基本服务，而不是面对着HTTP 5xx的错误页面不知所措。
开发APP的同学可以利用API网关的性能监控功能，在APP中实现服务降级。API网关本身也可以提供服务降级策略，如直接返回固定数据，或将返回的视频降级为图片等。
当然，实际上API网关不仅限于提供限流、熔断、降级、性能监控、性能告警等QoS相关的功能，还可以提供统一的鉴权功能，保护信息的机密性(Confidentiality)和完整性(Integrity)，而不需要每个业务自己去重新实现一遍这些控制逻辑。
那么，微服务与API网关的关系是什么样的呢？请看下集。
