SpringCloud服务调用

传送门

SpringMVC的源码解析（精品）
Spring6的源码解析（精品）
SpringBoot3框架（精品）
MyBatis框架（精品）
MyBatis-Plus
SpringDataJPA
SpringCloudNetflix
SpringCloudAlibaba（精品）
Shiro
SpringSecurity
java的LOG日志框架
Activiti（敬请期待）
JDK8新特性
JDK9新特性
JDK10新特性
JDK11新特性
JDK12新特性
JDK13新特性
JDK14新特性
JDK15新特性
JDK16新特性
JDK17新特性
JDK18新特性
JDK19新特性
JDK20新特性
JDK21新特性
其他技术文章传送门入口

前言

本文第一代SpringCloudNetflix和第二代SpringCloudAlibaba都有讲解。参考尚硅谷周阳老师的资料。
下面文章不定期更新中。。。

SpringCloud服务注册中心
SpringCloud服务调用
SpringCloud服务降级
SpringCloud服务网关
SpringCloud服务配置
SpringCloud服务总线
SpringCloud消息驱动
SpringCloud链路跟踪
SpringCloud分布式事务

全部三个服务调用：Ribbon、Feign、OpenFeign

一、Ribbon

1、概念

Spring自己出了一个LoadBalancer想替换掉Ribbon，哪怕Ribbon不维护了，但是生命力非常顽强，很多很多在用

Ribbon是Netflix开源的一款负载均衡的服务调用组件，Spring Cloud将其集成在了Spring Cloud Netflix模块中。

Ribbon可以作为客户端负载均衡器，可以将请求分发到多个服务提供者实例中，从而实现负载均衡和故障转移。它能够根据不同的负载均衡策略（如轮询、随机等）来选择目标服务实例，还支持自定义的负载均衡策略。

在Spring Cloud应用中，Ribbon可以与Eureka、Consul等服务发现组件集成，通过服务注册与发现，自动获取可用的服务实例列表，并进行负载均衡。通过Ribbon，开发者不需要手动管理服务实例，简化了服务调用的开发和维护工作。

除了负载均衡，Ribbon还提供了一些其他功能，如超时机制、重试机制等，可以提高服务调用的可靠性和可用性

2、Ribbon和Nginx的负载均衡区别

3、消费者修改配置

由于Ribbon是客户端的策略，所以只是消费者改，Eureka本身非常强大，内含了Ribbon的包，而在用Eureka当注册中心的时候，不管是消费者还是服务提供者都是Eureka的客户端，都得引入Eureka的包，自动就包含Ribbon的包了，所以Ribbon的jar包不用再次引入，当然想再次引入还是可以的。

pom中jar包不用引入了，不用改pom了，但是实际操作的时候，我单独引入了，新版不是这样了，又删除掉了，引入以后可以了。

不用默认轮询策略的时候，自己定义一个。(这个图有错误，正确写法看后面，没有@LB注解，类名和方法名还不能一样)

注意分包规则

yml也没改，就这边多了一个注解。

正确写法（其实坑了两三个小时，根本用不了这个自定义的，网上说是因为Eureka包删除了Ribbon，最官方的这种用法不行了。）

解决方案：
https://blog.csdn.net/qq_35799668/article/details/114534023

必须要的类（上面就是默认的方式）

可以不用，自定义的算法

4、二说restTemplate

两种get，简单认为Object是个json，Entity比Object多点响应码之类的东西，封装了一下Object吧。推荐用Object，json串对前后端都友好。

简单认为Object是个json，Entity比Object多点响应码之类的东西，封装了一下Object吧。

5、负载均衡策略

注意

要特殊化定制

二、Feign

1、概念

是声明式WebService客户端，能让编写的WebService（跨平台跨语言的规范，用于不同语言应用之间的交互）客户端更简洁。Feign 旨在使编写 Java Http 客户端变得更容易。前面在使用 Ribbon + RestTemplate 时，利用 RestTemplate 对 http 请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。SpringCould对Feign进行了封装。Feign也是客户端的负载均衡。
（就是Ribbon改进了一下，底层是Ribbon，不用rsetTemplate，创建接口，接口上加注解，感觉像调用本地方法而不是一个http，核心注解@ FeignClient）

调用微服务的两种方法：
Ribbon：微服务名字
Feign：接口和注解

个人理解：Feign生产者微服务提供具体方法实现，就像单机版的UserServiceImpl类，提供的是真正的方法实现，并且生产者服务不需要配置什么，Feign的消费者微服务，要调用（消费者微服务加个@EnableFeignClients），就需要增加一个UserService接口，一一对应Impl类中的方法，并且在这个接口上加@FeignClient(value=“生产者微服务名字”)，这样注入UserService就可以用了。单机版的Service和ServiceImpl在同一个地方，Service接口上面加@Service注解，而Feign就是分开了，一个在消费者服务里面（Service接口），一个在生产者服务里面（ServiceImpl）；当然将Service从消费者服务里面放到公共服务更好，这样很多个消费者服务都可以调用了。

Feign是Spring Cloud微服务框架中的一个声明式、模板化的HTTP客户端。它可以让开发人员更加方便地编写基于HTTP的服务间通信的客户端代码。

