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);}@Beanpublic RestTemplate restTemplate(){return new RestTemplate();}
}

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

@Service
public class OrderService {@Autowiredprivate OrderMapper orderMapper;@Autowiredprivate 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.存入orderorder.setUser(user);// 4.返回orderreturn 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.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-server</artifactId></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的依赖

 <dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency>

在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文件中的<dependencyManagement>中引入SpringCloudAlibaba的依赖：

- <dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>2.2.6.RELEASE</version><type>pom</type><scope>import</scope>
</dependency>

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

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</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:8848discovery: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:8848discovery: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:8848discovery:cluster-name: ShenZhennamespace:     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的客户端依赖：

<!--nacos配置管理依赖-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

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

spring:application:name: user-service # 服务名称profiles:active: dev #开发环境，这里是devcloud: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 {@Autowiredprivate UserService userService;@Autowiredprivate 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，添加方法：

    @Autowiredprivate 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.cloud</groupId><artifactId>spring-cloud-starter-openfeign</artifactId>
</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：

 @Autowiredprivate UserClient userClient;public Order findById(Long orderId) {// 1.查询订单Order order = orderMapper.findById(orderId);// 2.远程查询UserUser user = userClient.findById(order.getUserId());// 3.存入orderorder.setUser(user);// 4.返回orderreturn 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  {@Beanpublic 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依赖：

<!--httpClient的依赖 -->
<dependency><groupId>io.github.openfeign</groupId><artifactId>feign-httpclient</artifactId>
</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.cloud</groupId><artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

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

 <dependency><groupId>com.xyl</groupId><artifactId>feign-api</artifactId><version>0.0.1-SNAPSHOT</version></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，引入依赖

  <!--gateway网关--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-gateway</artifactId><version>2.2.5.RELEASE</version></dependency><!--nacos服务发现依赖--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId><version>2.2.5.RELEASE</version></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就是负载均衡，后面跟服务名称，jpredicates: # 路由断言，也就是判断请求是否符合路由规则的条件- Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求，就会路由到user-service中- id: order_serviceuri: lb://order-servicepredicates:- 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就是负载均衡，后面跟服务名称，jpredicates: # 路由断言，也就是判断请求是否符合路由规则的条件- Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求，就会路由到user-service中filters: # 路由过滤(局部过滤器)- AddRequestHeader=Belief,I believe I can fly and never give up

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

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

    @Autowiredprivate 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就是负载均衡，后面跟服务名称，jpredicates: # 路由断言，也就是判断请求是否符合路由规则的条件- Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求，就会路由到user-service中
#          filters: # 局部过滤器
#            - AddRequestHeader=Belief,I believe I can fly and never give up- id: order_serviceuri: lb://order-servicepredicates:- 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 {@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {// 1.获取请求参数authorizationServerHttpRequest request = exchange.getRequest();MultiValueMap<String, String> params = request.getQueryParams();// 2. 校验if ("admin".equals(params)){// 3.符合要求, 放行，从过滤器链chain 中找到下一个过滤器filterreturn chain.filter(exchange);}// 4.拦截// 4.1.禁止访问，设置状态码exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);  // 未授权,HttpStatus是枚举类,UNAUTHORIZED(401, "Unauthorized"),// 4.2.结束处理return exchange.getResponse().setComplete();}@Overridepublic 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>Document</title>
</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 # 是否允许携带cookiemaxAge: 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 # 是否允许携带cookiemaxAge: 360000 # 这次跨域检测的有效期

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

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

学习笔记：SpringCloud 微服务技术栈_实用篇①_基础知识
若文章内容或图片失效,请留言反馈.部分素材来自网络,若不小心影响到您的利益,请联系博主删除. 前言学习视频链接 SpringCloud + RabbitMQ + Docker + Redis + 搜 ...
学习笔记：SpringCloud 微服务技术栈_实用篇②_黑马旅游案例
若文章内容或图片失效,请留言反馈.部分素材来自网络,若不小心影响到您的利益,请联系博主删除. 前言学习视频链接 SpringCloud + RabbitMQ + Docker + Redis + 搜 ...
学习笔记：SpringCloud 微服务技术栈_高级篇⑤_可靠消息服务
若文章内容或图片失效,请留言反馈.部分素材来自网络,若不小心影响到您的利益,请联系博主删除. 前言学习视频链接 SpringCloud + RabbitMQ + Docker + Redis + 搜 ...
详解springcloud微服务技术栈（一）
1.微服务技术栈 2.认识微服务 2.1.微服务架构演变 2.2.springcloud(Spring Cloud) SpringCloud和SpringBoot的版本兼容关系如下: 2.3.微服务拆 ...
基于spingboot+springcloud微服务技术的在线教育平台系统
在线教育平台系统分享一个优质的微服务项目教程,这是我在B站找到的项目,教程中老师讲得很细致,而且有配套的教学笔记,视频中听得不是很清楚的时候跟着教学笔记敲是非常方便的.跟着这个视频我搭建出了在线教育 ...
《自学SpringCloud微服务架构》之第 1 篇 —— 微服务的自我修养
序言: 我们先看看2019年中国首富排行榜.嗯,99%的财富掌握在1%的人手里.没错的,这个时代,是富豪们玩转手里的棋子的时代,而我们都是看客.本人已毕业四年,却还是一如既往的做着毕业生都能做的敲代码 ...
SpringCloud 微服务 (十) 消息队列MQ 基础
2019独角兽企业重金招聘Python工程师标准>>> 壹之前学习了SpringCloud Bus结合MQ,没有多学习MQ,本次学习相关内容,先了解异步,同步就不说了异步: 客户 ...
微服务框架 SpringCloud微服务架构分布式事务 38 动手实践 38.2 实现XA 模式
微服务框架 [SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务] 分布式事务文章目录微服务 ...
微服务框架 SpringCloud微服务架构服务异步通讯 51 死信交换机 51.3 延迟队列 51.3.1 延迟队列 51.3.2 延迟队列插件
微服务框架 [SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务] 服务异步通讯文章目录微服 ...