SpringCloud微服务技术实践与总结（基础篇）

1、认识微服务

1.1、单体架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。

单体架构的优缺点如下：

• 优点： 架构简单、部署成本低
• 缺点： 耦合度高（维护困难、升级困难）

1.2、分布式架构

分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。

分布式架构的优缺点：

• 优点： 降低服务耦合、有利于服务升级和拓展
• 缺点： 服务调用关系错综复杂

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

• 服务拆分的粒度如何界定？
• 服务之间如何调用？
• 服务的调用关系如何管理？

1.3、微服务

微服务的架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
• 自治：团队独立、技术独立、数据独立，独立部署和交付
• 面向服务：服务提供统一标准的接口，与语言和技术无关
• 隔离性强：服务调用需要做好隔离、容错、降级，避免出现级联问题
  
• 微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。

1.4、SpringCloud

• SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。
• SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。
  其中常见的组件包括：
  
  另外，SpringCloud底层是依赖于SpringBoot的，并且有版本的兼容关系，如下：
  
  下面使用各个组件来搭建各项服务模块，使用的版本是Hoxton.SR10，因此，可以对应的SpringBoot版本是2.3.x版本。

1.5、小总结

• 单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统
• 分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝
• 微服务：一种良好的分布式架构方案
  ① 优点：拆分粒度更小、服务更独立、耦合度更低
  ② 缺点：架构非常复杂，运维、监控、部署难度提高
• SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件

2、服务的搭建和拆分

2.1、服务拆分原则

微服务拆分时的几个原则：

• 不同微服务，不要重复开发相同业务
• 微服务数据独立，不要访问其它微服务的数据库
• 微服务可以将自己的业务暴露为接口，供其它微服务调用
  

2.2、具体实践

项目结构如下（该初始化项目见我分享的cloud-demo）：
cloud-demo：父工程，管理依赖

• order-service：订单微服务，负责订单相关业务
• user-service：用户微服务，负责用户相关业务

要求：

• 订单微服务和用户微服务都必须有各自的数据库，相互独立

• 订单服务和用户服务都对外暴露Restful的接口

• 订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户服务的数据库
  

• sql语句导入

USE `cloud_user`;

DROP TABLE IF EXISTS `tb_user`;
CREATE TABLE `tb_user` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `username` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL COMMENT '收件人',
  `address` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL COMMENT '地址',
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `username` (`username`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=109 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;

insert  into `tb_user`(`id`,`username`,`address`) values (1,'张小敬','湖南省衡阳市'),(2,'文二狗','陕西省西安市'),(3,'华沉鱼','湖北省十堰市'),(4,'张必沉','天津市'),(5,'郑爽爽','辽宁省沈阳市大东区'),(6,'范兵兵','山东省青岛市');

USE `cloud_order`;

DROP TABLE IF EXISTS `tb_order`;
CREATE TABLE `tb_order` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '订单id',
  `user_id` bigint NOT NULL COMMENT '用户id',
  `name` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL COMMENT '商品名称',
  `price` bigint NOT NULL COMMENT '商品价格',
  `num` int DEFAULT '0' COMMENT '商品数量',
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `username` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=109 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;

insert  into `tb_order`(`id`,`user_id`,`name`,`price`,`num`) values (101,1,'Apple 苹果 iPhone 12 ',699900,1),(102,2,'雅迪 yadea 新国标电动车',209900,1),(103,3,'骆驼（CAMEL）休闲运动鞋女',43900,1),(104,4,'小米10 双模5G 骁龙865',359900,1),(105,5,'OPPO Reno3 Pro 双模5G 视频双防抖',299900,1),(106,6,'美的（Midea) 新能效 冷静星II ',544900,1),(107,7,'西昊/SIHOO 人体工学电脑椅子',79900,1),(108,3,'梵班（FAMDBANN）休闲男鞋',31900,1);

表的初始数据如下所示（第一张表是user表，归user-service持有，第二张表示order表，归order-service所持有），另外，cloud-order表中持有cloud-user表中的id字段，需求是order-service去调用user-service服务

在order-service服务中，有一个根据id查询订单的接口：

根据id查询订单，返回值是Order对象，如图，发送请求，localhost:8088/order/101，

在user-service中有一个根据id查询用户的接口，可发送请求测试：localhost:8081/user/1

2.3、案例需求

• 修改order-service中的根据id查询订单业务，要求在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回。
  
  因此，我们需要在order-service中 向user-service发起一个http的请求，调用http://localhost:8081/user/{userId}这个接口
  大概的步骤是这样的：
• 注册一个RestTemplate的实例到Spring容器
• 修改order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User
• 将查询的User填充到Order对象，一起返回

2.4、服务的远程调用

• 在order-service服务中的启动类上注入RestTemplate：

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    @Bean
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

• 修改order-service服务中的OrderService类中queryOrderById方法：

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.远程查询User
        // 2.1、url地址
        String url = "http://localhost:8081/user/" + order.getUserId();
        // 2.2、利用注入Spring容器的RestTemplate发起调用(JSON类型数据反序列化为对象)
        User user = restTemplate.getForObject(url, User.class);
        // 3.存入order
        order.setUser(user);
        // 4.返回order
        return order;
    }
}

2.5、提供者与消费者

