注意把register-with-eureka和fetch-registry修改为true或者注释掉
在上述配置文件中的${}表示在jvm启动时候若能找到对应port或者defaultZone参数则使用，若无则使用后面的默认值
把service-url的值改成了另外一台EurekaServer的地址，而不是自己
- 另外一台在启动的时候可以指定端口port和defaultZone配置：
修改原来的启动配置组件；在如下界面中的 VM options 中
设置 -Dport=10086 -DdefaultZone=http:127.0.0.1:10087/eureka
复制一份并修改；在如下界面中的 VM options 中
设置 -Dport=10087 -DdefaultZone=http:127.0.0.1:10086/eureka
-
启动测试；同时启动两台eureka server
-
客户端注册服务到集群
因为EurekaServer不止一个，因此user-service 项目注册服务或者consumer-demo 获取服务的时候，service-url参数需要修改为如下：
eureka:
client:
service-url: # EurekaServer地址,多个地址以’,'隔 开
defaultZone: http://127.0.0.1:10086/eureka,http://127.0.0.1:10087/eureka
为了方便上课和后面内容的修改，在测试完上述配置后可以再次改回单个eureka server的方式。
配置eureka客户端user-service的注册、续约等配置项。配置eureka客户端consumer-demo的获取服务间隔时间；了解失效剔除和组我保护
① Eureka客户端工程
○ user-service 服务提供
● 服务地址使用ip方式
● 续约
○ consumer-demo 服务消费
● 获取服务地址的频率
② Eureka服务端工程 eureka-server
○ 失效剔除
○ 自我保护
5.4.3. Eureka客户端
服务提供者要向EurekaServer注册服务，并且完成服务续约等工作。
服务注册
服务提供者在启动时，会检测配置属性中的： eureka.client.register-with-erueka=true 参数是否正确，事实上默认就是true。如果值确实为true，则会向EurekaServer发起一个Rest请求，并携带自己的元数据信息，EurekaServer会把这些信息保存到一个双层Map结构中。
-
第一层Map的Key就是服务id，一般是配置中的
spring.application.name属性 -
第二层Map的key是服务的实例id。一般host+ serviceId + port，例如：
localhost:user-service:8081 -
值则是服务的实例对象，也就是说一个服务，可以同时启动多个不同实例，形成集群。
默认注册时使用的是主机名或者localhost，如果想用ip进行注册，可以在user-service 中添加配置如下：
instance:
更倾向使用ip地址而不是host名
prefer-ip-address: true
IP地址
ip-address: 127.0.0.1
修改完后先后重启user-service 和consumer-demo ；在调用服务的时候就已经变成ip地址；需要注意的是：不是在eureka中的控制台服务实例状态显示。
服务续约
在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉EurekaServer：“我还活着”。这个我们称为服务的续约（renew）；
有两个重要参数可以修改服务续约的行为；可以在 user-service 中添加如下配置项：
eureka:
instance:
续约间隔，默认30秒
lease-renewal-interval-in-seconds: 30
服务失效时间，默认90秒
lease-expiration-duration-in-seconds: 90
-
lease-renewal-interval-in-seconds：服务续约(renew)的间隔，默认为30秒
-
lease-expiration-duration-in-seconds：服务失效时间，默认值90秒
也就是说，默认情况下每隔30秒服务会向注册中心发送一次心跳，证明自己还活着。如果超过90秒没有发送心跳，EurekaServer就会认为该服务宕机，会定时（eureka.server.eviction-interval-timer-in-ms设定的时间）从服务列表中移除，这两个值在生产环境不要修改，默认即可。
获取服务列表
当服务消费者启动时，会检测eureka.client.fetch-registry=true 参数的值，如果为true，则会从EurekaServer服务的列表拉取只读备份，然后缓存在本地。并且每隔30秒会重新拉取并更新数据。可以在consumer-demo项目中通过下面的参数来修改
eureka:
client:
registry-fetch-interval-seconds: 30
5.4.5. 失效剔除和自我保护
如下的配置都是在Eureka Server服务端进行：
服务下线
当服务进行正常关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心：“我要下线了”。服务中心接受到请求之后，将该服务置为下线状态。
失效剔除
有时我们的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作，而服务注册中心并未收到“服务下线”的请求。相对于服务提供者的“服务续约”操作，服务注册中心在启动时会创建一个定时任务，默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除，这个操作被称为失效剔除。
可以通过eureka.server.eviction-interval-timer-in-ms 参数对其进行修改，单位是毫秒。
自我保护
我们关停一个服务，很可能会在Eureka面板看到一条警告：
这是触发了Eureka的自我保护机制。当服务未按时进行心跳续约时，Eureka会统计服务实例最近15分钟心跳续约的比例是否低于了85%。在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka在这段时间内不会剔除任何服务实例，直到网络恢复正常。生产环境下这很有效，保证了大多数服务依然可用，不过也有可能获取到失败的服务实例，因此服务调用者必须做好服务的失败容错。
可以通过下面的配置来关停自我保护：
eureka:
server:
enable-self-preservation: false # 关闭自我保护模式（缺省为打开）
=========================================================================
在刚才的案例中，我们启动了一个user-service ，然后通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问。
但是实际环境中，往往会开启很多个user-service 的集群。此时获取的服务列表中就会有多个，到底该访问哪一个呢？
一般这种情况下就需要编写负载均衡算法，在多个实例列表中进行选择。
不过Eureka中已经集成了负载均衡组件：Ribbon，简单修改代码即可使用。
什么是Ribbon：
接下来，我们就来使用Ribbon实现负载均衡。
首先我们配置启动两个user-service 实例，一个9091，一个9092。
Eureka监控面板：
因为Eureka中已经集成了Ribbon，所以我们无需引入新的依赖。
直接修改 consumer-demo\src\main\java\com\itheima\consumer\ConsumerApplication.java
在RestTemplate的配置方法上添加@LoadBalanced 注解：
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}
修改consumer-demo\src\main\java\com\itheima\consumer\controller\ConsumerController.java 调用方式，不再手动获取ip和端口，而是直接通过服务名称调用；
@GetMapping(“{id}”)
public User queryById(@PathVariable(“id”) Long id){
String url=“http://user-service/user/”+id;
User user=restTemplate.getForObject(url,User.class);
return user;
}
访问页面，查看结果；并可以在9091和9092的控制台查看执行情况：
了解：Ribbon默认的负载均衡策略是轮询。SpringBoot也帮提供了修改负载均衡规则的配置入口在consumerdemo的配置文件中添加如下，就变成随机的了：
user-service:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
格式是： {服务名称}.ribbon.NFLoadBalancerRuleClassName
为什么只输入了service名称就可以访问了呢？之前还要获取ip和端口。
显然是有组件根据service名称，获取到了服务实例的ip和端口。因为consumer-demo 使用的是RestTemplate，spring的负载均衡自动配置类LoadBalancerAutoConfiguration.LoadBalancerInterceptorConfig 会自动配置负载均衡拦截器（在spring-cloud-commons-**.jar包中的spring.factories中定义的自动配置类）， 它就是LoadBalancerInterceptor ，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。
我们进行源码跟踪：
继续跟入execute方法：发现获取了9092端口的服务
再跟下一次，发现获取的是9091、9092之间切换：
多次访问consumer-demo 的请求地址；然后跟进代码，发现其果然实现了负载均衡。
=========================================================================
Hystrix 在英文里面的意思是 豪猪，它的logo 看下面的图是一头豪猪，它在微服务系统中是一款提供保护机制的组
件，和eureka一样也是由netflix公司开发。
主页：https://github.com/Netflix/Hystrix/
那么Hystrix的作用是什么呢？具体要保护什么呢？
Hystrix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。
微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：
如图，一次业务请求，需要调用A、P、H、I四个务，这四个服务又可能调用其它服务。
如果此时，某个服务出现异常：
例如： 微服务I 发生异常，请求阻塞，用户请求就不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：
服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。
这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。 此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。
Hystrix解决雪崩问题的手段主要是服务降级，包括：
-线程隔离
- 服务熔断
7.3.1. 原理
线程隔离示意图：
解读：
-
Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加速失败判定时间。
-
用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理，什么是服务降级？
服务降级：优先保证核心服务，而非核心服务不可用或弱可用。
用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息） 。
服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它服务没有响应。
触发Hystrix服务降级的情况：
-
线程池已满
-
请求超时
7.3.2. 动手实践
- 引入依赖
在consumer-demo 消费端系统的pom.xml文件添加如下依赖：
org.springframework.cloud
spring-cloud-starter-netflix-hystrix
- 开启熔断
在启动类ConsumerApplication 上添加注解：@EnableCircuitBreaker
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ConsumerApplication {
// …
}
可以看到，我们类上的注解越来越多，在微服务中，经常会引入上面的三个注解，于是Spring就提供了一个组合注解：@SpringCloudApplication
因此，我们可以使用这个组合注解来代替之前的3个注解。
@SpringCloudApplication
public class ConsumerApplication {
// …
}
- 编写降级逻辑
当目标服务的调用出现故障，我们希望快速失败，给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑，要使用HystrixCommand来完成。
改造consumer-demo\src\main\java\com\itheima\consumer\controller\ConsumerController.java 处理器类，如下：
package com.itheima.consumer.controller;
import com.itheima.consumer.pojo.User;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.client.discovery.DiscoveryClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;
import java.util.List;
@RestController
@RequestMapping(“/consumer”)
@Slf4j
public class ConsumerController {
@Autowired
private RestTemplate restTemplate;
@Autowired
private DiscoveryClient discoveryClient;
@GetMapping(“{id}”)
@HystrixCommand(fallbackMethod = “queryByIdFallback”)
public String queryById(@PathVariable Long id) {
String url = “http://localhost:9091/user/” + id;
//获取eureka中注册的user-service实例列表
/*List serviceInstanceList =
discoveryClient.getInstances(“user-service”);
ServiceInstance serviceInstance = serviceInstanceList.get(0);
url = “http://” + serviceInstance.getHost() + “:” + serviceInstance.getPort()
- “/user/” + id;*/
url = “http://user-service/user/” + id;
return restTemplate.getForObject(url, String.class);
}
public String queryByIdFallback(Long id) {
log.error(“查询用户信息失败。id：{}”, id);
return “对不起，网络太拥挤了！”;
}
}
*/
要注意；因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。
失败逻辑中返回User对象没有太大意义，一般会返回友好提示。所以把queryById的方法改造为返回String，反正也是Json数据。这样失败逻辑中返回一个错误说明，会比较方便。
说明：
@HystrixCommand(fallbackMethod = “queryByIdFallBack”)：用来声明一个降级逻辑的方法
测试：
当user-service 正常提供服务时，访问与以前一致。但是当将user-service 停机时，会发现页面返回了降级处理
信息：
- 默认的Fallback
刚才把fallback写在了某个业务方法上，如果这样的方法很多，那岂不是要写很多。所以可以把Fallback配置加在类上，实现默认fallback；
再次改造 consumer-demo\src\main\java\com\itheima\consumer\controller\ConsumerController.java
package com.itheima.consumer.controller;
import com.itheima.consumer.pojo.User;
import com.netflix.hystrix.contrib.javanica.annotation.DefaultProperties;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.client.discovery.DiscoveryClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;
import java.util.List;
@RestController
@RequestMapping(“/consumer”)
@Slf4j
@DefaultProperties(defaultFallback = “defaultFallback”)
public class ConsumerController {
@Autowired
private RestTemplate restTemplate;
@Autowired
private DiscoveryClient discoveryClient;
@GetMapping(“{id}”)
//@HystrixCommand(fallbackMethod = “queryByIdFallback”)
@HystrixCommand
public String queryById(@PathVariable Long id) {
String url = “http://localhost:9091/user/” + id;
//获取eureka中注册的user-service实例列表
/*List serviceInstanceList =
discoveryClient.getInstances(“user-service”);
ServiceInstance serviceInstance = serviceInstanceList.get(0);
url = “http://” + serviceInstance.getHost() + “:” + serviceInstance.getPort()
- “/user/” + id;*/
url = “http://user-service/user/” + id;
return restTemplate.getForObject(url, String.class);
}
public String queryByIdFallback(Long id) {
log.error(“查询用户信息失败。id：{}”, id);
return “对不起，网络太拥挤了！”;
}
public String defaultFallback() {
return “默认提示：对不起，网络太拥挤了！”;
}
}
@DefaultProperties(defaultFallback = “defaultFallBack”)：在类上指明统一的失败降级方法；该类中所有方法返回类型要与处理失败的方法的返回类型一致。
- 超时设置
在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystrix的默认超时时长为1，我们可以通过配置修
改这个值；修改 consumer-demo\src\main\resources\application.yml 添加如下配置：
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 2000
这个配置会作用于全局所有方法。为了方便复制到yml配置文件中，可以复制hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000 到yml文件中会自动格式化后再进行修改。为了触发超时，可以在user-service\src\main\java\com\itheima\user\service\UserService.java 的方法中休眠2秒；
@Service
public class UserService {
@Autowired
private UserMapper userMapper;
public User queryById(Long id) {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return userMapper.selectByPrimaryKey(id);
}
}
测试：
可以发现，请求的时长已经到了2s+，证明配置生效了。如果把修改时间修改到2秒以下，又可以正常访问。
7.4.1. 熔断原理
在服务熔断中，使用的熔断器，也叫断路器，其英文单词为：Circuit Breaker
熔断机制与家里使用的电路熔断原理类似；当如果电路发生短路的时候能立刻熔断电路，避免发生灾难。在分布式系统中应用服务熔断后；服务调用方可以自己进行判断哪些服务反应慢或存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。
Hystrix的服务熔断机制，可以实现弹性容错；当服务请求情况好转之后，可以自动重连。通过断路的方式，将后续请求直接拒绝，一段时间（默认5秒）之后允许部分请求通过，如果调用成功则回到断路器关闭状态，否则继续打开，拒绝请求的服务。
Hystrix的熔断状态机模型：
状态机有3个状态：
-
Closed：关闭状态（断路器关闭），所有请求都正常访问。
-
Open：打开状态（断路器打开），所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
-
Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进行休眠计时
7.4.2 动手实践
为了能够精确控制请求的成功或失败，在consumer-demo 的处理器业务方法中加入一段逻辑；
修改 consumer-demo\src\main\java\com\itheima\consumer\controller\ConsumerController.java
@GetMapping(“{id}”)
@HystrixCommand
public String queryById(@PathVariable(“id”) Long id){
if(id==1){
throw new RuntimeException(“太忙了”);
}
String url=“http://user-service/user/”+id;
String user=restTemplate.getForObject(url,String.class);
return user;
}
这样如果参数是id为1，一定失败，其它情况都成功。（不要忘了清空user-service中的休眠逻辑）
我们准备两个请求窗口：
-
一个请求：http://localhost:8080/consumer/1，注定失败
-
一个请求：http://localhost:8080/consumer/2，肯定成功
当我们疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会打开，一切请求都会被降级处理。
此时你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有20毫秒左右；因进入半开状态之后2是可以的。
不过，默认的熔断触发要求较高，休眠时间窗较短，为了测试方便，我们可以通过配置修改熔断策略：
配置熔断策略：
hystrix:
command:
default:
circuitBreaker:
errorThresholdPercentage: 50 # 触发熔断错误比例阈值，默认值50%
sleepWindowInMilliseconds: 10000 # 熔断后休眠时长，默认值5秒
requestVolumeThreshold: 10 # 熔断触发最小请求次数，默认值是20
execution:
isolation:
thread:
timeoutInMilliseconds: 2000 # 熔断超时设置，默认为1秒
为了方便复制上述配置，可以使用如下格式复制到yml文件中会自动格式化：
hystrix.command.default.circuitBreaker.requestVolumeThreshold=10
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=10000
hystrix.command.default.circuitBreaker.errorThresholdPercentage=50
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000
上述的配置项可以参考 HystrixCommandProperties 类中。
====================================================================
在前面的学习中，使用了Ribbon的负载均衡功能，大大简化了远程调用时的代码：
String url = “http://user-service/user/” + id;
User user = this.restTemplate.getForObject(url, User.class)
如果就学到这里，你可能以后需要编写类似的大量重复代码，格式基本相同，无非参数不一样。有没有更优雅的方式，来对这些代码再次优化呢？
这就是接下来要学的Feign的功能了。
Feign也叫伪装：
Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做。
项目主页：https://github.com/OpenFeign/feign
8.2.1. 导入依赖
在consumer-demo 项目的pom.xml 文件中添加如下依赖
org.springframework.cloud
spring-cloud-starter-openfeign
8.2.2. Feign的客户端
在consumer-demo 中编写如下Feign客户端接口类：
package com.itheima.consumer.client;
import com.itheima.consumer.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
@FeignClient(“user-service”)
public interface UserClient {
@GetMapping(“/user/{id}”)
User queryById(@PathVariable(“id”) Long id);
}
-
首先这是一个接口，Feign会通过动态代理，帮我们生成实现类。这点跟mybatis的mapper很像
-
@FeignClient ，声明这是一个Feign客户端，同时通过value 属性指定服务名称
-
接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果
-
@GetMapping中的/user，请不要忘记；因为Feign需要拼接可访问的地址
编写新的控制器类ConsumerFeignController ，使用UserClient访问：
package com.itheima.consumer.controller;
import com.itheima.consumer.client.UserClient;
import com.itheima.consumer.pojo.User;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping(“/cf”)
public class ConsumerFeignController {
@Autowired
private UserClient userClient;
@GetMapping(“/{id}”)
public User queryById(@PathVariable Long id) {
return userClient.queryById(id);
}
}
8.2.3. 开启Feign功能
在ConsumerApplication 启动类上，添加注解，开启Feign功能
package com.itheima.consumer;
import org.springframework.boot.SpringApplication;
import org.springframework.cloud.client.SpringCloudApplication;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.cloud.openfeign.EnableFeignClients;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;
/*@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker*/
@SpringCloudApplication
@EnableFeignClients//开启Feign功能
public class ConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsumerApplication.class, args);
}
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
}
Feign中已经自动集成了Ribbon负载均衡，因此不需要自己定义RestTemplate进行负载均衡的配置。
8.2.4. 启动测试
访问接口：http://localhost:8080/cf/2
正常获取到了结果。
Feign中本身已经集成了Ribbon依赖和自动配置：
因此不需要额外引入依赖，也不需要再注册RestTemplate 对象。
Fegin内置的ribbon默认设置了请求超时时长，默认是1000，我们可以通过手动配置来修改这个超时时长：
ribbon:
ReadTimeout: 2000 # 读取超时时长
ConnectTimeout: 1000 # 建立链接的超时时长
因为ribbon内部有重试机制，一旦超时，会自动重新发起请求。如果不希望重试，可以添加配置：
修改 consumer-demo\src\main\resources\application.yml 添加如下配置：
ribbon:
ConnectTimeout: 1000 # 连接超时时长
ReadTimeout: 2000 # 数据通信超时时长
MaxAutoRetries: 0 # 当前服务器的重试次数
MaxAutoRetriesNextServer: 0 # 重试多少次服务
OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试
重新给UserService的方法设置上线程沉睡时间2秒可以测试上述配置
Feign默认也有对Hystrix的集成：
只不过，默认情况下是关闭的。需要通过下面的参数来开启；修改 consumer-demo\src\main\resources\application.yml 添加如下配置：
feign:
hystrix:
enabled: true # 开启Feign的熔断功能
但是，Feign中的Fallback配置不像Ribbon中那样简单了。
- 首先，要定义一个类，实现刚才编写的UserFeignClient，作为fallback的处理类
package com.itheima.consumer.client.fallback;
import com.itheima.consumer.client.UserClient;
import com.itheima.consumer.pojo.User;
import org.springframework.stereotype.Component;
@Component
public class UserClientFallback implements UserClient {
@Override
public User queryById(Long id) {
User user = new User();
user.setId(id);
user.setName(“用户异常”);
return user;
}
}
- 然后在UserFeignClient中，指定刚才编写的实现类
@FeignClient(value = “user-service”, fallback = UserClientFallback.class)
public interface UserClient {
@GetMapping(“/user/{id}”)
User queryById(@PathVariable(“id”) Long id);
}
- 重启测试
重启启动 consumer-demo 并关闭user-service 服务，然后在页面访问：http://localhost:8080/cf/8
Spring Cloud Feign 支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。通过下面的参数即可开启请求与响应的压缩功能：
feign:
compression:
request:
enabled: true # 开启请求压缩
response:
enabled: true # 开启响应压缩
同时，我们也可以对请求的数据类型，以及触发压缩的大小下限进行设置：
feign:
compression:
request:
enabled: true # 开启请求压缩
mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
min-request-size: 2048 # 设置触发压缩的大小下限
注：上面的数据类型、压缩大小下限均为默认值。
前面讲过，通过logging.level.xx=debug 来设置日志级别。然而这个对Fegin客户端而言不会产生效果。因为@FeignClient 注解修改的客户端在被代理时，都会创建一个新的Fegin.Logger实例。我们需要额外指定这个日志的级别才可以。
- 在consumer-demo 的配置文件中设置com.itheima包下的日志级别都为debug修改 consumer-demo\src\main\resources\application.yml 添加如下配置：
logging:
level:
com.itheima: debug
- 在consumer-demo 编写FeignConfig配置类，定义日志级别
package com.itheima.consumer.config;
import feign.Logger;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class FeignConfig {
@Bean
Logger.Level feignLoggerLevel() {
//记录所有请求和响应的明细，包括头信息、请求体、元数据
return Logger.Level.FULL;
}
}
这里指定的Level级别是FULL，Feign支持4种级别：
① NONE：不记录任何日志信息，这是默认值。
② BASIC：仅记录请求的方法，URL以及响应状态码和执行时间
③ HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
④ FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。
- 在consumer-demo 的UserClient 接口类上的@FeignClient注解中指定配置类：
package com.itheima.consumer.client;
import com.itheima.consumer.client.fallback.UserClientFallback;
import com.itheima.consumer.config.FeignConfig;
import com.itheima.consumer.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
@FeignClient(value = “user-service”, fallback = UserClientFallback.class,
configuration = FeignConfig.class)
public interface UserClient {
@GetMapping(“/user/{id}”)
User queryById(@PathVariable Long id);
}
- 重启项目，访问：http://localhost:8080/cf/8 ；即可看到每次访问的日志：
=====================================================================================
-
Spring Cloud Gateway是Spring官网基于Spring 5.0、
-
Spring Boot 2.0、Project Reactor等技术开发的网关服
务。
Spring Cloud Gateway基于Filter链提供网关基本功能：安全、监控／埋点、限流等。
Spring Cloud Gateway为微服务架构提供简单、有效且统一的API路由管理方式。
Spring Cloud Gateway是替代Netflix Zuul的一套解决方案。Spring Cloud Gateway组件的核心是一系列的过滤器，通过这些过滤器可以将客户端发送的请求转发（路由）到对应的微服务。 Spring Cloud Gateway是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，从而加强安全保护。Spring Cloud Gateway本身也是一个微服务，需要注册到Eureka服务注册中心。
网关的核心功能是：过滤和路由
不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都可经过网关，然后再由
网关来实现 鉴权、动态路由等等操作。Gateway就是我们服务的统一入口。
-
路由（route） 路由信息的组成：由一个ID、一个目的URL、一组断言工厂、一组Filter组成。如果路由断言为真，说明请求URL和配置路由匹配。
-
断言（Predicate） Spring Cloud Gateway中的断言函数输入类型是Spring 5.0框架中的ServerWebExchange。Spring Cloud Gateway的断言函数允许开发者去定义匹配来自于Http Request中的任何信息比如请求头和参数。
-
过滤器（Filter） 一个标准的Spring WebFilter。 Spring Cloud Gateway中的Filter分为两种类型的Filter，分别是Gateway Filter和Global Filter。过滤器Filter将会对请求和响应进行修改处理。
9.4.1. 新建工程
填写基本信息：
打开 heima-springcloud\heima-gateway\pom.xml 文件修改为如下：
<?xml version="1.0" encoding="UTF-8"?><project xmlns=“http://maven.apache.org/POM/4.0.0”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
heima-springcloud
com.itheima
1.0-SNAPSHOT
4.0.0
com.itheima
heima-gateway
org.springframework.cloud
spring-cloud-starter-gateway
org.springframework.cloud
spring-cloud-starter-netflix-eureka-client
9.4.2. 编写启动类
在heima-gateway中创建com.itheima.gateway.GatewayApplication 启动类
package com.itheima.gateway;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
@SpringBootApplication
@EnableDiscoveryClient
public class GatewayApplication {
public static void main(String[] args) {
SpringApplication.run(GatewayApplication.class, args);
}
}
9.4.3 编写配置
创建heima-gateway\src\main\resources\application.yml 文件，内容如下：
server:
port: 10010
spring:
application:
name: api-gateway
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
prefer-ip-address: true
9.4.4. 编写路由规则
需要用网关来代理user-service 服务，先看一下控制面板中的服务状态：
-
ip为：127.0.0.1
-
端口为：9091
修改heima-gateway\src\main\resources\application.yml 文件为：
server:
port: 10010
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
路由id，可以随意写
- id: user-service-route
代理的服务地址
uri: http://127.0.0.1:9091
路由断言，可以配置映射路径
predicates:
- Path=/user/**
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
prefer-ip-address: true
将符合Path 规则的一切请求，都代理到 uri 参数指定的地址
本例中，我们将路径中包含有 /user/** 开头的请求，代理到http://127.0.0.1:9091
9.4.5. 启动测试
访问的路径中需要加上配置规则的映射路径，我们访问：http://localhost:10010/user/8
在刚才的路由规则中，把路径对应的服务地址写死了！如果同一服务有多个实例的话，这样做显然不合理。
应该根据服务的名称，去Eureka注册中心查找 服务对应的所有实例列表，然后进行动态路由！
9.5.1 修改映射配置，通过服务名称获取
因为已经配置了Eureka客户端，可以从Eureka获取服务的地址信息。
修改heima-gateway\src\main\resources\application.yml 文件如下：
server:
port: 10010
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
路由id，可以随意写
- id: user-service-route
代理的服务地址；lb表示从eureka中获取具体服务
uri: lb://user-service
路由断言，可以配置映射路径
predicates:
- Path=/user/**
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
prefer-ip-address: true
路由配置中uri所用的协议为lb时（以uri: lb://user-service为例），gateway将使用 LoadBalancerClient把user-service通过eureka解析为实际的主机和端口，并进行ribbon负载均衡。
9.5.2. 启动测试
再次启动 heima-gateway ，这次gateway进行代理时，会利用Ribbon进行负载均衡访问：http://localhost:10010/user/8
日志中可以看到使用了负载均衡器：
9.6.1. 添加前缀
在gateway中可以通过配置路由的过滤器PrefixPath，实现映射路径中地址的添加；
修改heima-gateway\src\main\resources\application.yml 文件：
server:
port: 10010
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
路由id，可以随意写
- id: user-service-route
代理的服务地址；lb表示从eureka中获取具体服务
uri: lb://user-service
路由断言，可以配置映射路径
predicates:
- Path=/**
filters:
添加请求路径的前缀
- PrefixPath=/user
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
prefer-ip-address: true
通过PrefixPath=/xxx 来指定了路由要添加的前缀。
也就是：
-
PrefixPath=/user http://localhost:10010/ --》http://localhost:9091/user/8
-
PrefixPath=/user/abc http://localhost:10010/8 --》http://localhost:9091/user/abc/8
以此类推。
9.6.2. 去除前缀
在gateway中可以通过配置路由的过滤器StripPrefix，实现映射路径中地址的去除；
修改heima-gateway\src\main\resources\application.yml 文件：
server:
port: 10010
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
路由id，可以随意写
- id: user-service-route
代理的服务地址；lb表示从eureka中获取具体服务
uri: lb://user-service
路由断言，可以配置映射路径
predicates:
- Path=/api/user/**
filters:
表示过滤1个路径，2表示两个路径，以此类推
- StripPrefix=1
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
prefer-ip-address: true
通过StripPrefix=1 来指定了路由要去掉的前缀个数。如：路径/api/user/1 将会被代理到/user/1 。
也就是：
-
StripPrefix=1 http://localhost:10010/api/user/8 --》http://localhost:9091/user/8
-
StripPrefix=2 http://localhost:10010/api/user/8 --》http://localhost:9091/8
以此类推。
9.7.1. 简介
Gateway作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作往往是通过网关提供的过滤器来实现的。前面的 路由前缀 章节中的功能也是使用过滤器实现的。
- Gateway自带过滤器有几十个，常见自带过滤器有：
| 过滤器名称 | 说明 |
| — | — |
| AddRequestHeader | 对匹配上的请求加上Header |
| AddRequestParameters | 对匹配上的请求路由添加参数 |
| AddResponseHeader | 对从网关返回的响应添加Header |
| StripPrefix | 对匹配上的请求路径去除前缀 |
详细的说明在官网链接.
- 配置全局默认过滤器
这些自带的过滤器可以和使用 路由前缀 章节中的用法类似，也可以将这些过滤器配置成不只是针对某个路由；而是可以对所有路由生效，也就是配置默认过滤器：
了解如下：
server:
port: 10010
spring:
application:
name: api-gateway
cloud:
gateway:
默认过滤器，对所有路由生效
default-filters:
响应头过滤器，对输出的响应设置其头部属性名称为X-Response-Default-MyName，值为itcast；如果有多个参数多则重写一行设置不同的参数
- AddResponseHeader=X-Response-Default-MyName, itcast
routes:
路由id，可以随意写
- id: user-service-route
代理的服务地址；lb表示从eureka中获取具体服务
uri: lb://user-service
路由断言，可以配置映射路径
predicates:
- Path=/api/user/**
filters:
表示过滤1个路径，2表示两个路径，以此类推
- StripPrefix=1
上述配置后，再访问 http://localhost:10010/api/user/8 的话；那么可以从其响应中查看到如下信息：
- 过滤器类型：Gateway实现方式上，有两种过滤器；
-
局部过滤器：通过spring.cloud.gateway.routes.filters 配置在具体路由下，只作用在当前路由上；自带的过滤器都可以配置或者自定义按照自带过滤器的方式。如果配置spring.cloud.gateway.default-filters 上会对所有路由生效也算是全局的过滤器；但是这些过滤器的实现上都是要实现GatewayFilterFactory接口。
-
全局过滤器：不需要在配置文件中配置，作用在所有的路由上；实现 GlobalFilter 接口即可。
9.7.2. 执行生命周期
Spring Cloud Gateway 的 Filter 的生命周期也类似Spring MVC的拦截器有两个：“pre” 和 “post”。“pre”和 “post” 分别会在请求被执行前调用和被执行后调用。
这里的 pre 和 post 可以通过过滤器的GatewayFilterChain 执行filter方法前后来实现。
9.7.3. 使用场景
常见的应用场景如下：
-
请求鉴权：一般GatewayFilterChain 执行filter方法前，如果发现没有访问权限，直接就返回空。
-
异常处理：一般GatewayFilterChain 执行filter方法后，记录异常并返回。
-
服务调用时长统计： GatewayFilterChain 执行filter方法前后根据时间统计。
9.8.1. 自定义局部过滤器
需求：在application.yml中对某个路由配置过滤器，该过滤器可以在控制台输出配置文件中指定名称的请求参数的值。
- 编写过滤器
在heima-gateway工程编写过滤器工厂类MyParamGatewayFilterFactory
package com.itheima.gateway.filter;
import org.springframework.cloud.gateway.filter.GatewayFilter;
import org.springframework.cloud.gateway.filter.factory.AbstractGatewayFilterFactory;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.stereotype.Component;
import java.util.Arrays;
import java.util.List;
@Component
public class MyParamGatewayFilterFactory extends
AbstractGatewayFilterFactory<MyParamGatewayFilterFactory.Config> {
public static final String PARAM_NAME = “param”;
public MyParamGatewayFilterFactory() {
super(Config.class);
}
@Override
public List shortcutFieldOrder() {
return Arrays.asList(PARAM_NAME);
}
@Override
public GatewayFilter apply(Config config) {
return (exchange, chain) -> {
ServerHttpRequest request = exchange.getRequest();
if (request.getQueryParams().containsKey(config.param)) {
request.getQueryParams().get(config.param)
.forEach(value -> System.out.printf("----------局部过滤器-----%s
= % s---- - ",
config.param, value));
}
return chain.filter(exchange);
};
}
public static class Config {
private String param;
public String getParam() {
return param;
}
public void setParam(String param) {
this.param = param;
}
}
}
- 修改配置文件
在heima-gateway工程修改heima-gateway\src\main\resources\application.yml 配置文件
server:
port: 10010
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
路由id，可以随意写
- id: user-service-route
代理的服务地址；lb表示从eureka中获取具体服务
uri: lb://user-service
路由断言，可以配置映射路径
predicates:
- Path=/api/user/**
filters:
表示过滤1个路径，2表示两个路径，以此类推
- StripPrefix=1
自定义过滤器
- MyParam=name
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
prefer-ip-address: true
注意：自定义过滤器的命名应该为：***GatewayFilterFactory
测试访问：http://localhost:10010/api/user/8?name=itcast 检查后台是否输出name和itcast；但是若访问
http://localhost:10010/api/user/8?name2=itcast 则是不会输出的。
9.8.2 自定义全局过滤器
需求：模拟一个登录的校验。基本逻辑：如果请求中有token参数，则认为请求有效，放行。
在heima-gateway工程编写全局过滤器类MyGlobalFilter
package com.itheima.gateway.filter;
import org.apache.commons.lang.StringUtils;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;
@Component
public class MyGlobalFilter implements GlobalFilter, Ordered {
@Override
public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) {
System.out.println("-----------------全局过滤器MyGlobalFilter-------------------
–");
String token = exchange.getRequest().getQueryParams().getFirst(“token”);
if (StringUtils.isBlank(token)) {
exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
return exchange.getResponse().setComplete();
}
return chain.filter(exchange);
}
@Override
public int getOrder() {
//值越小越先执行
return 1;
}
}
访问 http://localhost:10010/api/user/8
访问 http://localhost:10010/api/user/8?token=abc
Gateway中默认就已经集成了Ribbon负载均衡和Hystrix熔断机制
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 6000
ribbon:
ConnectTimeout: 1000
ReadTimeout: 2000
MaxAutoRetries: 0
MaxAutoRetriesNextServer: 0
Gateway跨域配置一般网关都是所有微服务的统一入口，必然在被调用的时候会出现跨域问题。
跨域：在js请求访问中，如果访问的地址与当前服务器的域名、ip或者端口号不一致则称为跨域请求。若不解决则不
能获取到对应地址的返回结果。
如：从在http://localhost:9090中的js访问 http://localhost:9000的数据，因为端口不同，所以也是跨域请求。
在访问Spring Cloud Gateway网关服务器的时候，出现跨域问题的话；可以在网关服务器中通过配置解决，允许哪些服务是可以跨域请求的；具体配置如下：
spring:
cloud:
gateway:
globalcors:
corsConfigurations:
‘[/**]’:
#allowedOrigins: * # 这种写法或者下面的都可以，*表示全部
allowedOrigins:
- “http://docs.spring.io”
allowedMethods:
- GET
上述配置表示：可以允许来自 http://docs.spring.io 的get请求方式获取服务数据。
allowedOrigins 指定允许访问的服务器地址，如：http://localhost:10000 也是可以的。
‘[/**]’ 表示对所有访问到网关服务器的请求地址
官网具体说明：[https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.1.1.RELEASE/multi/mul
ti__cors_configuration.html]( )
启动多个Gateway服务，自动注册到Eureka，形成集群。如果是服务内部访问，访问Gateway，自动负载均衡，没
问题。
但是，Gateway更多是外部访问，PC端、移动端等。它们无法通过Eureka进行负载均衡，那么该怎么办？
此时，可以使用其它的服务网关，来对Gateway进行代理。比如：Nginx
-
Gateway 作为整个应用的流量入口，接收所有的请求，如PC、移动端等，并且将不同的请求转发至不同的处理微服务模块，其作用可视为nginx；大部分情况下用作权限鉴定、服务端流量控制
-
Feign 则是将当前微服务的部分服务接口暴露出来，并且主要用于各个微服务之间的服务调用
10. Spring Cloud Config分布式配置中心
==========================================================================================
在分布式系统中，由于服务数量非常多，配置文件分散在不同的微服务项目中，管理不方便。为了方便配置文件集中管理，需要分布式配置中心组件。在Spring Cloud中，提供了Spring Cloud Config，它支持配置文件放在配置服务的本地，也支持放在远程Git仓库（GitHub、码云）。
使用Spring Cloud Config配置中心后的架构如下图：
配置中心本质上也是一个微服务，同样需要注册到Eureka服务注册中心！
10.2.1. 远程Git仓库
知名的Git远程仓库有国外的GitHub和国内的码云（gitee）；但是使用GitHub时，国内的用户经常遇到的问题是访问速度太慢，有时候还会出现无法连接的情况。如果希望体验更好一些，可以使用国内的Git托管服务——码云（gitee.com）。
与GitHub相比，码云也提供免费的Git仓库。此外，还集成了代码质量检测、项目演示等功能。对于团队协作开发，码云还提供了项目管理、代码托管、文档管理的服务。本章中使用的远程Git仓库是码云。
码云访问地址：https://gitee.com/
10.2.2. 创建远程仓库
首先要使用码云上的私有远程git仓库需要先注册帐号；请先自行访问网站并注册帐号，然后使用帐号登录码云控制台并创建公开仓库。
10.2.3. 创建配置文件
在新建的仓库中创建需要被统一配置管理的配置文件。
配置文件的命名方式：{application}-{profile}.yml 或 {application}-{profile}.properties
application为应用名称
profile用于区分开发环境，测试环境、生产环境等
如user-dev.yml，表示用户微服务开发环境下使用的配置文件。
这里将user-service工程的配置文件application.yml文件的内容复制作为user-dev.yml文件的内容，具体配置如下：
创建 user-dev.yml ；内容来自user-service\src\main\resources\application.yml （方便后面测试userservice项目的配置），可以如下：
server:
port: ${port:9091}
spring:
datasource:
driver-class-name: com.mysql.jdbc.Driver
url: jdbc:mysql://localhost:3306/springcloud
username: root
password: root
application:
#应用名
name: user-service
mybatis:
type-aliases-package: com.itheima.user.pojo
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
ip-address: 127.0.0.1
prefer-ip-address: true
lease-expiration-duration-in-seconds: 90
lease-renewal-interval-in-seconds: 30
创建完user-dev.yml配置文件之后，gitee中的仓库如下：
10.3.1. 创建工程
创建配置中心微服务工程：
添加依赖，修改config-server\pom.xml如下：
<project xmlns=“http://maven.apache.org/POM/4.0.0”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
heima-springcloud
com.itheima
1.0-SNAPSHOT
4.0.0
com.itheima
config-server
org.springframework.cloud
spring-cloud-starter-netflix-eureka-client
org.springframework.cloud
spring-cloud-config-server
10.3.2. 启动类
创建配置中心工程config-server的启动类；
configserver\src\main\java\com\itheima\config\ConfigServerApplication.java 如下：
package com.itheima.config;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}
10.3.3. 配置文件
创建配置中心工程config-server的配置文件；
config-server\src\main\resources\application.yml如下：
server:
port: 12000
spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: https://gitee.com/liaojianbin/heima-config.git
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
注意上述的 spring.cloud.config.server.git.uri 则是在码云创建的仓库地址；可修改为你自己创建的仓库地址
10.3.4. 启动测试
启动eureka注册中心和配置中心；然后访问http://localhost:12000/user-dev.yml ，查看能否输出在码云存储管理的user-dev.yml文件。并且可以在gitee上修改user-dev.yml然后刷新上述测试地址也能及时到最新数据。
前面已经完成了配置中心微服务的搭建，下面我们就需要改造一下用户微服务user-service ，配置文件信息不再由微服务项目提供，而是从配置中心获取。如下对user-service 工程进行改造。
10.4.1. 添加依赖
在user-service工程中的pom.xml文件中添加如下依赖：
org.springframework.cloud
spring-cloud-starter-config
2.1.1.RELEASE
10.4.2. 修改配置
-
删除
user-service工程的user-service\src\main\resources\application.yml文件（因为该文件从配置中心获取） -
创建
user-service工程user-service\src\main\resources\bootstrap.yml配置文件
spring:
cloud:
config:
与远程仓库中的配置文件的application保持一致
name: user
远程仓库中的配置文件的profile保持一致
profile: dev
远程仓库中的版本保持一致
label: master
discovery:
使用配置中心
enabled: true
配置中心服务id
service-id: config-server
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka**
user-service工程修改后结构：
bootstrap.yml文件也是Spring Boot的默认配置文件，而且其加载的时间相比于application.yml更早。
application.yml和bootstrap.yml虽然都是Spring Boot的默认配置文件，但是定位却不相同。bootstrap.yml可以理解成系统级别的一些参数配置，这些参数一般是不会变动的。application.yml 可以用来定义应用级别的参数，如果搭配 spring cloud config 使用，application.yml 里面定义的文件可以实现动态替换。
总结就是，bootstrap.yml文件相当于项目启动时的引导文件，内容相对固定。application.yml文件是微服务的一些常规配置参数，变化比较频繁。
10.4.3. 启动测试
启动注册中心eureka-server、配置中心config-server、用户服务user-service ，如果启动没有报错其实已经使用上配置中心内容，可以到注册中心查看，也可以检验user-service的服务。
====================================================================================
前面已经完成了将微服务中的配置文件集中存储在远程Git仓库，并且通过配置中心微服务从Git仓库拉取配置文件，当用户微服务启动时会连接配置中心获取配置信息从而启动用户微服务。
如果我们更新Git仓库中的配置文件，那用户微服务是否可以及时接收到新的配置信息并更新呢？
11.1.1. 修改远程Git配置
修改在码云上的user-dev.yml文件，添加一个属性test.name。
11.1.2. 修改UserController
修改user-service 工程中的处理器类；
user-service\src\main\java\com\itheima\user\controller\UserController.java如下：
package com.itheima.user.controller;
import com.itheima.user.pojo.User;
import com.itheima.user.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping(“/user”)
public class UserController {
@Autowired
private UserService userService;
@Value(“${test.name}”)
private String name;
@GetMapping(“/{id}”)
public User queryById(@PathVariable Long id) {
System.out.println("配置文件中的test.name = " + name);
return userService.queryById(id);
}
}
11.1.3. 测试
依次启动注册中心eureka-server、配置中心config-server 、用户服务user-service；然后修改Git仓库中的配置信息，访问用户微服务，查看输出内容。
结论：通过查看用户微服务控制台的输出结果可以发现，我们对于Git仓库中配置文件的修改并没有及时更新到用户微服务，只有重启用户微服务才能生效。
如果想在不重启微服务的情况下更新配置该如何实现呢? 可以使用Spring Cloud Bus来实现配置的自动更新。
需要注意的是Spring Cloud Bus底层是基于RabbitMQ实现的，默认使用本地的消息队列服务，所以需要提前启动本地RabbitMQ服务（安装RabbitMQ以后才有），如下：
Spring Cloud Bus是用轻量的消息代理将分布式的节点连接起来，可以用于广播配置文件的更改或者服务的监控管理。也就是消息总线可以为微服务做监控，也可以实现应用程序之间相互通信。 Spring Cloud Bus可选的消息代理有RabbitMQ和Kafka。
使用了Bus之后：
- 在config-server 项目的pom.xml文件中加入Spring Cloud Bus相关依赖
org.springframework.cloud
spring-cloud-bus
org.springframework.cloud
spring-cloud-stream-binder-rabbit
- 在config-server 项目修改application.yml文件如下：
server:
port: 12000
spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: https://gitee.com/liaojianbin/heima-config.git
rabbitmq的配置信息；如下配置的rabbit都是默认值，其实可以完全不配置
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
management:
endpoints:
web:
exposure:
暴露触发消息总线的地址
include: bus-refresh
- 在用户微服务
user-service项目的pom.xml中加入Spring Cloud Bus相关依赖
org.springframework.cloud
spring-cloud-bus
org.springframework.cloud
spring-cloud-stream-binder-rabbit
org.springframework.boot
spring-boot-starter-actuator
- 修改user-service 项目的bootstrap.yml如下：
spring:
cloud:
config:
与远程仓库中的配置文件的application保持一致
name: user
远程仓库中的配置文件的profile保持一致
profile: dev
远程仓库中的版本保持一致
label: master
discovery:
使用配置中心
enabled: true
配置中心服务id
service-id: config-server
rabbitmq的配置信息；如下配置的rabbit都是默认值，其实可以完全不配置
rabbitmq:
host: localhost
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）
总结
以上是字节二面的一些问题，面完之后其实挺后悔的，没有提前把各个知识点都复习到位。现在重新好好复习手上的面试大全资料（含JAVA、MySQL、算法、Redis、JVM、架构、中间件、RabbitMQ、设计模式、Spring等），现在起闭关修炼半个月，争取早日上岸！！！
下面给大家分享下我的面试大全资料
- 第一份是我的后端JAVA面试大全
后端JAVA面试大全
- 第二份是MySQL+Redis学习笔记+算法+JVM+JAVA核心知识整理
MySQL+Redis学习笔记算法+JVM+JAVA核心知识整理
- 第三份是Spring全家桶资料
MySQL+Redis学习笔记算法+JVM+JAVA核心知识整理
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
us简介
Spring Cloud Bus是用轻量的消息代理将分布式的节点连接起来，可以用于广播配置文件的更改或者服务的监控管理。也就是消息总线可以为微服务做监控，也可以实现应用程序之间相互通信。 Spring Cloud Bus可选的消息代理有RabbitMQ和Kafka。
使用了Bus之后：
- 在config-server 项目的pom.xml文件中加入Spring Cloud Bus相关依赖
org.springframework.cloud
spring-cloud-bus
org.springframework.cloud
spring-cloud-stream-binder-rabbit
- 在config-server 项目修改application.yml文件如下：
server:
port: 12000
spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: https://gitee.com/liaojianbin/heima-config.git
rabbitmq的配置信息；如下配置的rabbit都是默认值，其实可以完全不配置
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
management:
endpoints:
web:
exposure:
暴露触发消息总线的地址
include: bus-refresh
- 在用户微服务
user-service项目的pom.xml中加入Spring Cloud Bus相关依赖
org.springframework.cloud
spring-cloud-bus
org.springframework.cloud
spring-cloud-stream-binder-rabbit
org.springframework.boot
spring-boot-starter-actuator
- 修改user-service 项目的bootstrap.yml如下：
spring:
cloud:
config:
与远程仓库中的配置文件的application保持一致
name: user
远程仓库中的配置文件的profile保持一致
profile: dev
远程仓库中的版本保持一致
label: master
discovery:
使用配置中心
enabled: true
配置中心服务id
service-id: config-server
rabbitmq的配置信息；如下配置的rabbit都是默认值，其实可以完全不配置
rabbitmq:
host: localhost
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。[外链图片转存中…(img-yKSa7f1Z-1712633146876)]
[外链图片转存中…(img-2RmrTqGI-1712633146877)]
[外链图片转存中…(img-LAWr5n2x-1712633146877)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）
总结
以上是字节二面的一些问题，面完之后其实挺后悔的，没有提前把各个知识点都复习到位。现在重新好好复习手上的面试大全资料（含JAVA、MySQL、算法、Redis、JVM、架构、中间件、RabbitMQ、设计模式、Spring等），现在起闭关修炼半个月，争取早日上岸！！！
下面给大家分享下我的面试大全资料
- 第一份是我的后端JAVA面试大全
[外链图片转存中…(img-1tRIlF1J-1712633146877)]
后端JAVA面试大全
- 第二份是MySQL+Redis学习笔记+算法+JVM+JAVA核心知识整理
[外链图片转存中…(img-zCXPKYy0-1712633146877)]
MySQL+Redis学习笔记算法+JVM+JAVA核心知识整理
- 第三份是Spring全家桶资料
[外链图片转存中…(img-4YL297ZI-1712633146878)]
MySQL+Redis学习笔记算法+JVM+JAVA核心知识整理
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
扫一扫
1187
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
