复习笔记2-spring

什么是 Spring 框架

Spring 是一种轻量级开发框架，用来提高开发人员效率以及系统的可维护性，spring 的两大核心 IOC (控制反转)和 AOP (面向切面编程)，
重要模块如下：

Spring Core： 基础,可以说 Spring 其他所有的功能都需要依赖于该类库。主要提供 IoC 依赖注入功能。
Spring Aspects ： 该模块为与 AspectJ 的集成提供支持。
Spring AOP ：提供了面向切面的编程实现。
Spring JDBC : Java 数据库连接。
Spring JMS ：Java 消息服务。
Spring ORM : 用于支持Hibernate等ORM工具。
Spring Web : 为创建Web应用程序提供支持。
Spring Test : 提供了对 JUnit 和 TestNG 测试的支持。

AOP原理：既面向切面编程，就是提取公共部分，集中解决一些公共问题（例如事务处理、日志管理、权限控制等），降低模块间的耦合度
IOC原理：控制反转。在传统过程中，当某一个对象依赖于另外一个对象时，会由该对象去创建另外一个对象，有了ioc后，
		将创建过程交给IOC,由spring 创建 bean，从而只需给该对象注入即可

Spring AOP 和 AspectJ AOP 有什么区别

Spring AOP 属于运行时增强，而 AspectJ 是编译时增强。
Spring AOP 已经集成了 AspectJ ，AspectJ 功能更加强大，Spring AOP 更简单，切面比较少，两者性能差异不大。切面多时，选择 AspectJ ，它比Spring AOP 快很多。

Java JDK代理、CGLIB、AspectJ 代理分析比较

spring 的AOP 是基于动态代理实现：JDK 动态代理(默认)，CGLIB 动态代理（需要进行配置）
动态代理：每次运行时在内存中临时为对象生成一个 AOP 对象，这个 AOP 对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法
静态代理：框架在【编译时】生成代理类（class），也称为【编译时增强】，代表有 AspectJ

1. JDK 动态代理只能对【实现了接口的类】生成代理，而【不能针对类】，CGLIB 可对【未实现任何接口的类】代
理，CGLIB 动代是通过生成一个被代理类的子类来拦截被代理类的方法调用，因此不能代理声明为 final 类型的类和方法。
2. 效率：大部分情况都是 JDK 动态代理更优秀，随着 JDK 版本的升级，这个优势更加明显。
3. AOP 模块中，如果目标对象实现了接口，则采用 JDK 动态代理，否则采用 CGLIB 动态代理。

自定义注解（与 AOP 的搭配应用）

AspectJ：
连接点（Joinpoint）：要切的某个方法
切点（Pointcut）、引介（Introduction）、织入（Weaving）、
切面（Aspect）：是指连接点的集合可以形成。所有功能的总称叫切面。使用 @AspectJ 注解来实现
增强（Advice）：包括BeforeAdvice、AfterReturningAdvice、ThrowsAdvice等

Spring 通知（Advice）类型
（1）前置通知（Before Advice）：在连接点（Join point）之前执行的通知。
（2）后置通知（After Advice）：当连接点退出的时候执行的通知（不论是正常返回还是异常退出）。 
（3）环绕通知（Around Advice）：包围一个连接点的通知，这是最强大的一种通知类型。 环绕通知可以在方法调用前后完成自定义的行为。它也可以选择是否继续执行连接点或直接返回它们自己的返回值或抛出异常来结束执行。
（4）返回后通知（AfterReturning Advice）：在连接点正常完成后执行的通知（如果连接点抛出异常，则不执行）
（5）抛出异常后通知（AfterThrowing advice）：在方法抛出异常退出时执行的通知

自定义注解实现日志记录

1、什么时候使用该注解，我们定义为运行时；
2、注解用于什么地方，我们定义为作用于方法上；
3、注解是否将包含在 JavaDoc 中；
4、注解名为 WebLog;
5、定义一个属性，默认为空字符串

切面方法的执行顺序