在服务调用关系中，会有两个不同的角色：

• 服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）
• 服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）
  
  但是，服务提供者与服务消费者的角色并不是绝对的，而是相对于业务而言。
  如果服务A调用了服务B，而服务B又调用了服务C，服务B的角色是什么？
• 对于A调用B的业务而言：A是服务消费者，B是服务提供者
• 对于B调用C的业务而言：B是服务消费者，C是服务提供者
  因此，服务B既可以是服务提供者，也可以是服务消费者。

3、Eureka注册中心

假如我们的服务提供者user-service部署了多个实例，如图：

这里需要思考几个问题：

• order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？
• 有多个user-service实例地址，order-service调用时该如何选择？
• order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

3.1、Eureka的结构和作用

这些问题都需要利用SpringCloud中的注册中心来解决，其中最广为人知的注册中心就是Eureka，其结构如下：

在Eureka架构中，微服务角色有两类：

• EurekaServer：服务端，注册中心，用来记录服务信息，监控各个服务的心跳
• EurekaClient：客户端，分为服务提供方（Provider）、服务消费方（Consumer）

服务提供方（Provider），注册自己的信息到EurekaServer，每隔30秒向EurekaServer发送心跳
服务消费方（Consumer），根据服务名称从EurekaServer中拉取服务列表，基于服务列表做负载均衡，选中一个微服务后发起远程调用

注意：一个微服务，既可以是服务提供者，又可以是服务消费者，因此eureka将服务注册、服务发现等功能统一封装到了eureka-client端

• 接下来我们动手实践的步骤包括：
  

3.2、搭建eureka-server模块

• 引入eureka-server依赖

  <dependency>
      <groupId>org.springframework.cloudgroupId>
      <artifactId>spring-cloud-starter-netflix-eureka-serverartifactId>
 dependency>

• 启动类添加@EnableEurekaServer 注解

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
// 在eureka-server服务的启动类上，添加一个@EnableEurekaServer注解，开启eureka的注册中心功能：
@EnableEurekaServer
public class EurekaServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

• 在application.yml中配置eureka服务端地址

server:
  port: 12001
spring:
  application:
    name: eureka-server  ## eureka的服务名称
eureka:
  client:
    service-url:   ## eureka的地址信息,当搭建eureka集群时,需要知道集群中的各个节点信息,
      defaultZone: http://127.0.0.1:12001/eureka

• 启动eureka服务：
  发送请求：http://localhost:12001/，其结果如图所示：
  当然，也还可以通过点击IDEA 启动eureka-server后，生成的访问链接

3.3、服务注册

• 引入eureka-client的依赖

 >
     >org.springframework.cloud>
     >spring-cloud-starter-netflix-eureka-client>
 >

• 在application.yml中配置eureka服务端地址

spring:
  application:
    name: user-service
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:12001/eureka

注意：无论是消费者还是提供者，都需要引入eureka-client

3.4、服务发现

• 在启动类的RestTemplate上添加@LoadBalanced注解

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    @Bean
    @LoadBalanced  // 开启负载均衡
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

• 修改OrderService类
  修改queryOrderById方法，调用其他服务时，不再指定IP和端口号，而是限定所调用服务的名称

String url = "http://user-service/user/" + order.getUserId();

4.Ribbon负载均衡

经过如上过程，可实现负载均衡功能（添加了@LoadBalanced注解），这是什么原理呢？

4.1、负载均衡原理

• SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。
  
  那么发出的请求明明是http://userservice/user/1，怎么变成了http://localhost:8081的呢？

4.2、源码跟踪

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。
显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。

我们进行源码跟踪：

1）LoadBalancerIntercepor

可以看到这里的intercept方法，拦截了用户的HttpRequest请求，然后做了几件事：

• request.getURI()：获取请求uri，本例中就是 http://user-service/user/8
• originalUri.getHost()：获取uri路径的主机名，其实就是服务id，user-service
• this.loadBalancer.execute()：处理服务id，和用户请求。

这里的this.loadBalancer是LoadBalancerClient类型，我们继续跟入。

2）LoadBalancerClient

继续跟入execute方法：

代码是这样的：

• getLoadBalancer(serviceId)：根据服务id获取ILoadBalancer，而ILoadBalancer会拿着服务id去eureka中获取服务列表并保存起来。
• getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。本例中，可以看到获取了8082端口的服务

放行后，再次访问并跟踪，发现获取的是8081，故而实现了负载均衡。

3）负载均衡策略IRule

在刚才的代码中，可以看到获取服务使通过一个getServer方法来做负载均衡:

我们继续跟入：

继续跟踪源码chooseServer方法，发现这么一段代码：

我们看看这个rule是谁：

这里的rule默认值是一个RoundRobinRule，看类的介绍（当前使用的负载均衡策略为轮询策略）：

4）总结

• SpringCloudRibbon的底层采用了一个拦截器，拦截了RestTemplate发出的请求，对地址做了修改。用一幅图来总结一下：
  
  基本流程如下：

• 拦截我们的RestTemplate请求http://userservice/user/1

• RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service

• DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表

• eureka返回列表，localhost:8081、localhost:8082

• IRule利用内置负载均衡规则，从列表中选择一个，例如localhost:8081

• RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实请求

4.3、负载均衡策略

