Lxn2zh的博客

span 跨度：基本工作单元，span使用一个64位的id唯一标识，还包含有描述、时间戳、span 父id等，根span被称为root span，该span的id与trace id相等。就是将一次分布式请求还原成调用链路，将一次分布式请求的调用情况集中展示，如各个服务节点的耗时、具体请求的服务器、各节点的请求状态等，主要是用于分布式系统进行问题定位。集成在每个服务的代码中，负责Span的生成，带内数据(traceid等)的传递，带外数据(span)的上报，采样控制。springCloudSleuth简介。

由于市面上的消息中间件有很多，导致学习成本很大，而springCloudStream则将消息中间件进行再次封装，屏蔽了具体中间件的细节，应用程序通过inputs或者outputs来与Spring Cloud Stream中binder对象交互，通过配置来进行绑定，spring Cloud Stream的binder对象负责与消息中间件交互，目前支持RabbitMQ和kafka。@StreamListener 监听队列，用于消费者的队列的消息接收。@Input 注解标识输入通道，用于接收消息。

HTTP连接需要进行TCP三次握手，是一个比较耗时的操作，一般我们不直接使用HttpURLConnection，而是使用HttpClient/okHttp等支持连接池的客户端工具，以Feign集成OkHttp为例。OpenFeign本质是HTTP来进行服务调用的，也就是需要集成一个Http客户端。默认是HttpURLConnection方式，也就是jdk中提供的最原始的那个。要开启OkHttp ,还需要在YML 中添加开启配置项，默认是关闭的。使用的是Client接口来进行请求的。

代码也比较简单，可以看到是先获取的contextId，如果配置了 contextId 就会用 contextId，如果没有配置就会取 value 然后是 name 最后是 serviceId。在使用@FeignClient的时候，发现多个@FeignClient中的name相同就无法启动，当然了，这是因为bean名称重复了，创建bean的时候报的错，但是如何解决呢?拼接的beanName就是clientName.FeignClientSpecification。可以配置不同的contextId来进行解决。

OpenFeign提供了日志打印功能，可以配置不同级别的日志级别。OpenFeign日志打印。

由于OpenFeign是整合的ribbon进行的负载均衡，所以使用ribbon进行配置超时时间即可。openFeign默认超时时间是1s，如果超时则会报错。OpenFeign超时。

OpenFeign是SpringCloud对于Feign进行的再次封装，使其支持了SpringMVC的标准注解以及HttpMessageConverters。直接调用该方法就可以调用该微服务的接口。OpenFeign简介。

和 Feign 使用的时候需要注意错误处理的问题。对于一些非功能性的业务错误，需要包装为 HystrixBadRequestException，让 Hystrix 不要统计到错误中造成断路。会使用HystrixFeign.builder()来构建Feign，将具体的调用包裹在HystrixCommand 中。虽然开启了hystrix，但是其默认不带有监控端点，如果想要使用监控端点，需要加依赖。Feign默认已经整合了hystrix，只是默认是没有启用的，需要进行配置。Feign与Hystrix。

通过实现RequestInterceptor接口来实现Feign的拦截器，实现apply方法。

在构建RequestTemplate的时候会进行参数解析，如果参数是@RequestBody的会调用Encoder的encode方法进行编码（BuildEncodedTemplateFromArgs）首先通过@EnableFeignClients注解开启Feign功能，程序启动时开启对@FeignClient注解的扫描。当接口的方法调用时，通过动态代理SynchronousMethodHandler生成具体的RequestTemplate。Feign的执行流程。

然后发现@FeignClient注解中有一个属性是fallbackFactory，看着这个是有一个Throwable参数的，拿来试一试。我在最一开始使用Feign的时候，是使用FallBack类去实现的FeignClient接口，就像这样。但是这样的话，我发现没有办法查看是因为什么原因造成的fallback呢，这种方法肯定是不行的。Feign显示fallback异常原因。

但是有时候默认的并不满足全部的场景，我们需要自定义来进行配置，可以通过@FeignClient注解中的configuration属性来配置自定义的feign配置类，其优先级高于FeignClientsConfiguration。Feign的默认配置类是FeignClientsConfiguration，其内部定义了Feign默认使用的编码器、解码器、契约、重试机制等。自定义Feign的配置。