类名上可用 @Order(i) 注解来指定优先级，i 值越小，优先级则越高

@Pointcut(“execution (@com.test.annotation.AutoLog * *(…))”)
@Pointcut 一般是切某些目录下类中的所以方法，自定义注解非必须，AOP 可以单独用，用来无差别记录所有方法的出入参数

1.自定义注解
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface AutoLog {
    String tag();
    LogLevel level() default LogLevel.VERBOSE;
}

2.定义切面和切入点
@Aspect
public class LogAspect {

    // 切入点，添加了AutoLog注解的所有方法体内
    @Pointcut("execution (@com.test.annotation.AutoLog * *(..))")
    public void logMethodExecute() {
    }
    
    /**
     * 环绕增强，相当于MethodInterceptor
     */
    @Around("logMethodExecute()")
    public Object doAround(ProceedingJoinPoint joinPoint) throws Throwable {
	//记录日志
    }
}
3.使用

SpringBoot之常用注解

1、@SpringBootApplication
  SpringBoot 最核心的注解，用在启动类上，
 是 @Configuration, @EnableAutoConfiguration, @ComponentScan 三个注解的组合。

2、@EnableAutoConfiguration
允许 SpringBoot 自动配置，使用后，SpringBoot 能根据当前类路径下的包或者类来配置 Spring Bean。
如：当前类路径下有 Mybatis 这个 JAR 包，MybatisAutoConfiguration 注解就能根据相关参数来配置 Mybatis 的各个 Spring Bean。

@EnableAutoConfiguration 实现的关键在于引入了 AutoConfigurationImportSelector，核心逻辑为
selectImports 方法，逻辑大致如下：
　●　从配置文件META-INF/spring.factories 加载所有可能用到的自动配置类；
　●　去重，并将exclude 和 excludeName 属性携带的类排除；
　●　过滤，将满足条件（@Conditional）的自动配置类返回；

3、@Configuration
	用于定义配置类，指出该类是 Bean 配置的信息源，相当于传统的 xml 配置文件，一般加主类上。

4、@ComponentScan
	注解装配标识了 @Controller，@Service，@Repository，@Component 注解的类到spring容器中。

5、@Repository
	@Repository 注解接口，是 Spring 提供的，@mapper 是mybatis提供的，通过 mapper.xml 里面的namespace 属性对应相关的 mapper 类

6、@Service

7、@RestController
	是REST风格的控制器；它是@Controller和@ResponseBody的合集。

8、@ResponseBody
	表示返回json数据

9、@Component
	泛指组件，当组件不好归类的时候，我们可以使用这个注解进行标注。

10、@Bean
	放在方法的上面，意思是产生一个bean,并交给spring管理。

11、@AutoWired
	byType方式。把配置好的Bean拿来用，完成属性、方法的组装，它可以对类成员变量、方法及构造函数进行标注，完成自动装配的工作。

12、@Qualifier
	当有多个同一类型的 Bean时，可以用 @Qualifier("name")来指定。与@Autowired配合使用

13、@Resource(name="name",type="type")
	没有括号内内容的话，默认 byName。与@Autowired干类似的事。

14、@RequestMapping
	用来处理请求地址映射的注解

15、@RequestParam
	获取?后的参数
	
16.@PathVariable
	获取路径上的参数

17、@ConfigurationProperties
	properties 文件映射到实体 bean 中

Spring Boot

Spring Boot 是 Spring 框架的扩展，它消除了设置 Spring 应用程序所需的 XML 配置，约定大于配置

1、内嵌 tomcat 容器，可以直接打成 jar 包，通过 java -jar xx.jar 运行项目。
2、提供 spring-boot-starter-xxx pom 系列，简化 maven 的依赖加载，减少依赖冲突的发生。

springboot自动装配原理

@SpringBootApplication 由三个主要的注解构成：

@EnableAutoConfiguration：启用 SpringBoot 的自动配置机制
@Configuration：允许在上下文中注册额外的 bean 或导入其他配置类
@ComponentScan： 扫描被 @Component、@Service、@Controller 等注解的 bean，默认会扫描启动类所在的包下所有的类 