负载均衡的规则都定义在IRule接口中，而IRule有很多不同的实现类：

不同规则的含义如下：

默认的实现就是ZoneAvoidanceRule，是一种轮询方案。

4.4、自定义负载均衡策略

通过定义IRule实现可以修改负载均衡规则，有两种方式：

• 1）代码方式：在order-service中的启动类OrderApplication中，定义一个新的IRule：

@Bean
public IRule randomRule(){
    return new RandomRule();
}

• 2）配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则 

4.5、饥饿加载

• Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。
  而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    enabled: true ## 开启饥饿加载
    clients: userservice  ## 指定使用饥饿加载的服务名

5、Nacos注册中心

Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。

5.1、Windows安装

开发阶段采用单机安装即可。

1）下载安装包

• 在Nacos的GitHub页面，提供有下载链接，可以下载编译好的Nacos服务端或者源代码：
  GitHub主页：https://github.com/alibaba/nacos
  GitHub的Release下载页：https://github.com/alibaba/nacos/releases
  
• 下载Nacos安装包，并解压到任意非中文目录下

2）启动Nacos服务

• 切换到解压后的Nacos的bin目录下，cmd的方式打开命令行窗口，执行如下命令以单机版的方式启动Nacos服务：

startup.cmd -m standalone

• Nacos服务启动成功后，访问地址：http://localhost:8848/nacos/就会来到下图所示界面，账号和密码默认都是nacos
  
• 登录成功后，就会如图所示界面
  
• 注意：Nacos的默认端口是8848，如果你电脑上的其它进程占用了8848端口，请先尝试关闭该进程。如果无法关闭占用8848端口的进程，也可以进入nacos的conf目录，修改application.properties配置文件中的端口：
  

5.2、服务注册到Nacos

• Nacos是SpringCloudAlibaba的组件，而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说，并没有太大区别。
• 主要差异在于：依赖和服务地址不同

1）引入依赖

• 在cloud-demo父工程的pom文件中的中引入SpringCloudAlibaba的依赖：

- <dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-alibaba-dependenciesartifactId>
    <version>2.2.6.RELEASEversion>
    <type>pomtype>
    <scope>importscope>
dependency>

• 在user-service和order-service中的pom文件中引入nacos-discovery依赖（需要注释掉eureka的依赖）：

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
dependency>

2）配置nacos地址

• 在user-service和order-service的application.yml中添加nacos地址：
  

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

3）测试

重启order-service和user-service微服务后，登录nacos管理页面，可以看到微服务信息，如图order-service有两个，是因为我复制了端口为8090的order-service服务的配置：

在Run DashBoard中，选中order-servce服务，右键，选择Copy Configuration，在vm options输入栏中通过输入-Dserver.port命令指定服务实例的端口号（如：-Dserver.port=8091）

4）其他问题

• Run DashDoard
  我在测试过程中，不注意将Run DashDoard界面弄没了，导致后续启动项目变得非常麻烦，解决方法如下：可以在工程目录下找.idea文件夹下的workspace.xml，在其中增加如下组件，

 <component name="RunDashboard">
     <option name="configurationTypes">
       <set>
         <option value="SpringBootApplicationConfigurationType" />
       set>
     option>
     <option name="ruleStates">
       <list>
         <RuleState>
           <option name="name" value="ConfigurationTypeDashboardGroupingRule" />
         RuleState>
         <RuleState>
           <option name="name" value="StatusDashboardGroupingRule" />
         RuleState>
       list>
     option>
   component>

• eureka和nacos的依赖冲突：
  
  解决方案：
• 找到External Libraries里面eureka的jar包（可用双Shift搜索‘eureka’）
  然后在 “spring-cloud-netflix-eureka-client:xx” 上右键“Open Library Settings”如下图：
  
  
  右键“Delete”, 删除这个依赖，然后，apply --> ok

5.3、服务分级存储模型

1）模型概述

一个服务可以有多个实例，例如我们的user-service，可以有:

• 127.0.0.1:8081
• 127.0.0.1:8082
• 127.0.0.1:8083
  假如这些实例分布于全国各地的不同机房，例如：
• 127.0.0.1:8081，在上海机房
• 127.0.0.1:8082，在上海机房
• 127.0.0.1:8083，在杭州机房
  Nacos就将同一机房内的实例 划分为一个集群。

也就是说，user-service是服务，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型

在Nacos服务分级存储模型中，一级是服务，例如，user-service，二级是集群，例如，前面配置的WuHan、ShenZhen；三级是实例，例如，WuHan机房的某台机器上部署了user-service服务

微服务互相访问时，应该尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。例如：

2）集群配置

修改order-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: ShenZhen   #  配置集群名称

重启两个order-service实例后，再次复制一个order-service启动配置，添加属性：

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=WuHan

我们可以在nacos控制台看到下面结果（点击 服务列表中操作栏的 详情选项，即可查看），order-service服务实例数是3个，选中最右侧的详情，即可看到指定服务的集群等信息

3）同集群优先的负载均衡

默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。因此Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。

• 修改user-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: ShenZhen # 集群名称

• 同前面的order-service服务一样，配置多个user-service实例（其后，让order-service去调用多个user-service），其结果如下图所示，再停止8090端口之外的order-service服务，发送多次请求http://localhost:8090/order/101（order-service内部会调用user-service）
  