Feign通过注解生成和动态代理技术将接口定义与HTTP请求的调用绑定在一起，使得开发人员可以像调用本地方法一样调用远程服务。开发人员只需要定义一个接口，加上@FeignClient注解指定要调用的服务名称和服务端口，然后在接口的方法上使用@Requestmapping或其他HTTP请求相关的注解即可。

Feign还提供了负载均衡、内置的HTTP请求重试和错误解码机制等功能，以满足微服务架构中的服务间通信的需求。同时，Feign还与Ribbon、Eureka等Spring Cloud组件集成，可以实现服务发现和负载均衡的功能。

总而言之，Feign是Spring Cloud中用于简化编写基于HTTP的服务间通信的客户端代码的工具，它使得开发人员可以更加方便地调用远程服务，并提供了一些功能来增强服务间通信的可靠性和可扩展性。

2、代码

接口+注解（放到了一个公共的地方，其实直接可以放到消费者服务里面，但是公共地方很多其他微服务也方便调用了）

消费者服务的注解配置

消费者服务的使用

三、OpenFeign（核心）

1、概念

在Feign的基础上加强了，支持SpringMVC的标准注解。
默认超时1秒那边也不对，一定要看引入的是什么版本包，去看源码，我在20220225引入的新包，默认超时已经改成了60秒，并且OpenFeign的jar包已经不包含Ribbon的jar包了，所以改超时时间，也不能用Ribbon的配置了。

OpenFeign是Spring Cloud中的一个声明式的HTTP客户端，它简化了通过HTTP调用其他微服务的过程。OpenFeign提供了一种类似于编写Retrofit接口的方式来定义和配置HTTP请求，可以将HTTP请求的细节隐藏在接口中，使得调用其他微服务变得简单和直观。

通过使用OpenFeign，开发者只需要定义一个接口，并使用注解来描述HTTP请求的细节，例如URL、HTTP方法、请求头、请求体等，然后Spring Cloud会自动为这个接口生成一个具体的实现，开发者可以像调用普通的Java接口一样使用它来发起HTTP请求。

OpenFeign还提供了负载均衡的能力，可以根据服务名自动选择目标微服务的实例进行调用，从而实现了服务间的通信。同时，OpenFeign还集成了Hystrix和Ribbon等组件，提供了服务容错和负载均衡的支持。

总之，OpenFeign是Spring Cloud中的一个用于简化微服务间HTTP通信的框架，它通过提供声明式的接口和自动化的实现，使得调用其他微服务变得更加简单、直观和可靠。

2、消费者改配置

消费者orderFeign80改pom （注意用的Eureka一套，所以Eureka的jar包要引入）（注意引入OpenFeign包）

yml不用专门为OpenFeign做什么，引入注册中心就可以了

启动类增加注解

增加转为OpenFeign准备的接口（这边可以直接拷贝 服务提供者Controller里面的方法头。）

不用restTemplate了，不用Ribbon

四、OpenFeign的超时控制（深坑）

1、概念（默认1秒超时是错误的，要看版本里面的源码，我引入的是60秒超时）

看版本的理论，SpringCloud注册中心有提到版本的理论，文章见传送门

在OpenFeign的jar包真的包含Ribbon的jar包时，这种设置才有用，我引入的jar包没有包含，该配置就没有效果的。

2、专门提供一个错误接口，理解概念

修改服务提供者
Payment8001服务提供者 专门增加一个 3秒才返回结果的 接口，这样 消费者服务OpenFeign调用后，3秒才返回结果，而默认设置1秒的时候，就会超时报错

服务提供者修改后，浏览器测试后，3秒才返回结果，服务提供者修改成功。

修改消费者
orderFeign增加上面Payment8001对接的接口，来调用payment8001提供的接口，查看结果，默认配置是会报超时错误的。

Controller增加接口调用

测试结果
反复测试，发现并没有写错误代码，3秒并没有超时，经过排查源码，发现并不是1秒超时了，最新的jar包改成了60秒超时。
坑1：由于payment8001修改了，payment8002没有增加timeout的接口，所以两个都启动的话，OpenFeign轮询查询，当查到payment8002调用timeout接口的时候就报404错误了，因为8002压根没有增加。所以测试的时候不要启动8002接口，这也间接说明了轮询这种策略的弊端，集群代码必须一模一样，不然真的坑啊，两边接口啥的要保持一模一样。
坑2：尚硅谷周阳视频中讲解的时候，引入的OpenFeign的jar包是包含了Ribbon的jar包的，所以他用了Ribbon的设置来吧默认1秒超时，改成5秒，但是我引入的是最新版的，不仅没有包含Ribbon的jar包，而且默认超时也不是1秒了，查看源码，发现是60秒了。太坑了。

yml的正确配置

我引入的OpenFeign的jar包没有包含Ribbon

找源码


找源码，发现默认时间不是1秒了，而是60秒了

我改成默认1秒，生效配置的超时结果

默认时间够用了，也就是上面yml的配置其实不用加了。

五、日志打印

1、概念

2、日志级别

3、消费端修改

增加配置类，修改默认级别NONE为FULL

改yml

4、测试结果

报错的日志比较全面了。

正确接口的日志也非常全面。