在向服务发送请求时，有些情况需要对请求内容进行处理。可以对服务响应的内容进行处理。Feign的编解码器。

feign底层默认使用的是jdk原生的URLConnection发送http请求，没有连接池，可以使用Apache的HttpClient来替换Feign原始的httpClient，使用连接池。通过动态代理的方式来构建Http请求。Feign是Netflix开发的一个声明式的HTTP客户端(远程服务调用组件)，只需要接口+注解即可完成对于微服务的调用，不需要使用RestTemplate+Ribbon来对微服务进行访问，简化了编程，直接调用该方法就可以调用该微服务的接口。，目标是减少HTTP调用的复杂性。

有一个HystrixCommandAspect是专门用来处理@HystrixCommand注解的。是不是感觉很熟悉，就是一个AOP切面，然后会使用@Around环绕来进行处理。executionType为SYNCHRONOUS。[ ] 这里用的是Rxjava的，需要后续研究一下。2.创建HystrixInvokable。HystrixCommand如何执行。1.创建MetaHolder。

判断熔断器(circuit-breaker)是否打开，如果打开则执行fallback进行降级策略，如果关闭继续执行。调用HystrixCommand的run方法，运行依赖逻辑，如果逻辑调用超时，则执行fallback逻辑。判断线程池/队列/信号量是否跑满，如果跑满执行fallback进行降级策略，否则继续后续步骤。判断逻辑是否调用成功，如果调用成功，则返回调用结果；如果调用出错，则执行fallback逻辑。每次调用创建一个新的HystrixCommand，把依赖调用封装在run()方法中。

我们可以根据我们自己不同需求通过装饰去扩展它。在微服务框架中，可能一个服务需要调用多个微服务，在tomcat中运行时，tomcat只是分配了100个线程，由于多个服务之间调用的时间消耗过长，可能会导致线程耗尽，而在Hystrix中存在线程隔离，对于每个微服务分配一个线程池，访问某个微服务时就从对应的线程池中取线程，如果对应线程池中的线程都用光了，那么就认为该服务不可用了，如果在需要请求该微服务，则直接返回。那么这个线程池是存在于哪里呢？Hystrix线程隔离。

信号量隔离(SEMAPHORE) 使用该策略，HystrixCommand将会在请求线程上执行，开销相对较小，并发请求收到信号量个数的限制，其一般仅适用于非网络调用的隔离，只有当调用负载非常高时(每秒调用几百上千次)，才会使用信号量隔离，因为负载过高的情况下使用THREAD开销会比较大。线程隔离(THREAD) 使用该策略，HystrixCommand将会在单独的线程上执行，并发请求受线程池中的线程数的限制，默认使用该策略，因为该策略有一个除网络超时外的额外保护层。Hystrix隔离策略。

设置隔离策略，THREAD表示线程 SEMAPHORE表示信号量，默认THREAD，有几种情况可以使用SEMAPHORE模式：只想控制并发度 外部的方法已经做了线程隔离 调用的是本地方法或者可靠度非常高、耗时特别小的方法。一个滑动窗口下的最小的请求次数(请求是否达到开启的阈值)，默认20，只有在一个统计窗口内处理的请求数量达到这个阈值，才会进行熔断与否的判断。设置每个桶保存的执行时间的最大值，如果设置为100，但是有500次请求，则只会计算最近的100次。threadPoolProperties配置。

Hystrix除了熔断降级之外，还提供了准实时的调用监控，持续的记录所有通过Hystrix发起的请求的执行信息，并以统计报表的形式展示出来，包括有每秒执行多少请求，多少成功，多少失败等，通过hystrix-metrics-event-stream实现对以上指标的监控。还可以用turbine-stream使用消息中间件收集数据，各个微服务将Hystrix Command的监控数据发送至消息中间件，Turbine消费消息中间件中的数据。如果是turbine集群，则填入。turbine-stream配置。

服务熔断 当下游的服务因为某种原因不可用，上游服务为了保证自己整体服务可用，不再继续调用目标服务，直接返回，快速释放资源，类似于保险丝，当某个异常条件被触发时，直接熔断整个服务，而不是一直等到此服务超时，用于应对雪崩效应的一种保护机制，注解是@HystrixCommand，失败次数达到一定阈值，就会启动熔断，当检测到该服务响应正常后，则恢复调用 熔断是解决服务雪崩的一种方案。为了解决该问题，hystrix使用了线程池/信号量隔离，为不同的接口提供独立的线程池，使得各大线程池之间不互相影响。