• 其结果是服务是由多个user-service实例随机提供的，下面修改负载均衡规则，让其优先选择同一集群内的服务，在同一集群中，采用随机访问，如果同一集群中的服务均不可用，会再访问其他集群中的服务

user-service:  # 配置指定服务的负载均衡策略
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 优先选择同一集群内的服务,当同一集群内没有服务可用时,再去调用其他集群中的服务

• NacosRule：优先选择同一集群内的服务,当同一集群内没有服务可用时,再去调用其他集群中的服务
• 启动项目，配置成功，ShenZhen集群中的order-service会优先调用本集群内的user-service；当本集群中user-service宕机后，才会去调用其他集群（WuHan集群）中的user-service

4）权重配置

实际部署中会出现这样的场景：

• 服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。
• 但默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。因此，Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高，在nacos控制台，找到user-service（被调用服务）的实例列表，点击编辑，即可修改权重：
  
  在弹出的编辑窗口，修改权重：
  

5）namespace实现环境隔离

• Nacos为了方便数据和服务的存储、管理，则引入了namespace来实现环境隔离。

• nacos中可以有多个namespace
• namespace下可以有group、service等
• 不同namespace之间相互隔离，例如不同namespace的服务互相不可见

• 创建namespace
  默认情况下，所有service、data、group都在同一个namespace，名为public，点击页面"新建"按钮，添加一个命名空间namespace：
  
  
  如此，一个新的命名空间就已经创建完成：
  
• 给微服务配置namespace

给微服务配置namespace只能通过修改配置来实现,例如，修改order-service的application.yml文件：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: ShenZhen
        namespace: 	f4ca31ea-73e6-4ab8-8872-2521196df4fa # 命名空间，填ID

• 重启order-service后，访问控制台，可以order-service和user-service已经处在不同两个命名空间：
  
• 发送请求：http://localhost:8090/order/103，页面得到500的响应结果
  
  小总结：
• Nacos通过namespace来实现环境隔离，每个namespace都有唯一的id
• 不同namespace下的服务不可见（即不可在内部相互调用）

5.6、Nacos与Eureka的区别

1）Nacos的服务实例类型

• 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。

• 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。
  配置一个服务实例为永久实例：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

2）两者对比

Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

• Nacos与eureka的共同点
  • 都支持服务注册和服务拉取
  • 都支持服务提供者用心跳方式做健康检测
• Nacos与Eureka的区别
  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式；临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
  • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

6、Nacos配置中心

Nacos除了可以做注册中心，还可以做配置管理，实现服务配置的热更新，即服务不需要重新启动，就能读取到Nacos中的配置。

6.1、统一配置管理

• 当微服务部署的实例越来越多，逐个修改微服务的配置就会变得非常麻烦且容易出错。我们需要一种统一配置管理方案，可以集中管理所有服务实例的配置。
  
• Nacos一方面可以将配置集中管理，另一方可以在配置变更时，及时通知微服务，实现配置的热更新。
• 注意：项目的核心配置，需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。
  
  

6.2、微服务拉取配置

• 微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动。但如果尚未读取application.yml，又如何得知nacos地址呢？
• 因此spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取，流程如下：
  
• 1）引入nacos-config依赖
  在user-service服务中，引入nacos-config的客户端依赖：

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-configartifactId>
dependency>

• 2）添加bootstrap.yaml
  在user-service中添加一个bootstrap.yaml文件，内容如下：

spring:
  application:
    name: user-service # 服务名称
  profiles:
    active: dev #开发环境，这里是dev
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名

• 这里会根据spring.cloud.nacos.server-addr获取nacos地址，再根${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}作为文件id，来读取配置。
• 3）读取nacos配置
  在user-service中的UserController中添加业务逻辑，读取pattern.dateformat配置：

   @Value("${pattern.dateFormat}")
    private String dateFormat;

    @GetMapping("/now")
    public String now(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateFormat));
    }

• 总结：
  

6.3、配置热更新

• 我们最终目的是修改nacos中的配置后，微服务中无需重启即可让配置生效，也就是配置热更新。

1）添加@RefreshScope注解的方式

• 方式1是在@Value注入的变量所在类上添加注解@RefreshScope：
  

2）@ConfigurationProperties代替@Value

• 方式2是 在user-service服务的config包中，添加一个配置类，读取patterrn.dateformat属性：

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@Component   //  将PatternProperties类注册成bean，注入到Spring容器中，以便可以让其他组件使用
@Data
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
}

• 在UserController中使用这个类代替@Value：
  

@Slf4j
@RestController
@RequestMapping("/user")
// @RefreshScope // nacos 热更新配置
public class UserController {

    @Autowired
    private UserService userService;

    @Autowired
    private PatternProperties patternProperties;

//    @Value("${pattern.dateformat}")
//    private String dateFormat;
//
    @GetMapping("/now")
    public String now(){
//        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateFormat));
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(patternProperties.getDateformat()));
    }
 }

6.4、多环境配置共享

其实微服务启动时，会去nacos读取多个配置文件，例如：

• [spring.application.name]-[spring.profiles.active].yaml，例如：userservice-dev.yaml
• [spring.application.name].yaml，例如：userservice.yaml
  而[spring.application.name].yaml不包含环境，因此可以被多个环境共享。