@EnableAutoConfiguration 注意：spring boot 在整个的启动过程中，在类路径的META-INF/spring.factories 文件中找到 EnableAutoConfiguration 对应的所有的自动配置类，通过反射实例化为对象加载到spring容器中

【spring.factories文件在spring-boot-auto-configuration.jar包内，且是以 key-value 键值对的形式存储，其中有一个 key为EnableAutoConfiguration，它对应的 value值都是一个个以 AutoConfiguration结尾来命名的 xxxAutoConfiguration 自动配置类】

前面加载的所有自动配置类并不是都生效的，每一个xxxAutoConfiguration 自动配置类都是在某些特定的条件之下才会生效。通过@ConditionOnxxx 注解实现的

常见的 @ConditionOnxxx 注解有以下几种：

@ConditionalOnBean：当容器里存在指定bean的条件下。
@ConditionalOnMissingBean：当容器里不存在指定bean的条件下。
@ConditionalOnClass：当类路径下有指定类的条件下。
@ConditionalOnMissingClass：当类路径下不存在指定类的条件下。
@ConditionalOnProperty：指定的属性是否有指定的值，比如

springboot 和 springcloud

1、springboot 是一个快速开发框架，简化spring 开发，简单配置即可开发，约定大于配置
2、是一整套基于 Spring Boot 的微服务解决方案。它为开发者提供了很多工具，用于快速构建分布式系统的一些
通用模式，例如：配置管理、注册中心、服务发现、限流、网关、链路追踪等。

Spring Cloud

是一整套基于Spring Boot 的微服务解决方案。它为开发者提供了很多工具，用于快速构建分布式系统的一些通用模式，例如：配置管理、注册中心、服务发现、限流、网关、链路追踪等。

微服务和分布式

微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难

分布式和集群

 分布式：一个业务分拆多个子业务，部署在不同的服务器上
 集群：同一个业务，部署在多个服务器上

@RestController vs @Controller

@RestController 返回 JSON 或 XML 形式数据
@Controller 不加 @ResponseBody 的话一般使用在要返回一个视图的情况，属于传统的 Spring MVC 的应用，前后端不分离
@Controller +@ResponseBody 返回 JSON 或 XML 形式数据

Spring 中的 bean 的作用域

singleton : Spring 中的 bean 默认都是单例的。
prototype : 每次请求都会创建一个新的 bean 实例。
request : 每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP request内有效。
session : 每一次HTTP请求都会产生一个新的 bean，该bean仅在当前 HTTP session 内有效。
global-session： 全局session作用域，仅仅在基于 portlet 的 web 应用中才有意义，Spring5 已经没有了

Spring 中的单例 bean 的线程安全问题

单例存在安全问题的。多线程操作这个对象的成员变量可能存在线程安全问题。
我们常用的 Controller、Service、Dao 这些 Bean 是无状态的。无状态的 Bean 不能保存数据，因此是线程安全的。

常见的有 2 种解决办法：
在类中定义一个 ThreadLocal 成员变量，将需要的可变成员变量保存在  ThreadLocal 中（推荐的一种方式）。
改变 Bean 的作用域为 “prototype”：每次请求都会创建一个新的 bean 实例，自然不会存在线程安全问题。

@Component 和 @Bean 的区别

@Component 注解作用于类，而 @Bean 注解作用于方法。
@Component通常是通过类路径扫描来自动侦测以及自动装配到Spring容器中（配合 @ComponentScan 注解定义要扫描的路径从）。@Bean 注解通常是我们在标有该注解的方法中定义产生这个 bean,@Bean告诉了Spring这是某个类的示例，当我需要用它的时候还给我。

将一个类声明为Spring的 bean 的注解

 @Controller  @Service @Repository   @Component   

spring 框架中的工厂有哪些及区别（ beanFactory 和 applicationContext ）

beanFactory 是 spring 早期创建 bean 对象工厂接口
applicationContext 接口实现了 beanFactory 接口