根据平均响应时间计算所有服务的权重，响应时间越快的服务权重越大被选中的概率越高，刚启动时如果统计信息不足，则使用RoundRobinRule策略，等统计信息足够，会切换到WeightedResponseTimeRule。，会先过滤掉由于多次访问故障而处于跳闸状态的服务，然后选择一个并发量最小的进行访问。，先按照轮询策略获取服务，如果获取服务失败则在指定时间内进行重试，获取可用服务。除了使用注解，还可以使用配置文件来配置服务使用的ribbon负载均衡算法。Ribbon的负载均衡算法。

不同的后端服务器，可能机器的配置和系统当前的负载并不相同，因此他们抗压能力也不尽相同，给配置高负载低的机器配置更高的权重，让其处理更多的请求，而低配置负载高的机器，则给其分配较低的权重，降低其系统负载，加权轮询能很好的处理这一问题，并将请求顺序且按照权重分配到后端。，通过系统随机函数，根据后端服务器列表的大小值，来随机选取其中一台进行访问，由概率统计的理论可以得知，随着调用量的增大，其实际效果越来越接近于平均分配流量到每一台后端服务器，也就是轮询的效果。常见的负载均衡算法有以下几种。

实现自定义的全局过滤器，需要实现GlobalFilter和Ordered接口，全局过滤器，不需要在配置文件中配置，作用在所有的路由上，最终通过 GatewayFilterAdapter 包装成 GatewayFilterChain 可识别的过滤器，为请求业务以及路由的 URI 转换为真实业务服务请求地址的核心过滤器，不需要配置系统初始化时加载，并作用在每个路由上。有三种策略 RETAIN_FIRST、RETAIN_LAST、RETAIN_UNIQUE。全局过滤器不需要在配置文件中配置。

权重匹配，接收group和weight两个参数，权重是按照组进行计算的。Header是匹配请求头的name以及值的正则表达式进行匹配。会根据cookie的name以及值的正则表达式进行匹配。以Cookie断言为例，Cookie断言的配置类如下。gateWay网关中提供了多种断言方式。匹配在当前日期时间之后发生的请求。匹配在当前日期时间之前发生的请求。gateway配置断言有两种方式。匹配在两个日期之间发生的请求。RemoteAddr断言。断言Predicate。断言名称和参数之间是。

由于zuul升级为zuul2时，netflix公司内部出现了分歧，所以springcloud自己研发了一套网关gateway，提供一种简单有效的方式来对API进行路由，以及提供一些强大的过滤器功能，如：熔断、限流、重试等，基于WebFlux框架实现的，底层使用了高性能的Reactor模式通信框架Netty。路由是构建网关的基本模块，由ID、目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由。开发人员可以匹配HTTP请求中的所有内容，包括请求头和请求参数，如果请求与断言相匹配，则进行路由。

可以看到自动配置也是ZuulProxy继承的ZuulServer，所以ZuulProxy实现的内容更多，且ZuulProxy支持Ribbon和DiscoveryClient。@EnableZuulProxy包含了@EnableZuulServer中所有的过滤器，是@EnableZuulServer的超集。使用@EnableZuulProxy和@EnableZuulServer注解来标识网关。除@EnableZuulServer中的过滤器外还包含了。@EnableZuulServer过滤器。

基于Servlet2.5，不支持长连接，每次IO操作都是从工作线程中选择一个执行，请求线程被阻塞直到工作线程完成。将zuul注册到注册中心中，同时从注册中心中获取其他微服务的消息，之后访问其他微服务都是通过zuul进行跳转的。zuul的性能一般，采用了同步编程模型，对于IO密集型的服务如果处理时间过长会导致将servlet的线程池占满。zuul是Netflix开源的微服务网关，包含了对请求的路由和过滤两个主要的功能。路由，负责将外部请求转发到具体的微服务实例上，实现外部访问统一入口的基础。