1）具体操作如下

• 1）添加一个环境共享配置
  我们在nacos中添加一个user-service.yaml：选中左侧栏中的配置列表，进行如图配置
  

• 2）在user-service中读取共享配置
  在user-service服务中，修改PatternProperties类，读取新添加的属性envShareValue：
  

• 3）在user-service服务中，修改UserController，添加方法：

    @Autowired
    private PatternProperties patternProperties;

    @GetMapping("/share")
    public PatternProperties share(){
        return patternProperties;
    }

• 4）配置共享测试
  发送请求：http://localhost:8081/user/now，http://localhost:8081/user/share，结果如图所示：
  

启动两个UserApplication，使用不同的profile，修改UserApplication2这个启动项，改变其profile值：

• 如此，UserApplication(8081)使用的profile是dev，UserApplication2(8083)使用的profile是test。
  启动UserApplication和UserApplication2由测试结果看到，多环境共享配置设置成功，dateformat变量只在user-service-dev.yaml中配置过，故只对环境为dev的8081端口可见，而envShareValue只在user-service.yaml配置过，故envShareValue对所有环境都可见，因此，不管是dev，还是test环境，都读取到了envShareValue这个属性的值。
  

2）配置共享的优先级

当nacos、服务本地同时出现相同属性时，优先级有高低之分：
在nacos中的配置和本地配置中都设置相同属性即可测试

6.5、Nacos集群搭建

7、Feign远程调用

7.1、Feign概述

7.2、Feign替代RestTemplate

Fegin的使用步骤如下：

• 1）引入依赖
  我们在order-service服务的pom文件中引入feign的依赖：

<dependency>
    <groupId>org.springframework.cloudgroupId>
    <artifactId>spring-cloud-starter-openfeignartifactId>
dependency>

• 2）添加注解
  在order-service的启动类添加@EnableFeignClients注解开启Feign的功能：
  
• 3）编写Feign的客户端
  在order-service中新建一个UserClient接口，内容如下：

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient("user-service")  // UserClient接口类可以调用user-service服务
public interface UserClient {

    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

这个客户端主要是基于SpringMVC的注解来声明远程调用的信息，比如：

服务名称：user-service，由@FeignClient注解中的属性指定
请求方式：GET（@GetMapping）
请求路径：/user/{id}
请求参数：Long id（@PathVariable(“id”) Long id）
返回值类型：User

这样，Feign就可以帮助我们发送http请求，无需自己使用RestTemplate来发送了。

• 4）使用UserClient发起请求调用
  修改order-service中的OrderService类中的findById方法，使用Feign客户端代替RestTemplate：

 @Autowired
    private UserClient userClient;

    public Order findById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.远程查询User
        User user = userClient.findById(order.getUserId());
        // 3.存入order
        order.setUser(user);
        // 4.返回order
        return order;
    }

• 5）总结
  使用Feign的步骤：
  ① 引入依赖（spring-cloud-starter-openfeign）
  ② 启动类上添加@EnableFeignClients注解
  ③ 编写FeignClient接口（UserClient）
  ④ 注入FeignClient，使用FeignClient中定义的方法代替RestTemplate

7.3、自定义配置

Feign可以支持很多的自定义配置，如下图所示：

一般情况下，默认值就能满足我们使用，如果要自定义时，只需要创建自定义的@Bean覆盖默认Bean即可。

1）编写yaml配置文件的方式

• 基于配置文件修改feign的日志级别可以针对单个服务：

feign:  
  client:
    config: 
      user-service: # 针对某个微服务的配置
        loggerLevel: FULL #  日志级别 

• 也可以针对所有服务，来修改feign的日志级别：

feign:  
  client:
    config: 
      default: # 这里用default就是全局配置，如果是写服务名称，则是针对某个微服务的配置
        loggerLevel: FULL #  日志级别 

• 而日志的级别分为四种：
  • NONE：不记录任何日志信息，这是默认值。
  • BASIC：仅记录请求的方法，URL以及响应状态码和执行时间
  • HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
  • FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

2）编写Java代码的方式

• 基于Java代码来修改日志级别，先声明一个类，然后声明一个Logger.Level的对象：

import feign.Logger;
import org.springframework.context.annotation.Bean;

public class DefaultFeignConfiguration  {
    @Bean
    public Logger.Level feignLogLevel(){
        return Logger.Level.BASIC; // 日志级别为BASIC
    }
}

如果要全局生效，需要将DefaultFeignConfiguration 放到启动类的@EnableFeignClients注解中：

@EnableFeignClients(defaultConfiguration = DefaultFeignConfiguration.class) 

如果是局部生效，则把它放到对应的@FeignClient这个注解中：

@FeignClient(value = "userservice", configuration = DefaultFeignConfiguration .class) 

发送请求，http://localhost:8090/order/106，下面使用Java代码+全局配置的方式，启动服务后，在IDEA控制台所展示的测试结果：

• 小总结：
  

7.4、Feign使用优化

Feign底层发起http请求，依赖于其它的框架。其底层客户端实现包括：

• URLConnection：默认实现，jdk自带，性能一般，不支持连接池，连接池可以减少 http请求 连接和创建的性能损耗（三次握手和 四次挥手）， Feign是声明式的http客户端，将我们编写的声明转变为http请求，
• Apache HttpClient ：支持连接池
• OKHttp：支持连接池