beanFactory 采取的延迟加载,第一次 getBean 时才会初始化Bean
applicationContext是加载完 applicationContext.xml  就创建了具体的 bean 实例(只对 BeanDefition 中描述是单例的 bean ,才进行恶汉模式创建）

applicationContext 接口常用实现类或子类
1. classpathXmlApplicationContext : 它是从类的根路径下加载配置文件,推荐使用这种
2. FileSystemXmlApplicationContext: 它是从磁盘上加载配置文件,配置文件可以在磁盘的任意位置
3. AnnotationConfigApplicationContext : 当我们使用注解配置容器对象时，需要使用此类来创建 spring 容器。它用来读取注解。

Spring 中的 bean 生命周期

Bean 容器找到配置文件中 Spring Bean 的定义。
Bean 容器利用 Java Reflection API 创建一个Bean的实例。
如果涉及到一些属性值 利用 set()方法设置一些属性值。
如果 Bean 实现了 BeanNameAware 接口，调用 setBeanName()方法，传入Bean的名字。
如果 Bean 实现了 BeanClassLoaderAware 接口，调用 setBeanClassLoader()方法，传入 ClassLoader对象的实例。
与上面的类似，如果实现了其他 *.Aware接口，就调用相应的方法。
如果有和加载这个 Bean 的 Spring 容器相关的 BeanPostProcessor 对象，执行postProcessBeforeInitialization() 方法
如果Bean实现了InitializingBean接口，执行afterPropertiesSet()方法。
如果 Bean 在配置文件中的定义包含 init-method 属性，执行指定的方法。
如果有和加载这个 Bean的 Spring 容器相关的 BeanPostProcessor 对象，执行postProcessAfterInitialization() 方法
当要销毁 Bean 的时候，如果 Bean 实现了 DisposableBean 接口，执行 destroy() 方法。
当要销毁 Bean 的时候，如果 Bean 在配置文件中的定义包含 destroy-method 属性，执行指定的方法。

生命周期概括 4 阶段：实例化、属性赋值、初始化（前置处理后置处理等）、销毁

怎么理解 MVC 及工作原理

Model（模型）：数据模型，提供要展示的数据，数据模型：实体类（JavaBean），数据访问：JDBC，Hibernate等。
View（视图）：负责进行模型的展示，一般就是我们见到的用户界面，比如 JSP，Html 等
Controller（控制器）：接收用户请求，委托给模型进行处理，处理完毕后把返回的模型数据返回给视图，由视图负责展示

总结：控制器（controller）接受用户的输入并调用【模型】后返回【视图】view 给用户，控制器本身不输出任何东西和做任何处理。只接收请求并决定调用哪个模型构件去处理请求，再确定用哪个视图来显示返回的数据。

SpringMVC 工作原理

1.客户端（浏览器）发送请求，直接请求到 DispatcherServlet。
2.DispatcherServlet 根据请求信息调用 HandlerMapping，解析请求对应的 Handler。
3.解析到对应的 Handler（也就是我们平常说的 Controller 控制器）后，开始由 HandlerAdapter 适配器处理。
4.HandlerAdapter 会根据 Handler 来调用真正的处理器来处理请求，并处理相应的业务逻辑。
5.处理器处理完业务后，会返回一个 ModelAndView 对象，Model 是返回的数据对象，View 是个逻辑上的 View。
6.ViewResolver 会根据逻辑 View 查找实际的 View。
7.DispaterServlet 把返回的 Model 传给 View（视图渲染）。
8.把 View 返回给请求者（浏览器）

总结：客户端请求到前端处理器，【前端处理器】调用【处理器映射器】，再【调用处理器适配器】得到 ModelAndView 对象，
	该对象在交给【视图解析器】处理，最后前端处理器返回给浏览器

Spring 框架中用到的设计模式

java 有 23 种设计模

工厂设计模式 : Spring使用工厂模式通过 BeanFactory、ApplicationContext 创建 bean 对象。
代理设计模式 : Spring AOP 功能的实现。
单例设计模式 : Spring 中的 Bean 默认都是单例的。
模板方法模式 : Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。
包装器设计模式 : 我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。
观察者模式: Spring 事件驱动模型就是观察者模式很经典的一个应用。
适配器模式 :Spring AOP 的增强或通知(Advice)使用到了适配器模式、spring MVC 中也是用到了适配器模式适配Controller。
......

Spring 管理事务的方式

编程式事务：在代码中硬编码。(不推荐使用)
声明式事务：基于注解的声明式事务

Spring 事务中的隔离级别

TransactionDefinition 接口中定义了五个表示隔离级别的常量：
读未提交（Read uncommitted）、读已提交（Read committed）、可重复读（Repeatable read）、串行化（Serializable ）

TransactionDefinition.ISOLATION_DEFAULT: 使用后端数据库默认的隔离级别，Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别.
TransactionDefinition.ISOLATION_READ_UNCOMMITTED: 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读
TransactionDefinition.ISOLATION_READ_COMMITTED: 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生
TransactionDefinition.ISOLATION_REPEATABLE_READ: 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
TransactionDefinition.ISOLATION_SERIALIZABLE: 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

Spring 事务中事务传播行为

@Transactional 的默认传播行为：PROPAGATION.REQUIRED
支持当前事务的情况：

TransactionDefinition.PROPAGATION_REQUIRED： 如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
TransactionDefinition.PROPAGATION_SUPPORTS： 如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
TransactionDefinition.PROPAGATION_MANDATORY： 如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。（mandatory：强制性）

不支持当前事务的情况：

TransactionDefinition.PROPAGATION_REQUIRES_NEW： 创建一个新的事务，如果当前存在事务，则把当前事务挂起。
TransactionDefinition.PROPAGATION_NOT_SUPPORTED： 以非事务方式运行，如果当前存在事务，则把当前事务挂起。
TransactionDefinition.PROPAGATION_NEVER： 以非事务方式运行，如果当前存在事务，则抛出异常。

其他情况（嵌套事务）：

TransactionDefinition.PROPAGATION_NESTED： 如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

@Transactional(rollbackFor = Exception.class)

当 @Transactional 注解作用于类上时，该类的所有 public 方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义。如果类或者方法加了这个注解，那么这个类里面的方法抛出异常，就会回滚，数据库里面的数据也会回滚。

在 @Transactional 注解中如果不配置 rollbackFor 属性,那么事务只会在遇到 RuntimeException 的时候才会回滚,加上rollbackFor=Exception.class,可以让事务在遇到非运行时异常时也回滚。

如涉及多表的事务

@Transient

如果我们想让某个字段不被持久化，不被数据库存储用这个

springcloud

Spring Cloud 就是微服务系统架构的一站式解决方案，在平时我们构建微服务的过程中需要做如 服务发现注册 、配置中心 、消息总线 、负载均衡 、断路器 、数据监控 等操作

Eureka 服务发现框架
Ribbon 进程内负载均衡器
Open Feign 服务调用映射 （内置 Ribbon ）
Hystrix 服务降级熔断器
Zuul 微服务网关
Config 微服务统一配置中心
Bus 消息总线

服务发现Eureka

服务发现：
服务提供者： 
服务消费者： 
服务中介： 
服务注册 Register：
服务续约 Renew：
服务下线 Cancel：
服务剔除 Eviction

客户端向 Eureka 服务器发送服务续约，即心跳
消费者消费的时候，会获取服务地址之后，缓存在本地的JVM内存中，默认每30S更新一次服务调用地址。
注册中心发现一些服务提供者状态变动时（如down机）会向订阅者发布，去让他们更新服务列表缓存

负载均衡 Ribbon

运行在消费者端。工作原理就是 消费端 获取到了所有的服务列表之后，在其内部使用负载均衡算法，进行对多个系统的调用。
和 nginx 区别，Ribbon 在客户端计算，nginx 是自己算

负载均衡策略：
轮询策略：Ribbon 默认采用的策略。若经过一轮轮询没有找到可用的 provider，其最多轮询 10 轮。若最终还没有找到，则返回 null。
随机策略：从所有可用的 provider 中随机选择一个。
重试策略：先按照 RoundRobinRule 策略获取 provider，若获取失败，则在指定的时限内重试。默认的时限为 500 毫秒

Open Feign

微服务之间的调用可以用 RestTemplat ，但是用ip+端口就没有负载均衡了

1.
service-a 作为服务提供方有两个，只是端口不一样
restTemplate.getForObject("http://service-a/hi?id="+id, String.class);

2.
或者
@FeignClient(value = "eureka-client-provider")
public interface TestClient {
	@RequestMapping(value = "/hi")
    String hi();
 }

消费方Controller 里注入这个 TestClient 接口来调用

@Autowired
private RestTemplate restTemplate;
// 这里是提供者A的ip地址，但是如果使用了 Eureka 那么就应该是提供者A的名称
private static final String SERVICE_PROVIDER_A = "http://localhost:8081";

@PostMapping("/judge")
public boolean judge(@RequestBody Request request) {
    String url = SERVICE_PROVIDER_A + "/service1";
    return restTemplate.postForObject(url, request, Boolean.class);
}

OpenFeign 也是运行在消费者端的，直接内置了 Ribbon。

// 使用 @FeignClient 注解来指定提供者的名字
@FeignClient(value = "eureka-client-provider")
public interface TestClient {
    // 这里一定要注意需要使用的是提供者那端的请求相对路径，这里就相当于映射了
    @RequestMapping(value = "/provider/xxx",method = RequestMethod.POST)
    CommonResponse<List<Plan>> getPlans(@RequestBody planGetRequest request);
}

然后我们在 Controller 就可以像原来调用 Service 层代码一样调用它了。
@RestController
public class TestController {
    // 这里就相当于原来自动注入的 Service
    @Autowired
    private TestClient testClient;
    // controller 调用 service 层代码
    @RequestMapping(value = "/test", method = RequestMethod.POST)
    public CommonResponse<List<Plan>> get(@RequestBody planGetRequest request) {
        return testClient.getPlans(request);
    }
}

Hystrix之熔断和降级
Hystrix 的 后备处理 模式。你可以通过设置 fallbackMethod 来给一个方法设置备用的代码逻辑。当某个方法出现异常时，可以调用备用方法

// 指定了后备方法调用
@HystrixCommand(fallbackMethod = "getHystrixNews")
@GetMapping("/get/news")
public News getNews(@PathVariable("id") int id) {
    // 调用新闻系统的获取新闻api 代码逻辑省略
}
// 
public News getHystrixNews(@PathVariable("id") int id) {
    // 做服务降级
    // 返回当前人数太多，请稍后查看
}

微服务网关Zuul
统一入口、鉴权校验、动态路由
Zuul 中最关键的就是 路由和过滤器 了
统一前缀
这个很简单，就是我们可以在前面加一个统一的前缀，比如我们刚刚调用的是 localhost:9000/consumer1/studentInfo/update，这个时候我们在 yaml 配置文件中添加如下。

网关令牌桶限流：以一定 固定的速率 会往里面放令牌，请求过来先要从桶中获取令牌，如果没有获取到，那么这个请求就拒绝，如果获取到那么就放行。

zuul:
  prefix: /zuul
这样我们就需要通过 localhost:9000/zuul/consumer1/studentInfo/update 来进行访问了。

路由策略配置
你会发现前面的访问方式(直接使用服务名)，需要将微服务名称暴露给用户，会存在安全性问题。所以，可以自定义路径来替代微服务名称，即自定义路由策略。

路径屏蔽
Zuul 还可以指定屏蔽掉的路径 URI，即只要用户请求中包含指定的 URI 路径，那么该请求将无法访问到指定的服务。通过该方式可以限制用户的权限。

zuul:
  ignore-patterns: **/auto/**

过滤功能（路由前加个拦截器做前置处理），实现 限流，灰度发布，权限控制 等等。

配置中心