spring cloud

服务发现（Eureka），断路器（Hystrix），智能路有（Zuul），客户端负载均衡（Ribbon）

(一)服务提供方@EnableDiscoveryClient和服务注册中心@EnableEurekaServer(起了两个应用)

（二）如何去消费服务提供者的接口

Ribbon是一个基于HTTP和TCP客户端的负载均衡器

创建RestTemplate实例，并通过@LoadBalanced注解开启均衡负载能力

Ribbon可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。

当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动

（三，断路器）当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放

（四）spring-cloud-config-server @EnableConfigServer application.properties中配置服务信息以及git信息

（五 服务网关）通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能

Zuul中提供了两种映射，通过url映射的方式对于Zuul来说，并不是特别友好，Zuul需要知道我们所有为服务的地址，才能完成所有的映射配置。而实际上，我们在实现微服务架构时，服务名与服务实例地址的关系在eureka server中已经存在了，所以只需要将Zuul注册到eureka server上去发现其他服务，我们就可以实现对serviceId的映射

服务过滤  ZuulFilter抽象类实现其定义的四个抽象函数就可对请求进行拦截与过滤

自定义过滤器的实现，需要继承ZuulFilter，需要重写实现下面四个方法：

• filterType：返回一个字符串代表过滤器的类型，在zuul中定义了四种不同生命周期的过滤器类型，具体如下：
  • pre：可以在请求被路由之前调用
  • routing：在路由请求时候被调用
  • post：在routing和error过滤器之后被调用
  • error：处理请求时发生错误时被调用
• filterOrder：通过int值来定义过滤器的执行顺序
• shouldFilter：返回一个boolean类型来判断该过滤器是否要执行，所以通过此函数可实现过滤器的开关。在上例中，我们直接返回true，所以该过滤器总是生效。
• run：过滤器的具体逻辑。需要注意，这里我们通过ctx.setSendZuulResponse(false)令zuul过滤该请求，不对其进行路由，然后通过ctx.setResponseStatusCode(401)设置了其返回的错误码，当然我们也可以进一步优化我们的返回，比如，通过ctx.setResponseBody(body)对返回body内容进行编辑等。