因此提高Feign的性能主要手段就是使用连接池代替默认的URLConnection，这里我们用Apache的HttpClient来讲解。

• 1）引入依赖

在order-service的pom文件中引入Apache的HttpClient依赖：

<dependency>
    <groupId>io.github.openfeigngroupId>
    <artifactId>feign-httpclientartifactId>
dependency>

• 2）配置连接池
  在order-service的application.yml中添加配置：

feign:
  client:
    config:
      default: # default全局的配置
        loggerLevel: BASIC # 日志级别，BASIC就是基本的请求和响应信息
  httpclient:
    enabled: true # 开启feign对HttpClient的支持
    max-connections: 200 # 最大的连接数
    max-connections-per-route: 50 # 每个路径的最大连接数,最大连接数需要压测求得

总结：

• 日志级别尽量使用Basic
• 使用HttpClient或者OKHttp代替URL实现服务的远程调用：

1）引入feign-httpclient的依赖
2）配置文件开启httpclient功能，设置连接池参数

7.5、Feign的最佳实践

所谓最近实践，就是使用过程中总结的经验，最好的一种使用方式。
不难发现，Feign的客户端（order-service）与服务提供者user-service模块的controller代码非常相似：

如何简化这种重复的代码编写，操作如下：

7.5.1、继承方式

一样的代码可以通过继承来共享（采用了面向契约的编程思想）：

• 定义一个API接口，利用定义方法，并基于SpringMVC注解做声明
• Feign客户端和Controller都集成改接口
  
  优点：
• 简单、实现了代码共享

缺点：

• 服务提供方、服务消费方紧耦合
• 参数列表中的注解映射并不会继承，因此Controller中必须再次声明方法、参数列表、注解

7.5.2、抽取代码形成模块

• 将Feign的客户端order-service中的重复代码，抽取为独立模块，并且把接口有关的POJO、默认的Feign配置都放到这个模块中，提供给所有消费者使用。
• 例如，将UserClient、User、Feign的默认配置都抽取到一个feign-api包中，所有微服务引用该依赖包，即可直接使用。
• 如果feign-api中的方法，使用地较少，就不推荐使用该模块 抽取的方式

具体操作如下：

• 1）新建模块，命名为feign-api
• 2）在feign-api中然后引入feign的starter依赖：

<dependency>
    <groupId>org.springframework.cloudgroupId>
    <artifactId>spring-cloud-starter-openfeignartifactId>
dependency>

• 3）剪切user-service模块中的UserClient、User、DefaultFeignConfiguration到feign-api中
  
• 4）在order-service中导入依赖feign-api，首先，删除order-service中的UserClient、User、DefaultFeignConfiguration等类或接口。
  注意：两个服务中feign-api的信息要一致
  

 <dependency>
     <groupId>com.xylgroupId>
     <artifactId>feign-apiartifactId>
    <version>0.0.1-SNAPSHOTversion>
 dependency>

• 4）重入导入order-service服务的包依赖
  修改order-service中的所有与上述三个组件有关的导包部分，改成导入feign-api中的包

• 5）重启测试
  重启服务后，发现报错了：
  
  这是因为UserClient现在在feign-api模块的com.xyl.feign.client包下，而order-service的@EnableFeignClients注解是在cn.itcast.order包下，不在同一个包，无法扫描到UserClient。

• 6）解决扫描包问题
  方式一，启动类上指定需要加载的Client接口：

@EnableFeignClients(clients = {UserClient.class})

方式二，启动类上指定Feign应该扫描的包：

@EnableFeignClients(basePackages = "com.xyl.feign.client")

该方式会扫描feign-api模块com.xyl.feign.client目录下的所有类

• 7）总结
  

8、Gateway服务网关

8.1、为什么需要网关

• Spring Cloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等响应式编程和事件流技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

• Gateway网关是我们服务的守门神，所有微服务的统一入口。

• 网关的核心功能特性：

  • 请求路由和负载均衡：一切请求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。
  • 权限控制：网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截。
  • 限流：当请求流量过高时，在网关中按照下游的微服务能够接受的速度来放行请求，避免服务压力过大。

• 在SpringCloud中网关的实现包括两种：gateway、zuul，
  Zuul是基于Servlet的实现，属于阻塞式编程。而SpringCloudGateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能

8.2、Gateway服务搭建

8.2.1、具体步骤

• 1）创建gateway服务gateway-server，引入依赖

  
    <dependency>
        <groupId>org.springframework.cloudgroupId>
        <artifactId>spring-cloud-starter-gatewayartifactId>
        <version>2.2.5.RELEASEversion>
    dependency>
    
    <dependency>
        <groupId>com.alibaba.cloudgroupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
        <version>2.2.5.RELEASEversion>
    dependency>

• 2）服务启动类

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class GatewayServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(GatewayServerApplication.class, args);
    }
}

• 3）编写基础配置和路由规则
  创建application.yml文件，内容如下：

server:
  port: 13001 # 网关端口
