一、Sleuth与Zipkin整合

Zipkin简介

Zipkin是Twitter的开源项目，致力于服务器间的链路追踪，它通过RESTAPI接口来辅助我们查询跟踪链路，以实现对分布式系统的服务链路监控，从而找到延迟高等问题。

它的一大特点是自带图形化界面，像Hystrix的Hystrix-dashboard一样，很直观的查看和搜索链路间的明细。

上图就是Zipkin的基础架构，分为四大组件：

一、分布式服务跟踪

简介

通过之前的学习，我们已经可以搭建起一套比较完善的微服务架构了，进而慢慢添加我们所需的业务需求。

随着业务增多，系统规模也会逐渐扩大，各个服务间互相调用也更加复杂，通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果。

这时，便需要一个服务跟踪技术，用来对前端请求后的服务调用链路进行跟踪，通过跟踪，可以找到哪条链路延迟高，或出现失败问题。

通过实现对请求调用的跟踪可以帮助我们快速的发现错误根源以及监控分析每条请求链路上的性能瓶颈等好处。

针对上面所述的分布式服务跟踪问题，Spring Cloud Sleuth提供了一套完整的解决方案。

Spring Cloud Stream

简介

Spring Cloud Stream 是一个消息驱动的微服务应用。

主要用途是，简化开发，统一抽象，使微服务对于消息中间件的使用与切换更加方便。

一、Zuul获取Routes规则

在上面，我们可以看到，在配置文件中配置路由，或者注册到注册中心中，就可以获取路由配置。

那么问题来了，这是如何做到的呢？

我们带着问题，可以先看下RoutesEndPoint这个类

RoutesEndPoint

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

@ManagedResource(description = "Can be used to list the reverse proxy routes")
@ConfigurationProperties(prefix = "endpoints.routes")
public class RoutesEndpoint extends AbstractEndpoint<Map<String, String>> {

   private static final String ID = "routes";

   private RouteLocator routes;

   private ApplicationEventPublisher publisher;

   @Autowired
   public RoutesEndpoint(RouteLocator routes) {
      super(ID, true);
      this.routes = routes;
   }

   @ManagedAttribute
   public Map<String, String> invoke() {
      Map<String, String> map = new LinkedHashMap<>();
      for (Route route : this.routes.getRoutes()) {
         map.put(route.getFullPath(), route.getLocation());
      }
      return map;
   }
}

一、SpringCloud Zuul入门

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。

Zuul在微服务中，便处于一个网关的地位，他自身整合了Ribbon和Hystrix，用作转发时的负载均衡和熔断。

我们接着上一节学习Feign的项目，来进行Zuul的学习。

一、简介

在之前，我们学习了Ribbon和Hystrix。微服务的负载均衡器以及服务熔断措施，大大稳定了微服务应用。

在使用Spring Cloud Ribbon的时候，是配合RestTemplate与@LoadBalanced使用的，RestTemplate封装了http请求，提供了一套模板化调用方法。这时我们会发现，在实际开发中，对于更多的应用以及接口的调用，要写大量的RestTemplate模板化内容。

这时SpringCloud为了方便开发，实现了Feign这一组件，它简化了Ribbon，我们只需要创建接口并使用注解配置，即可完成对服务提供方的接口绑定。它具备可插拔的注解支持，包括Feign注解、JAX-RS注解。它也支持可插拔的编码器和解码器。Spring Cloud Feign还扩展了对Spring MVC注解的支持，同时还整合了Hystrix来提供服务熔断。

一、简单介绍

1.问题的提出

在微服务架构中，各个服务的消费提供都是依赖远程调用的方式，这样便会因为网络，服务故障等问题出现请求超时，延迟。若此时服务调用数量增加，导致请求累计，最终会导致系统瘫痪。

举个例子：以淘宝为例，创建订单业务需要先查询库存，库存 > 0才允许创建，如果此时库存服务因某些问题故障，导致无法被访问，那么创建订单的线程会一直等待，最终导致创建失败，如果这是在双十一的时候，那么大量并发冲击，导致无数线程等待库存服务，最终会导致订单服务挂掉。

在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就会因依赖关系形成故障蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构就更加的不稳定。为了解决这样的问题，因此产生了断路器模式。

一、SpringCloud CircuitBreaker

首先我们从SpringCloud的官方断路器注解@EnableCircuitBreaker入手

@EnableCircuitBreake

1
2
3
4
5
6
7
8

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@Import(EnableCircuitBreakerImportSelector.class)
public @interface EnableCircuitBreaker {

}

一、Ribbon核心接口

对于下面介绍的接口，都很重要，他们组合在一起，就是负载均衡实现的原理，所以我们先来研究他们的接口，最后再看实现的步骤

1.负载均衡客户端

Spring对于命名非常灵性，对于负载均衡客户端，我们就可以在源码中搜索Load Balance Client即可，即可搜到LoadBalancerClient，即我们想要的接口，主要作用为：执行调用

LoadBalancerClient

这里我们简单放出源码，并进行一些转变，比如去掉注解，把父类的方法也拿进来之类的：

1
2
3
4
5
6
7
8
9
10
11

public interface LoadBalancerClient extends ServiceInstanceChooser {
    
    // 父类ServiceInstanceChooser方法
    ServiceInstance choose(String serviceId);

   <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException;

   <T> T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest<T> request) throws IOException;

   URI reconstructURI(ServiceInstance instance, URI original);
}

一、理论基础

1.客户端负载均衡（Ribbon）

客户端实现负载均衡，在SpringCloud中使用NetFlix的Ribbon

如图，负载均衡器和Client实例是在一起的，即一个完整的应用

好处：是比较稳定的，如果负载均衡器出问题的话，只会一个应用出问题，而不是整个应用都出问题。如果多个Client实例绑定到一台负载均衡器时，负载均衡器宕机就会导致全部出问题。

不足：升级的成本高，