RPC远程调用过程中如何防止服务雪崩效用
微服务中如何保护服务
Hystrix是一个微服务中关于服务保护框架，在分布式中能够实现对服务容错。出错之后的预备方案
背景
在今天，基于SOA的架构已经大行其道。伴随着架构的SOA化，相关联的服务熔断、降级、限流等思想，也在各种技术讲座中频繁出现。本文将结合Netflix开源的Hystrix框架，对这些思想做一个梳理。
伴随着业务复杂性的提高，系统的不断拆分，一个面向用户端的API，其内部的RPC调用层层嵌套，调用链条可能会非常长。这会造成以下几个问题：
API接口可用性降低
引用Hystrix官方的一个例子，假设tomcat对外提供的一个application，其内部依赖了30个服务，每个服务的可用性都很高，为99.99%。那整个applicatiion的可用性就是：99.99%的30次方 ＝ 99.7%，即0.3%的失败率。
这也就意味着，每1亿个请求，有30万个失败；按时间来算，就是每个月的故障时间超过2小时。
服务熔断
为了解决上述问题，服务熔断的思想被提出来。类似现实世界中的“保险丝“，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时。
熔断的触发条件可以依据不同的场景有所不同，比如统计一个时间窗口内失败的调用次数。
服务降级
有了熔断，就得有降级。所谓降级，就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。
这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景。
关于Hystrix中fallback的使用，此处不详述，参见官网。
项目搭建
需求：搭建一套分布式rpc远程通讯案例：比如订单服务调用会员服务实现服务隔离，防止雪崩效应案例
Hystrix针对微服务保护框架，涉及到服务之间的rpc演出调用。订单与会员实现rpc调用
微服务汇总 rpc远程调用使用http通讯
采用restful 底层可以使用httpclient实现rpc远程通讯
订单服务 通过http协议 调用 会员服务 （基于请求响应的，需要等待他的响应）
Hystrix 是一个微服务关于服务保护的框架，是Netflix开源的一款针对分布式系统的延迟和容错解决框架，目的是用来隔离分布式服务故障。它提供线程和信号量隔离，以减少不同服务之间资源竞争带来的相互影响；提供优雅降级机制；提供熔断机制使得服务可以快速失败，而不是一直阻塞等待服务响应，并能从中快速恢复。Hystrix通过这些机制来阻止级联失败并保证系统弹性、可用。