spring:
  application:
    name: gateway-server # 服务名称
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos地址
    gateway:
      routes: # 网关路由配置
        - id: user_service # 路由id，自定义，只要唯一即可
          # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
          uri: lb://user-service # 路由的目标地址 lb就是负载均衡，后面跟服务名称，j
          predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
            - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求，就会路由到user-service中
        - id: order_service
          uri: lb://order-service
          predicates:
            - Path=/order/**

我们将符合Path 规则的一切请求，都代理到 uri参数指定的地址。
本例中，我们将 /user/**开头的请求，代理到lb://userservice，lb是负载均衡，根据服务名拉取服务列表，实现负载均衡。

• 4）启动网关服务
  重启网关和user-service，以及复制多个user-service服务的配置并一同启动，访问http://localhost:10010/user/1时，符合/user/**规则，请求转发到uri：http://userservice/user/1，结果访问成功，启动的多个user-serive实例轮询地提供服务，可见，用Gateway来请求路由和负载均衡都已实现，测试order-service服务也是如此

8.2.2、网关路由的流程图

整个访问的流程如下：

路由配置包括：

• 路由id：路由的唯一标示
• 路由目标（uri）：路由的目标地址，http代表固定地址，lb代表根据服务名负载均衡
• 路由断言（predicates）：判断路由的规则，
• 路由过滤器（filters）：对请求或响应做处理

8.3、断言工厂

• 我们在配置文件中写的断言规则只是字符串，这些字符串会被Predicate Factory读取并处理，转变为路由判断的条件，例如Path=/user/**是按照路径匹配，这个规则是由org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory类来处理的，像这样的断言工厂在SpringCloudGateway还有十几个：
  
• PredicateFactory的作用：读取用户配置的断言规则，然后，将其解析成对应的判断条件，用于对后续用户请求的判断，如果浏览器传过来的url符合 判断条件，再放行请求
• Path=/user/** 的含义：路径是以 /user 开头，就默认为该请求是符合要求的

8.4、过滤器工厂

GatewayFilter是网关中提供的一种过滤器，可以对进入网关的请求和微服务返回的响应做处理：

1）路由过滤器的种类

Spring提供了31种不同的路由过滤器工厂。例如：

名称	说明
AddRequestHeader	给当前请求添加一个请求头
RemoveRequestHeader	移除请求中的一个请求头
AddResponseHeader	给响应结果中添加一个响应头
RemoveResponseHeader	从响应结果中移除有一个响应头
RequestRateLimiter	限制请求的流量

2）举例请求头过滤器（局部过滤器）

下面我们以AddRequestHeader 为例来讲解。
需求：给所有进入userservice的请求添加一个请求头：Truth=I believe I can fly，never give up！
只需要修改gateway服务的application.yml文件，添加路由过滤即可：

spring:
  cloud:
    gateway:
      routes:
       - id: user_service # 路由id，自定义，只要唯一即可
          # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
          uri: lb://user-service # 路由的目标地址 lb就是负载均衡，后面跟服务名称，j
          predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
            - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求，就会路由到user-service中
          filters: # 路由过滤(局部过滤器)
            - AddRequestHeader=Belief,I believe I can fly and never give up

当前过滤器写在userservice路由下，因此仅仅对访问userservice的请求有效。

• 修改user-service服务中的UserController的now方法：

    @Autowired
    private PatternProperties patternProperties;
    
    @GetMapping("/now")
    public String now(@RequestHeader(value = "Belief",required = false) String belief){
//        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateFormat));
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(patternProperties.getDateformat())) + " -->" + belief;
    }

• 启动网关服务和user-service（网关的端口号为13001），发送请求：http://localhost:13001/user/1·，结果如图所示，配置测试成功！
  

3）默认过滤器

• 如果要对所有的路由都生效，则可以将过滤器工厂写到default下（default-filters），格式如下：
  

server:
  port: 13001 # 网关端口
spring:
  application:
    name: gateway-server # 服务名称
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos地址
    gateway:
      routes: # 网关路由配置
        - id: user_service # 路由id，自定义，只要唯一即可
          # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
          uri: lb://user-service # 路由的目标地址 lb就是负载均衡，后面跟服务名称，j
          predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
            - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求，就会路由到user-service中
#          filters: # 局部过滤器
#            - AddRequestHeader=Belief,I believe I can fly and never give up
        - id: order_service
          uri: lb://order-service
          predicates:
            - Path=/order/**
      default-filters: # 默认过滤器
        - AddRequestHeader=Belief,default-filters:I believe I can fly and never give up 

• 发送请求测试， http://localhost:13001/user/now
  

• 4）小总结

• 过滤器的作用是什么？
  ① 对路由的请求或响应做加工处理，比如添加请求头
  ② 配置在路由下的过滤器只对当前路由的请求生效

• defaultFilters是什么？
  ① defaultFilters是对所有路由都生效的过滤器

8.5、全局过滤器

1）GatewayFilter引入

• Gateway提供了31种过滤器，但每一种过滤器的作用都是固定的。如果我们希望拦截请求，做自己的业务逻辑则没办法实现。
• Gateway就引入了全局过滤器，其作用也是处理一切进入网关的请求和微服务响应，与GatewayFilter的作用一样。区别在于GatewayFilter通过配置定义，处理逻辑是固定的；而GlobalFilter的逻辑需要自己写代码实现。

定义方式是实现GlobalFilter接口：

在filter中编写自定义逻辑，可以实现的功能有： 登录状态判断、权限校验、请求限流等

2）代码实现

需求：定义全局过滤器，拦截请求，判断请求的参数是否满足下面条件：
A、参数中是否有authorization，
B、authorization参数值是否为admin
如果同时满足则放行，否则拦截

• 在gateway服务中定义一个过滤器，当全局过滤器有多个时，order值表示过滤器的优先级，order值越小，则优先级越高，设置order可以通过@Order，也可以实现Ordered 接口，重写getOrder方法来实现，具体代码实现如下：

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.http.server.reactive.ServerHttpRequest;
import org.springframework.stereotype.Component;
import org.springframework.util.MultiValueMap;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

//@Order(-1)  // 设置当前 过滤器的优先级，值越小，优先级越高，越先执行，也还可以 实现Ordered接口，重写order方法
@Component
public class AuthorizeFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1.获取请求参数authorization
        ServerHttpRequest request = exchange.getRequest();
        MultiValueMap<String, String> params = request.getQueryParams();
        // 2. 校验
        if ("admin".equals(params)){
            // 3.符合要求, 放行，从过滤器链chain 中找到下一个过滤器filter
            return chain.filter(exchange);
        }
        // 4.拦截
        // 4.1.禁止访问，设置状态码
        exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);  // 未授权,HttpStatus是枚举类,UNAUTHORIZED(401, "Unauthorized"),
        // 4.2.结束处理
        return exchange.getResponse().setComplete();
    }

    @Override
    public int getOrder() {
        return -1;
    }
}

• 补充：见Ordered 接口源码，

package org.springframework.core;

public interface Ordered {
    int HIGHEST_PRECEDENCE = Integer.MIN_VALUE; // order可以设置的最大值
    int LOWEST_PRECEDENCE = Integer.MAX_VALUE;  // order最小值

    int getOrder();
}

• 重启Gateway服务，发送请求：http://localhost:13001/user/2?authorization=admin和http://localhost:13001/user/2，（注意，13001是Gateway的端口）如下图结果所示，全局过滤器成功实现，如果请求后面有参数authorization=admin，则放行请求，返回查询数据的结果，如果没有authorization参数，就会被全局过滤器拦截，返回未授权的状态码401
  

8.6、过滤器执行顺序

1）过滤器排序规则

• 请求进入网关会碰到三类过滤器：当前路由的过滤器（局部过滤器）、DefaultFilter、GlobalFilter
• 请求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器：
  

排序的规则是什么呢：

• 每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。
• GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定
• 路由过滤器和defaultFilter的order由Spring指定，默认是按照声明分别从1顺序递增（即路由过滤器和defaultFilter内部都有自己的计数器，各自计数）。
• 当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。

详细内容，可以查看源码：
org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator#getFilters()方法是先加载defaultFilters，然后再加载某个route的filters，然后合并。
org.springframework.cloud.gateway.handler.FilteringWebHandler#handle()方法会加载全局过滤器，与前面的过滤器合并后根据order排序，组织过滤器链

2）部分源码分析

• 局部过滤器（路由过滤器）和全局过滤器底层由AddRequestHeaderGatewayFilterFactory类实现，其中的apply方法返回的是GatewayFilter对象，而全局过滤器通过实现GlobalFilter接口，重写filter方法实现
• GatewayFilterAdapter是全局过滤器和其他过滤器之间的适配器，各个过滤器通过GatewayFilterAdapter统一适配成GatewayFilter，统一加入到GatewayFilter类型的list集合中
• 在DefaultGatewayFilterChain类中，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链的集合中（GatewayFilter类型的list）

注意：GatewayFilterAdapter和DefaultGatewayFilterChain是FilteringWebHandler中的静态内部类

8.7、跨域问题处理

1）什么是跨域问题

跨域：域名不一致就是跨域，主要包括：

• 域名不同： www.taobao.com 和 www.taobao.org 和 www.jd.com 和 miaosha.jd.com
• 域名相同，端口不同：localhost:8080和localhost8081

跨域问题：浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截的问题
跨域请求 不需要在每个微服务中处理，只需要在网关中处理即可
解决方案：CORS，详情可以参考https://www.ruanyifeng.com/blog/2016/04/cors.html

2）模拟跨域问题：

将下面index.html放入tomcat或者nginx这样的web服务器中，启动并访问：

DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Documenttitle>
head>
<body>
<pre>
spring:
  cloud:
    gateway:
      globalcors: # 全局的跨域处理
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求
              - "http://localhost:8090"
              - "http://www.leyou.com"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期
pre>
body>
<script src="https://unpkg.com/axios/dist/axios.min.js">script>
<script>
  axios.get("http://localhost:13001/user/1?authorization=admin")
  .then(resp => console.log(resp.data))
  .catch(err => console.log(err))
script>
html>

可以在浏览器控制台看到下面的错误：

从localhost:8090访问localhost:13001，端口不同，显然是跨域的请求。

3）解决跨域问题

在gateway服务的application.yml文件中，添加下面的配置：

spring:
  cloud:
    gateway:
      # =========
      globalcors: # 全局的跨域处理
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求 
              - "http://localhost:8090"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期

参考资料：SpringCloud微服务技术实战课程