1.1-为何使用Sentinel

在我们日常生活中，经常会在淘宝、天猫、京东、拼多多等平台上参与商品的秒杀、抢购以及一些优惠活动，也会在节假日使用12306 手机APP抢火车票、高铁票，甚至有时候还要帮助同事、朋友为他们家小孩拉投票、刷票，这些场景都无一例外的会引起服务器流量的暴涨，导致网页无法显示、APP反应慢、功能无法正常运转，甚至会引起整个网站的崩溃。

Sentinel为了解决上述这些问题，由此应运而生。它通过为秒杀、抢购、抢票、拉票等功能提供API接口层面的流量限制，让突然暴涨而来的用户访问受到统一的管控，使用合理的流量放行规则使得用户都能正常得到服务。

另外，在微服务项目中，经常存在服务A调用服务B，服务B又调用服务C等微服务级联调用的场景，当服务C出现故障，服务B和服务A都会跟着出现故障，因为它们之间存在调用链关系；有时候调用链会很长并且很复杂，比如服务A不仅调用了服务B，还调用了服务H、服务I、服务J等等，同时服务A调用链的最长链条终端有可能是从服务C、服务D一直到服务Z，这种调用复杂的调用链条一旦出现故障，有可能直接让整个微服务体系都无法提供服务，造成的影响是致命的。

调用链架构示意图如下所示：

 

这种由于调用链中某一个节点出现故障而引发的级联故障，称为应用雪崩，也称为级联故障、级联失效（Cascading Failure）。

Sentinel的出现，正好可以解决这种雪崩效应引发的一系列问题。