} catch (InterruptedException e) {
e.printStackTrace();
}
return this.userService.queryUserById(id);
}运行查看结果：
服务熔断
熔断原理：熔断器(断路器)，当某些服务反应慢或者存在大量超时问题时，服务调用方可以自己进行判断，并进行熔断，防止整个系统被拖垮。当情况好转时，在进行自动重连。
通过断路器的方式，可以将后续请求直接拒绝掉，一段时间之后允许部分请求通过，如果调用成功则回到电路闭合状态，否则继续断开。
熔断状态机3个状态：
- Closed：关闭状态，所有请求都正常访问。
- Open：打开状态，所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
- Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进行休眠计时
在程序中测试：
在consumer的调用业务中加入一段逻辑：
@GetMapping
@HystrixCommand(fallbackMethod = “queryUserByIdFallback”) //声明熔断的方法
public String queryUserById(@RequestParam(“id”) Long id) {
if(id==1){
throw new RuntimeException();
}
return this.restTemplate.getForObject(“http://service-provider/user/” + id, String.class);
}这样如果参数是id为1，一定失败，其它情况都成功。（不要忘了清空service-provider中的休眠逻辑）
当我们连续访问id为1的请求时（超过20次，手速要快），就会触发熔断。断路器会断开，一切请求都会被降级处理。此时你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有几毫秒左右：
第一次访问id=2：
连续访问id=1：
再次访问id=2：
不过，默认的熔断触发要求较高，休眠时间窗较短，为了测试方便，我们可以通过配置修改熔断策略：
circuitBreaker:
requestVolumeThreshold: 10 #触发熔断的最小请求次数，默认20
sleepWindowInMilliseconds: 10000 #触发熔断的失败请求最小占比，默认50%
errorThresholdPercentage: 50 #休眠时长，默认是5000毫秒
声明式服务调用Feign
=========================================================================
Feign是Netfix开发的声明式、模板化的HTTP客户端，它可帮助我们更加快捷的调用HTTP API，其中支持自带的注解，JAX-Rs注解，SpringMVC注解，并且还整合了Ribbon与Eureka。通过使用Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做，十分方便。
Feign项目地址：https://github.com/OpenFeign/feign
在前面的学习中，我们使用了Ribbon的负载均衡功能，大大简化了远程调用时的代码：
String user = this.restTemplate.getForObject(“http://service-provider/user/” + id, String.class);
快速入门:
改造springboot-service-consumer工程：
导入依赖：
org.springframework.cloud
spring-cloud-starter-openfeign
开启Feign功能：在启动类上，添加注解，@EnableFeignClients开启Feign功能
@SpringCloudApplication //组合注解，相当于@SpringBootApplication + @EnableDiscoveryClient + @EnableCircuitBreaker
@EnableFeignClients //启用feign组件
public class SpringbootServiceConsumerApplication {
/*@Bean
@LoadBalanced //开启负载均衡
public RestTemplate restTemplate() {
return new RestTemplate();
}*/
public static void main(String[] args) {
SpringApplication.run(SpringbootServiceConsumerApplication.class, args);
}
}删除RestTemplate：feign已经自动集成了Ribbon负载均衡的RestTemplate。所以，此处不需要再注册RestTemplate。
配置Feign的客户端：
在springboot-service-consumer工程中，添加UserClient接口：
//@FeignClient(value = “service-provider”) // 标注该类是一个feign接口
@FeignClient(value = “service-provider”,fallback = UserClientFallBack.class)
public interface UserClient {
@GetMapping(“user/{id}”)
User queryById(@PathVariable(“id”) Long id);
}- 首先这是一个接口，Feign会通过动态代理，帮我们生成实现类。这点跟mybatis的mapper很像
@FeignClient，声明这是一个Feign客户端，类似@Mapper注解。同时通过value属性指定服务名称- 接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果
改造原来的调用逻辑，调用UserClient接口：
@RestController
@RequestMapping(“consumer/user”)
public class UserController {
@Autowired
private UserClient userClient;
@GetMapping
public String queryUserById(@RequestParam(“id”) Long id){
User user = this.userClient.queryUserById(id);
return user.toString();
}
}启动测试：
访问接口：
正常获取到了结果。
负载均衡与Hystrix支持：
Feign中本身已经集成了Ribbon依赖和自动配置，因此我们不需要额外引入依赖，也不需要再注册RestTemplate对象。
同时Feign默认也有对Hystrix的集成，只不过，默认情况下是关闭的。我们需要通过下面的参数来开启：(在springboot-service-consumer工程添加配置内容)：
feign:
hystrix:
enabled: true # 开启Feign的熔断功能
但是，Feign中的Fallback配置不像hystrix中那样简单了。首先，我们要定义一个类UserClientFallback，实现刚才编写的UserClient，作为fallback的处理类
@Component
public class UserClientFallBack implements UserClient {
@Override
public User queryUserById(Long id) {
User user = new User();
user.setUsername(“服务器正忙，请稍后再试！！！”);
return user;
}
}然后在UserFeignClient中，指定刚才编写的实现类
@FeignClient(value = “service-provider”, fallback = UserClientFallback.class) // 标注该类是一个feign接口
public interface UserClient {
@GetMapping(“user/{id}”)
User queryUserById(@PathVariable(“id”) Long id);
}重启测试：
请求压缩：
Spring Cloud Feign 支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。通过下面的参数即可开启请求与响应的压缩功能：
feign:
compression:
request:
enabled: true # 开启请求压缩
response:
enabled: true # 开启响应压缩
同时，我们也可以对请求的数据类型，以及触发压缩的大小下限进行设置：
feign:
compression:
request:
enabled: true # 开启请求压缩
mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
min-request-size: 2048 # 设置触发压缩的大小下限
注：上面的数据类型、压缩大小下限均为默认值。
Zuul网关
===================================================================
通过前面的学习，使用Spring Cloud实现微服务的架构基本成型，大致是这样的：
- 使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；
- 服务间通过Ribbon或Feign实现服务的消费以及均衡负载。
- 为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。
在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？
我们可以将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器的服务网关。
服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。
Zuul网关官网：https://github.com/Netflix/zuul
Zuul加入后的架构
不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现 鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。
