需求背景

在流量较大的场景下，举个例子，用户在电商平台下单后开始跳转到在线收银台进行支付。由于支付渠道和网络环境随时都有可能发生问题，那么你该怎么保证支付系统的可靠性呢?

保证支付系统的可靠性需要考虑的点非常多，但这里有一个最直接和重点的内容就支付响应时长，如果支付时间过长，那么暴增的支付请求可能会把整个服务拖垮，最终导致所有服务瘫痪。

这时你可能会想到一个功能组件，超时熔断hystrix。这也是大多数支付系统中必用的组件，但怎么用呢，我们是在所有的接口上都加一个这样的功能组件吗?显然这样做是不合适的，一般类似这样的组件可能会嵌入到你的RPC接口或者自研的网关上，也可能是在整个服务治理层的功能编排上。总之，它不会轻易的暴漏给你，让你硬编码到业务逻辑实现中。

那么，本章我们就抽丝剥茧把组件包装使用的最核心实现方式展示给你。记住任何实现方案都是以当前系统环境最适合方式设计的，并不一定非得拘泥于某种形式。

方案设计

面对复杂的场景问题，市面上基本上都有应对的方案。。就像我们本章节所需要的调用超时要熔断保护系统，就有相应的技术组件hystrix，它是 Netflix公司开源的一款容错框架，在大部分RPC服务中也都有引入使用。

那如果我们只是想方便、简单并且不需要关心如何创建和返回结果的使用这样一个服务，就可以把hystrix的框架包装在中间里，屏蔽调用逻辑。整体的设计方案如图4-1超时熔断中间件框架设计。

大致思路如下：