目录
1. Feign的基本使用
第一步：引入Feign的依赖，这里要注意，当模块A要调用模块B的方法时，要在调用者中加入Feign的依赖，依赖如下
第二步：要在调用者的启动类上添加注解
第三步：编写Feign的客户端，假设，在orderservice层，查询订单信息，需要调用userservice层查询用户信息的方法
2. 自定义Feign的配置
3. Feign的性能优化
4. Feign的最佳实践，如何使用Feign？
第一种（继承）：给消费者的FeignCilent和提供者的Controller定义统一的父接口作为标准，如下图所示：
第二种（抽取）：将FeignClient抽取成一个独立模块，并且把有关的POJO，默认的Feign配置都可以放在这个模块当中，提供给所有消费者使用。这样说可能有些抽象，我来简单举例说明
5. 最佳实践实际操作(方式二)
（1）这里我们创建feign-api模块，
（2）定义UserClient
方案一：在启动类@EnableFeignClients注解上指定要扫描的client包
方案二：仍然是在启动类上的@EnableFeignClients注解上指定要扫描的特定的字节码文件，也就是你用哪个扫哪个，如下所示：
1. Feign的基本使用
Feign是一个声明式的http客户端，我们知道，在不使用Feign之前，在微服务中，一个模块如果想要调用另一个模块中的某个功能，需要向其发起请求http请求，如果不使用Feign，我们就需要通过硬编码的形式去编写构建http请求，例如使用RestTemplate发起远程调用。如下所示：
可以看到，这样的编码明显是不太友好的。
代码可读性差，而且编程体验也不好；
参数复杂时URL难以维护。
因此，就要引出我们的Feign，Feign可以帮助我们发送http请求，解决上面的问题。
那么Feign该怎样使用呢？其实很简单
第一步：引入Feign的依赖，这里要注意，当模块A要调用模块B的方法时，要在调用者中加入Feign的依赖，依赖如下
org.springframework.cloud
spring-cloud-starter-openfeign
第二步：要在调用者的启动类上添加注解
@EnableFeignClients
开启Feign功能，不加注解是不启动的
第三步：编写Feign的客户端，假设，在orderservice层，查询订单信息，需要调用userservice层查询用户信息的方法
在orderservice模块中新建一个包client，需要声明的客户端如下，其实就是一个接，因为是要查询User信息，所以定义为UserClient
@FeignClient(value = "userservice")
public interface UserClient {
@GetMapping("/user/{id}")
User findById(@PathVariable("id") Long id);
}这里声明的客户端需要和上述中的方法体保持一致，都要使用@GetMapping，路径也要保持一致。@FeignClient(value = “userservice”)这里面因为我写的这个方法是userservice业务模块的，所以指定value值就是userservice。
完成上述三步之后，在orderservice业务模块中查询订单的方法中，我们就不需要像之前那样采用硬编码的形式，采用自动装配userClient，那么方法及可以改成下面这种形式
（1） 用户传入要查询的订单信息，通过orderId查询到订单
（2）然后我们直接就可以使用注入的userClient远程调用，其实就是调用了我们定义的接口
此外这里多提一句，Feign不仅可以帮助我们发送请求，还可以帮助我们实现负载均衡，因为在Feign内部，已经集成了Ribbon。
2. 自定义Feign的配置
Spring Boot已经自动装配了Feign的配置，但是我们自己是可以修改或者自定义Feign的配置的，可以修改的配置如下：
上面是我们最常用到的，当然也还有其他的，这里就不说了
简单来说一下日志，日志一共分为四个级别
NONE：没有任何日志，也是默认配置；
BASIC：可以记录http请求什么时候发送，什么时候结束，耗时多久等基本信息；
HEADERS：除了BASIC中含有的以外，还包含请求头和响应头；
FULL：是最全面的，除了HEADERS中包含的以外，还包含请求体信息和响应体信息。
自定义Feign配置是有两种方式的
方式一：配置文件方式，这里又可分为全局生效和局部生效
在application.yml文件中的全局配置如下：
其实default默认的就是全局配置，如果想要局部生效（即对某个微服务生效，将default改成对应的服务名称即可）。
这里loggerLevel我定义为FULL，我先清空一下控制台
然后打开浏览器查询一下102订单，查询成功如下
再来看控制台打印的信息
可以看到打印了一大堆日志。
方式二：就是采用Java代码的形式，需要先申明一个Bean，在Bean中定义好日志的等级
public class DefaultFeignConfiguration {
@Bean
public Logger.Level logLevel(){
return Logger.Level.BASIC;
}
}当然了，这里也分为全局生效和局部生效
想要局部生效时，就在Feign的具体的接口上的注解上添加configuration = FeignConfiguration.class，如下所示：
@FeignClient(value = "userservice",configuration = DefaultFeignConfiguration.class)
public interface UserClient {
@GetMapping("/user/{id}")
User findById(@PathVariable("id") Long id);
}
想要全局生效时，就在功能模块的启动类上的启动Feign的注解上添加值defaultConfiguration = FeignConfiguration.class，如下所示：
@EnableFeignClients(defaultConfiguration = DefaultFeignConfiguration.class)
这里我也设置为全局生效，重启服务器，打开浏览器仍然查询订单102，打开idea重新观察，如下所示
可以看到BASIC相比于FULL，明显少了许多。
总结得出如下图
这里我建议，如果是调试错误的时候，可以使用FULL；但如果日常开发，建议使用NONE或BASIC。因为记录日志也是会消耗一定的性能的。
3. Feign的性能优化
说起性能调优，大家都不陌生，不管开发什么，用什么工具，都会有调优这一说，例如jvm调优，mysql调优。其实Feign的性能本身已经很好了，但是还是有优化的余地，我们先来了解一下Feign的底层实现
第一种URLConnection是默认实现，是JDK自带的，它的性能是不太好的，而且不支持连接池。
连接池可以避免我们创建和销毁的一个性能损耗，而且连接需要三次握手，断开需要四次挥手，是比较浪费性能的。所以我们可以使用另外两个，所以对Feign性能的优化，就是对底层实现的改变。还有就是我们上述的日志的级别，也是对Feign性能稍微有影响的，这也是为什么Feign日志默认是NONE。
这里我就采用Apache HttpClient来实现
第一步：引入HttpClient的依赖，maven依赖如下
io.github.openfeign
feign-httpclient
第二步：配置连接池
feign:
httpclient:
enabled: true # 支持HttpClient的开关
max-connections: 200 # 最大连接数
max-connections-per-route: 50 # 单个路径的最大连接数
这里enable要设置为true，打开开关；下边的连接参数和我们之前学的数据库连接池有些相似，很好理解，这两个数量设置多少合适没有具体数值，可以在具体的业务中进行测试，测试设置为多少位最好，因项目而异。
总结如下图
4. Feign的最佳实践，如何使用Feign？
关于Feign如何使用，大概可以分为以下两种：
第一种（继承）：给消费者的FeignCilent和提供者的Controller定义统一的父接口作为标准，如下图所示：
因为orderservice业务中要向userservice发起请求，要通过FeignCilent，FeignClient又需要定义和userservice业务中控制层完全一样的接口，所以我们可以定义一个父接口，让UserClient接口去继承这个父接口，让userservice业务中Controller层去实现这个父接口，之前我们的Controller层都是自己定义方法，这样一来就不需要了，我们直接实现父接口，UserAPI也算是一种规范，算是对子类型为的一个约束，给Feign客户端和Controller定义统一的标准。
但是，这种方式确有一定的问题，下面这段话是Spring官方给出的一个说明
翻译过来就是，“一般情况下不推荐在服务端和客户端共享一个接口，因为它会造成紧耦合，而且这种继承方案对SpringMVC是不起作用的”。我来简单解释几个问题，
第一，紧耦合，因为我们的服务端FeignClient和客户端Controller都实现了同一个接口，一旦后期我们的接口发生了改变，那么两端都需要发生改变，需要付出巨大的成本。我们做项目都希望高内聚低耦合，方便后期对业务的扩展，所以这个方法是有点缺点的。
第二：“这种继承方案对SpringMVC是不起作用的”这句话的意思也就是说，我们在Controller层继承此接口时，参数是不能继承下来的，例如我们所写的@PathVariable，这个是需要我们自己补充的。
尽管上述两点是此方法的一些缺点，但是！！！这个方法实现了面向契约编程，而且在一些小型微服务项目中特别合适，因此仍然也是比较流行的。
第二种（抽取）：将FeignClient抽取成一个独立模块，并且把有关的POJO，默认的Feign配置都可以放在这个模块当中，提供给所有消费者使用。这样说可能有些抽象，我来简单举例说明
如下：
有三个模块，user-service，orde-rservice，pay-service，假设我们的orde-rservice，pay-service模块都需要user-service模块中的功能，按照我们的第一种做法，就是各自都实现UserClient，如果后期模块越来越多，相互调用越来越复杂，那么这个项目的耦合度是非常恐怖的，就背离了我们的微服务项目的初衷。
由此就引出了第二种方法
这里我们把Feign也当作微服务的一个模块，专门用来存放各种的POJO类和默认配置，这样的话，我们的所有业务模块只需要引入我们的feign-api依赖即可直接使用。这样我们就大大的降低了项目的耦合度。
但是！！！这种方案也有一定的问题。例如，我的order-service模块只需要feign-api模块中的一个功能，但是我又必须要用，我就必须将feign-api所有的东西都通过依赖拿过来，不管用不用，其他模块也是如此，这样就造成了一定资源的浪费。
综上所述，两种方案都是有利有弊。看项目和公司如何选择了，如果不想耦合，就可以选方式二；如果不很在意耦合想省事，就可以使用方式一。没有完美的解决方案，根据需要选择即可。
5. 最佳实践实际操作(方式二)
刚才我们说了继承和抽取两种方案，这里的话我实际操作一下，我选择的是方式二(抽取)。
步骤分为三步：
（1）新建feign-api模块，引入feign的依赖；
（2）将所需要的Client定义到feign-api模块中；
（3）在所需要的业务模块中引入我们创建的feign-api依赖；
（4）完成上述操作之后，我们都可以重启测试了。
（1）这里我们创建feign-api模块，
gateway模块不需要关心，与本次无关。
打开pom文件继承父工程cloud-demo。引入openfeign依赖，如下
cloud-demo
cn.itcast.demo
1.0
4.0.0
feign-api
8
8
org.springframework.cloud
spring-cloud-starter-openfeign
（2）定义UserClient
这里我只是做举例，所以实体类只写了User，之前orderservice业务中的User累就可以删掉了。
@Data
public class User {
private Long id;
private String username;
private String address;
}实际项目中用到那个写那个。
这里我只定义了关于User的Client接口，实际开发也一样，有别的业务在定义别的业务的接口
@FeignClient(value = "userservice")
public interface UserClient {
@GetMapping("/user/{id}")
User findById(@PathVariable("id") Long id);
}这里我单独创建config包定义了日志的等级
public class DefaultFeignConfiguration {
@Bean
public Logger.Level logLevel(){
return Logger.Level.BASIC;
}
}和上面第二节我说的一样，全局生效就在对应模块的启动类上配置，局部生效就在上面定义的UserClient接口上的@FeignClient中配置，这里我是全局生效就不再展示了。
（3）在对应的业务模块中引入我们定义的feign-api依赖，这里就是orderservice业务模块，这里我直接把orderservice的pom文件全展示一下吧
cloud-demo
cn.itcast.demo
1.0
4.0.0
order-service
org.springframework.boot
spring-boot-starter-web
mysql
mysql-connector-java
org.mybatis.spring.boot
mybatis-spring-boot-starter
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
org.springframework.cloud
spring-cloud-starter-openfeign
io.github.openfeign
feign-httpclient
cn.itcast.demo
feign-api
1.0
app
org.springframework.boot
spring-boot-maven-plugin
这里还有一点非常重要，千万千万要注意，当我们将feign独立成一个模块之后，我们的Spring容器再去注入Client时，是会报错的。因为我们在独立出来之前，orderservice模块启动类默认扫描的是整个orderservice模块，当时我们把feign写在orderservice模块中，肯定是能扫描到的。但现在独立出来了，它就扫不到了，会报错。
这里有两种解决方案
方案一：在启动类@EnableFeignClients注解上指定要扫描的client包
如下所示：
方案二：仍然是在启动类上的@EnableFeignClients注解上指定要扫描的特定的字节码文件，也就是你用哪个扫哪个，如下所示：
如果你某个模块有多个client要用时，可以扫包，更快捷；
如果你某个模块只有一个client要用是，可以扫指定的文件。
两种方式都可以，根据需要即可
（4）完成上述操作之后我们重启项目，在浏览器输入localhost:8088/order/102 查询订单id为102的订单信息如下所示
可以看到我们已经查询成功了。所以项目应该是没有问题的。