令牌桶算法是一种反向的漏桶算法，桶中存放的不再是请求，而是令牌，只有拿到令牌后，才能对请求进行处理，如果没有令牌，就需要等待可用的令牌，为了限制流速，该算法每单位时间产生一定量的令牌存入桶中。漏桶算法是利用一个缓存区，当请求进入系统时，无论请求的速率如何，都先在缓存区内保存，然后以固定的流速流出缓存区进行处理，使用队列实现。将单位时间分为多个区间，每个区间都有一个计数器，有一个请求落在该区间内，则该区间的计数器就会加一。每过一段时间，时间窗口就会滑动一格，抛弃最老的一个区间，并纳入一个新的区间。

在PropertySourceBootstrapConfiguration的initialize方法中会遍历propertySourceLocators集合，来执行PropertySourceLocator的locateCollection方法，这样就和springCloudConfig获取配置接上了，使用ConfigServicePropertySourceLocator类。springCloudConfig核心其实在于实现了一个PropertySourceLocator接口来进行获取远程配置的。

Spring Cloud Bus是将分布式系统的节点与轻量级消息系统链接起来的框架，整合了java的时间处理机制和消息中间件功能，目前支持RabbitMQ和kafka，构建一个共用的消息主题，并让系统中所有的微服务实例都连接上来，该主题产生的消息会被所有实例监听和消费，所以被称为消息总线。ConfigClient实例都监听MQ中同一个topic(默认是springCloudBus)，当一个服务刷新数据时，会把这个信息放入到Topic中，这样其他监听同一Topic的服务就能得到通知，然后更新自身的配置。

第二种是bootstrap.yml，是系统级别的，优先级更高，springcloud对于bootstrap.yml会创建一个'Bootstrap Context'，作为Spring应用的Application Context的父上下文，初始化时，Bootstrap Context负责从外部源加载配置属性并解析配置，这两个上下文共享一个从外部获取的Environment，Bootstrap的优先级更高，默认情况下，不会被被本地配置覆盖。配置发生变化时，服务不需要重启即可感知到配置的变化并应用新的配置。

Eureka的AP原则，Eureka中各个节点是平等的，几个节点挂掉不会影响正常的节点工作，正常的节点依然可以正常提供注册和查询服务，只要有一台Eureka还在，就可以保证注册服务可用，只不过可能查到的信息不是最新的(不保证强一致性)，且存在自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，则认为客户端与注册中心之间出现了网络故障，此时会出现以下情况。类似多机房部署，保证服务稳定性。采用C-S架构，Eureka Server作为服务注册的服务器，是服务注册中心。

eureka的高可用性，不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功，当数据出现不一致时，虽然A，B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息如果请求A查不到，但请求B就能查到。提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。Eureka Server注册中心配置。

Eureka集群模式，集群内的每个机器地位是相等的，不存在主从，每个服务可以向任意一个Eureka实例进行服务注册与发现，集群中的每一个Eureka实例接收到写请求之后都会自动同步给其他所有的Eureka实例。Eureka是对等模式，可能数据还没同步完，然后就宕机了，此时还是可以从其他机器拉取注册信息，只是不保证是最新的注册信息，该过程服务可以向其他没有宕机的节点进行注册，为了保证A而舍弃了C。AP:如果需要可用性，只要有一个服务在，就能正常接受请求，只能放弃强一致性，采用最终一致性。

服务提供者在启动的时候，将其提供的服务名称，服务器地址注册到服务注册中心，服务消费者通过服务注册中心来获得需要调用的服务的机器列表，通过相应的负载均衡算法，选取其中一台服务器进行调用，当服务器宕机或者下线的时候，相应的机器需要能够动态的从服务配置中心里面移除，并通知相应的服务消费者，否则服务消费者就有可能调用到已经失效的服务而发生错误。服务注册与发现，服务注册是指微服务启动时，将自己的信息注册到注册中心；微服务启动时，将自己的网络地址等信息注册到注册中心中，注册中心会存储这些信息。

微服务是一种架构风格，将单体应用划分为小型的服务单元，微服务之间使用HTTP的API进行资源访问和操作，与SOA不同的是，SOA架构侧重于将每个单体应用的服务集成到ESB(消息总线)上，而微服务强调将整个模块变成服务组件，对模块的划分粒度更细致。springcloud是基于springboot提供的一整套微服务解决方案，包括服务注册与发现，配置中心，链路监控，服务网关，负载均衡，熔断器等组件，是各个微服务架构落地技术的集合体。Eureka：基于REST服务的注册中心，用于服务管理。