微服务基础知识 认识微服务 单体架构 单体架构（monolithic structure）即整个项目中所有功能模块都在一个工程中开发。项目部署时需要对所有模块一起编译、打包。项目的架构设计、开发模式都相对简单。
当项目规模较小时，这种模式上手快，部署、运维也都很方便，因此早期很多小型项目都采用这种模式。
但随着项目的业务规模越来越大，团队开发人员也不断增加，单体架构就呈现出越来越多的问题：
团队协作成本高 ：团队数十个人同时协作开发同一个项目，由于所有模块都在一个项目中，不同模块的代码之间物理边界越来越模糊。系统发布效率低 ：任何模块变更都需要发布整个系统，而系统发布过程中需要多个模块之间制约较多，需要对比各种文件，任何一处出现问题都会导致发布失败，往往一次发布需要数十分钟甚至数小时。系统可用性差 ：单体架构各个功能模块是作为一个服务部署，相互之间会互相影响，一些热点功能会耗尽系统资源，导致其它服务低可用。
要想解决这些问题，就需要使用微服务架构。
从单体架构到微服务 微服务架构，首先是服务化，就是将单体架构中的功能模块从单体应用中拆分出来，独立部署为多个服务。同时要满足下面的一些特点：
单一职责 ：一个微服务负责一部分业务功能，并且其核心数据不依赖于其它模块团队自治 ：每个微服务都有自己独立的开发、测试、发布、运维人员，团队人员规模较小服务自治 ：每个微服务都独立打包部署，访问自己独立的数据库。并且要做好服务隔离，避免对其它服务产生影响
SpringCloud SpringCloud框架是目前Java领域最全面的微服务组件的集合。它依托于SpringBoot的自动装配能力，降低了其项目搭建、组件使用的成本。
服务调用 不同的微服务虽然功能不同，但因为还是同一个项目，或多或少会出现互相调用的情况。但不同的微服务都是不同的项目，不能使用Spring的自动装配，这时就需要服务之间发送Http请求去获取数据。
RestTemplate Spring提供了一个RestTemplate的API，可以方便的实现Http请求的发送。其中提供了大量的方法，方便发送Http请求
常见的Get、Post、Put、Delete请求都支持，如果请求参数比较复杂，还可以使用exchange方法来构造请求。
使用示例 先将RestTemplate注册为一个Bean
@Configuration public class RemoteCallConfig { @Bean public RestTemplate restTemplate () { return new RestTemplate (); } }
然后使用RestTemplate发送请求
private void handleCartItems (List<CartVO> vos) { Set<Long> itemIds = vos.stream().map(CartVO::getItemId).collect(Collectors.toSet()); ResponseEntity<List<ItemDTO>> response = restTemplate.exchange( "http://localhost:8081/items?ids={ids}" , HttpMethod.GET, null , new ParameterizedTypeReference <List<ItemDTO>>() {}, Map.of("ids" , CollUtil.join(itemIds, "," )) ); List<ItemDTO> items = response.getBody(); }
可以看到，利用RestTemplate发送http请求与前端ajax发送请求非常相似，都包含四部分信息：
在这个过程中，item-service提供了查询接口，cart-service利用Http请求调用该接口。因此item-service可以称为服务的提供者，而cart-service则称为服务的消费者或服务调用者。
总结 服务拆分之后，不可避免的会出现跨微服务的业务，此时微服务之间就需要进行远程调用。微服务之间的远程调用被称为RPC，即远程过程调用。RPC的实现方式有很多，比如：
这里使用的是Http方式，这种方式不关心服务提供者的具体技术实现，只要对外暴露Http接口即可。
Java发送http请求可以使用Spring提供的RestTemplate，使用的基本步骤如下：
注册RestTemplate到Spring容器
调用RestTemplate的API发送请求，常见方法有：
getForObject：发送Get请求并返回指定类型对象
PostForObject：发送Post请求并返回指定类型对象
put：发送PUT请求
delete：发送Delete请求
exchange：发送任意类型请求，返回ResponseEntity
服务注册和发现 上面通过Http请求实现了跨微服务的远程调用，不过这种手动发送Http请求的方式存在一些问题。
试想一下，假如商品微服务被调用较多，为了应对更高的并发，进行了多实例部署，一个微服务对应多个ip地址或端口
此时，每个service的实例其IP或端口不同，问题来了：
service这么多实例，其他服务如何知道每一个实例的地址？
http请求要写url地址，其他服务到底该调用哪个实例？
如果在运行过程中，该服务实例宕机，其他服务依然在调用该怎么办？
如果并发太高，该服务临时多部署了N台实例，其他服务如何知道新实例的地址？
为了解决上述问题，就必须引入注册中心的概念。
为了解决上述问题，就必须引入注册中心的概念了，接下来我们就一起来分析下注册中心的原理。
注册中心原理 在微服务远程调用的过程中，包括两个角色：
服务提供者：提供接口供其它微服务访问
服务消费者：调用其它微服务提供的接口
在大型微服务项目中，服务提供者的数量会非常多，为了管理这些服务就引入了注册中心 的概念。注册中心、服务提供者、服务消费者三者间关系如下：
流程如下：
服务启动时就会注册自己的服务信息（服务名、IP、端口）到注册中心
调用者可以从注册中心订阅想要的服务，获取服务对应的实例列表（1个服务可能多实例部署）
调用者自己对实例列表负载均衡，挑选一个实例
调用者向该实例发起远程调用
当服务提供者的实例宕机或者启动新实例时，调用者如何得知呢？
服务提供者会定期向注册中心发送请求，报告自己的健康状态（心跳请求）
当注册中心长时间收不到提供者的心跳时，会认为该实例宕机，将其从服务的实例列表中剔除
当服务有新实例启动时，会发送注册服务请求，其信息会被记录在注册中心的服务实例列表
当注册中心服务列表变更时，会主动通知微服务，更新本地服务列表
Nacos注册中心 目前开源的注册中心框架有很多，比较常见的有：
Eureka：Netflix公司出品，目前被集成在SpringCloud当中，一般用于Java应用
Nacos：Alibaba公司出品，目前被集成在SpringCloudAlibaba中，一般用于Java应用
Consul：HashiCorp公司出品，目前集成在SpringCloud中，不限制微服务语言
以上几种注册中心都遵循SpringCloud中的API规范，因此在业务开发使用上没有太大差异，这里学习Nacos
安装nacos 首先要准备MySQL数据库表，用来存储Nacos的数据。
DROP DATABASE IF EXISTS `nacos`;CREATE DATABASE IF NOT EXISTS `nacos` ;USE `nacos`; DROP TABLE IF EXISTS `config_info`;CREATE TABLE IF NOT EXISTS `config_info` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id' , `data_id` varchar (255 ) COLLATE utf8_bin NOT NULL COMMENT 'data_id' , `group_id` varchar (128 ) COLLATE utf8_bin DEFAULT NULL , `content` longtext COLLATE utf8_bin NOT NULL COMMENT 'content' , `md5` varchar (32 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'md5' , `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' , `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间' , `src_user` text COLLATE utf8_bin COMMENT 'source user' , `src_ip` varchar (50 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'source ip' , `app_name` varchar (128 ) COLLATE utf8_bin DEFAULT NULL , `tenant_id` varchar (128 ) COLLATE utf8_bin DEFAULT '' COMMENT '租户字段' , `c_desc` varchar (256 ) COLLATE utf8_bin DEFAULT NULL , `c_use` varchar (64 ) COLLATE utf8_bin DEFAULT NULL , `effect` varchar (64 ) COLLATE utf8_bin DEFAULT NULL , `type` varchar (64 ) COLLATE utf8_bin DEFAULT NULL , `c_schema` text COLLATE utf8_bin, `encrypted_data_key` text COLLATE utf8_bin NOT NULL COMMENT '秘钥' , PRIMARY KEY (`id`), UNIQUE KEY `uk_configinfo_datagrouptenant` (`data_id`,`group_id`,`tenant_id`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb3 COLLATE = utf8_bin COMMENT= 'config_info' ; DELETE FROM `config_info`;DROP TABLE IF EXISTS `config_info_aggr`;CREATE TABLE IF NOT EXISTS `config_info_aggr` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id' , `data_id` varchar (255 ) COLLATE utf8_bin NOT NULL COMMENT 'data_id' , `group_id` varchar (128 ) COLLATE utf8_bin NOT NULL COMMENT 'group_id' , `datum_id` varchar (255 ) COLLATE utf8_bin NOT NULL COMMENT 'datum_id' , `content` longtext COLLATE utf8_bin NOT NULL COMMENT '内容' , `gmt_modified` datetime NOT NULL COMMENT '修改时间' , `app_name` varchar (128 ) COLLATE utf8_bin DEFAULT NULL , `tenant_id` varchar (128 ) COLLATE utf8_bin DEFAULT '' COMMENT '租户字段' , PRIMARY KEY (`id`), UNIQUE KEY `uk_configinfoaggr_datagrouptenantdatum` (`data_id`,`group_id`,`tenant_id`,`datum_id`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb3 COLLATE = utf8_bin COMMENT= '增加租户字段' ; DELETE FROM `config_info_aggr`;DROP TABLE IF EXISTS `config_info_beta`;CREATE TABLE IF NOT EXISTS `config_info_beta` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id' , `data_id` varchar (255 ) COLLATE utf8_bin NOT NULL COMMENT 'data_id' , `group_id` varchar (128 ) COLLATE utf8_bin NOT NULL COMMENT 'group_id' , `app_name` varchar (128 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'app_name' , `content` longtext COLLATE utf8_bin NOT NULL COMMENT 'content' , `beta_ips` varchar (1024 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'betaIps' , `md5` varchar (32 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'md5' , `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' , `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间' , `src_user` text COLLATE utf8_bin COMMENT 'source user' , `src_ip` varchar (50 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'source ip' , `tenant_id` varchar (128 ) COLLATE utf8_bin DEFAULT '' COMMENT '租户字段' , `encrypted_data_key` text COLLATE utf8_bin NOT NULL COMMENT '秘钥' , PRIMARY KEY (`id`), UNIQUE KEY `uk_configinfobeta_datagrouptenant` (`data_id`,`group_id`,`tenant_id`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb3 COLLATE = utf8_bin COMMENT= 'config_info_beta' ; DELETE FROM `config_info_beta`;DROP TABLE IF EXISTS `config_info_tag`;CREATE TABLE IF NOT EXISTS `config_info_tag` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id' , `data_id` varchar (255 ) COLLATE utf8_bin NOT NULL COMMENT 'data_id' , `group_id` varchar (128 ) COLLATE utf8_bin NOT NULL COMMENT 'group_id' , `tenant_id` varchar (128 ) COLLATE utf8_bin DEFAULT '' COMMENT 'tenant_id' , `tag_id` varchar (128 ) COLLATE utf8_bin NOT NULL COMMENT 'tag_id' , `app_name` varchar (128 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'app_name' , `content` longtext COLLATE utf8_bin NOT NULL COMMENT 'content' , `md5` varchar (32 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'md5' , `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' , `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间' , `src_user` text COLLATE utf8_bin COMMENT 'source user' , `src_ip` varchar (50 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'source ip' , PRIMARY KEY (`id`), UNIQUE KEY `uk_configinfotag_datagrouptenanttag` (`data_id`,`group_id`,`tenant_id`,`tag_id`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb3 COLLATE = utf8_bin COMMENT= 'config_info_tag' ; DELETE FROM `config_info_tag`;DROP TABLE IF EXISTS `config_tags_relation`;CREATE TABLE IF NOT EXISTS `config_tags_relation` ( `id` bigint NOT NULL COMMENT 'id' , `tag_name` varchar (128 ) COLLATE utf8_bin NOT NULL COMMENT 'tag_name' , `tag_type` varchar (64 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'tag_type' , `data_id` varchar (255 ) COLLATE utf8_bin NOT NULL COMMENT 'data_id' , `group_id` varchar (128 ) COLLATE utf8_bin NOT NULL COMMENT 'group_id' , `tenant_id` varchar (128 ) COLLATE utf8_bin DEFAULT '' COMMENT 'tenant_id' , `nid` bigint NOT NULL AUTO_INCREMENT, PRIMARY KEY (`nid`), UNIQUE KEY `uk_configtagrelation_configidtag` (`id`,`tag_name`,`tag_type`), KEY `idx_tenant_id` (`tenant_id`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb3 COLLATE = utf8_bin COMMENT= 'config_tag_relation' ; DELETE FROM `config_tags_relation`;DROP TABLE IF EXISTS `group_capacity`;CREATE TABLE IF NOT EXISTS `group_capacity` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID' , `group_id` varchar (128 ) COLLATE utf8_bin NOT NULL DEFAULT '' COMMENT 'Group ID，空字符表示整个集群' , `quota` int unsigned NOT NULL DEFAULT '0' COMMENT '配额，0表示使用默认值' , `usage` int unsigned NOT NULL DEFAULT '0' COMMENT '使用量' , `max_size` int unsigned NOT NULL DEFAULT '0' COMMENT '单个配置大小上限，单位为字节，0表示使用默认值' , `max_aggr_count` int unsigned NOT NULL DEFAULT '0' COMMENT '聚合子配置最大个数，，0表示使用默认值' , `max_aggr_size` int unsigned NOT NULL DEFAULT '0' COMMENT '单个聚合数据的子配置大小上限，单位为字节，0表示使用默认值' , `max_history_count` int unsigned NOT NULL DEFAULT '0' COMMENT '最大变更历史数量' , `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' , `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间' , PRIMARY KEY (`id`), UNIQUE KEY `uk_group_id` (`group_id`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb3 COLLATE = utf8_bin COMMENT= '集群、各Group容量信息表' ; DELETE FROM `group_capacity`;DROP TABLE IF EXISTS `his_config_info`;CREATE TABLE IF NOT EXISTS `his_config_info` ( `id` bigint unsigned NOT NULL , `nid` bigint unsigned NOT NULL AUTO_INCREMENT, `data_id` varchar (255 ) COLLATE utf8_bin NOT NULL , `group_id` varchar (128 ) COLLATE utf8_bin NOT NULL , `app_name` varchar (128 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'app_name' , `content` longtext COLLATE utf8_bin NOT NULL , `md5` varchar (32 ) COLLATE utf8_bin DEFAULT NULL , `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP , `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP , `src_user` text COLLATE utf8_bin, `src_ip` varchar (50 ) COLLATE utf8_bin DEFAULT NULL , `op_type` char (10 ) COLLATE utf8_bin DEFAULT NULL , `tenant_id` varchar (128 ) COLLATE utf8_bin DEFAULT '' COMMENT '租户字段' , `encrypted_data_key` text COLLATE utf8_bin NOT NULL COMMENT '秘钥' , PRIMARY KEY (`nid`), KEY `idx_gmt_create` (`gmt_create`), KEY `idx_gmt_modified` (`gmt_modified`), KEY `idx_did` (`data_id`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb3 COLLATE = utf8_bin COMMENT= '多租户改造' ; DELETE FROM `his_config_info`;DROP TABLE IF EXISTS `permissions`;CREATE TABLE IF NOT EXISTS `permissions` ( `role` varchar (50 ) COLLATE utf8mb4_general_ci NOT NULL , `resource` varchar (255 ) COLLATE utf8mb4_general_ci NOT NULL , `action` varchar (8 ) COLLATE utf8mb4_general_ci NOT NULL , UNIQUE KEY `uk_role_permission` (`role`,`resource`,`action`) USING BTREE ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4 COLLATE = utf8mb4_general_ci; DELETE FROM `permissions`;DROP TABLE IF EXISTS `roles`;CREATE TABLE IF NOT EXISTS `roles` ( `username` varchar (50 ) COLLATE utf8mb4_general_ci NOT NULL , `role` varchar (50 ) COLLATE utf8mb4_general_ci NOT NULL , UNIQUE KEY `idx_user_role` (`username`,`role`) USING BTREE ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4 COLLATE = utf8mb4_general_ci; DELETE FROM `roles`;INSERT INTO `roles` (`username`, `role`) VALUES ('nacos' , 'ROLE_ADMIN' ); DROP TABLE IF EXISTS `tenant_capacity`;CREATE TABLE IF NOT EXISTS `tenant_capacity` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID' , `tenant_id` varchar (128 ) COLLATE utf8_bin NOT NULL DEFAULT '' COMMENT 'Tenant ID' , `quota` int unsigned NOT NULL DEFAULT '0' COMMENT '配额，0表示使用默认值' , `usage` int unsigned NOT NULL DEFAULT '0' COMMENT '使用量' , `max_size` int unsigned NOT NULL DEFAULT '0' COMMENT '单个配置大小上限，单位为字节，0表示使用默认值' , `max_aggr_count` int unsigned NOT NULL DEFAULT '0' COMMENT '聚合子配置最大个数' , `max_aggr_size` int unsigned NOT NULL DEFAULT '0' COMMENT '单个聚合数据的子配置大小上限，单位为字节，0表示使用默认值' , `max_history_count` int unsigned NOT NULL DEFAULT '0' COMMENT '最大变更历史数量' , `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' , `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间' , PRIMARY KEY (`id`), UNIQUE KEY `uk_tenant_id` (`tenant_id`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb3 COLLATE = utf8_bin COMMENT= '租户容量信息表' ; DELETE FROM `tenant_capacity`;DROP TABLE IF EXISTS `tenant_info`;CREATE TABLE IF NOT EXISTS `tenant_info` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id' , `kp` varchar (128 ) COLLATE utf8_bin NOT NULL COMMENT 'kp' , `tenant_id` varchar (128 ) COLLATE utf8_bin DEFAULT '' COMMENT 'tenant_id' , `tenant_name` varchar (128 ) COLLATE utf8_bin DEFAULT '' COMMENT 'tenant_name' , `tenant_desc` varchar (256 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'tenant_desc' , `create_source` varchar (32 ) COLLATE utf8_bin DEFAULT NULL COMMENT 'create_source' , `gmt_create` bigint NOT NULL COMMENT '创建时间' , `gmt_modified` bigint NOT NULL COMMENT '修改时间' , PRIMARY KEY (`id`), UNIQUE KEY `uk_tenant_info_kptenantid` (`kp`,`tenant_id`), KEY `idx_tenant_id` (`tenant_id`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb3 COLLATE = utf8_bin COMMENT= 'tenant_info' ; DELETE FROM `tenant_info`;DROP TABLE IF EXISTS `users`;CREATE TABLE IF NOT EXISTS `users` ( `username` varchar (50 ) COLLATE utf8mb4_general_ci NOT NULL , `password` varchar (500 ) COLLATE utf8mb4_general_ci NOT NULL , `enabled` tinyint(1 ) NOT NULL , PRIMARY KEY (`username`) ) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4 COLLATE = utf8mb4_general_ci; DELETE FROM `users`;INSERT INTO `users` (`username`, `password`, `enabled`) VALUES ('nacos' , '$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu' , 1 );
然后需要配置环境
PREFER_HOST_MODE=hostname MODE=standalone SPRING_DATASOURCE_PLATFORM=mysql MYSQL_SERVICE_HOST=192.168.145.128 # 改成自己的IP地址 MYSQL_SERVICE_DB_NAME=nacos MYSQL_SERVICE_PORT=3306 MYSQL_SERVICE_USER=root MYSQL_SERVICE_PASSWORD=123 MYSQL_SERVICE_DB_PARAM=characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai
进入root目录，执行docker命令：
docker run -d \ --name nacos \--env-file ./nacos/custom.env \-p 8848 :8848 \-p 9848 :9848 \-p 9849 :9849 \--restart =always \nacos/nacos-server :v2.1.0 -slim
启动完成后，访问下面地址：http://ip地址/nacos/
首次访问会跳转到登录页，账号密码都是nacos
服务注册 接下来，把service注册到Nacos
添加依赖 在pom.xml中添加依赖：
<dependency > <groupId > com.alibaba.cloud</groupId > <artifactId > spring-cloud-starter-alibaba-nacos-discovery</artifactId > </dependency >
配置Nacos 在application.yml中添加nacos地址配置：
spring: application: name: item-service cloud: nacos: server-addr: 192.168 .145 .128 :8848
启动服务实例后访问nacos控制台，可以发现服务注册成功
服务发现 服务的消费者要去nacos订阅服务，这个过程就是服务发现
引入依赖 服务发现除了要引入nacos依赖以外，由于还需要负载均衡，因此要引入SpringCloud提供的LoadBalancer依赖。
在pom.xml中添加依赖：
<dependency > <groupId > com.alibaba.cloud</groupId > <artifactId > spring-cloud-starter-alibaba-nacos-discovery</artifactId > </dependency >
可以发现，这里Nacos的依赖于服务注册时一致，这个依赖中同时包含了服务注册和发现的功能。因为任何一个微服务都可以调用别人，也可以被别人调用，即可以是调用者，也可以是提供者。
配置Nacos地址 在application.yml中添加nacos地址配置：
spring: cloud: nacos: server-addr: 192.168 .150 .101 :8848
####发现并调用服务
接下来，服务调用者就可以去订阅已经在Nacos注册过的服务了。不过因为服务可能有多个实例，而真正发起调用时只需要知道一个实例的地址。
因此，服务调用者必须利用负载均衡的算法，从多个实例中挑选一个去访问。常见的负载均衡算法有：
Eureka Eureka是Netflix公司开源的一个服务注册中心组件，早期版本的SpringCloud都是使用Eureka作为注册中心。由于Eureka和Nacos的starter中提供的功能都是基于SpringCloudCommon规范，因此两者使用起来差别不大。
Eureka和Nacos对比 Eureka和Nacos都能起到注册中心的作用，用法基本类似。但还是有一些区别的，例如：
服务注册发现上也有区别，在Eureka中，健康检测的原理如下：
微服务启动时注册信息到Eureka，这点与Nacos一致
微服务每隔30秒向Eureka发送心跳请求，报告自己的健康状态。Nacos中默认是5秒一次
Eureka如果90秒未收到心跳，则认为服务疑似故障，可能被剔除。Nacos中则是15秒超时，30秒剔除
Eureka如果发现超过85%比例的服务都心跳异常，会认为是自己的网络异常，暂停剔除服务的功能
Eureka每隔60秒执行一次服务检测和清理任务；Nacos是每隔5秒执行一次
综上，你会发现Eureka是尽量不剔除服务，这就导致当服务真的出现故障时，迟迟不会被剔除，给服务的调用者带来困扰
不仅如此，当Eureka发现服务宕机并从服务列表中剔除以后，并不会将服务列表的变更消息推送给所有微服务。而是等待微服务自己来拉取时发现服务列表的变化。而微服务每隔30秒才会去Eureka更新一次服务列表，进一步推迟了服务宕机时被发现的时间。
而Nacos中微服务除了自己定时去Nacos中拉取服务列表以外，Nacos还会在服务列表变更时主动推送最新的服务列表给所有的订阅者
综上，Eureka和Nacos的相似点有：
都支持服务注册发现功能
都有基于心跳的健康监测功能
都支持集群，集群间数据同步默认是AP模式，即最全高可用性
Eureka和Nacos的区别有：
Eureka的心跳是30秒一次，Nacos则是5秒一次
Eureka如果90秒未收到心跳，则认为服务疑似故障，可能被剔除。Nacos中则是15秒超时，30秒剔除。
Eureka每隔60秒执行一次服务检测和清理任务；Nacos是每隔5秒执行一次。
Eureka只能等微服务自己每隔30秒更新一次服务列表；Nacos即有定时更新，也有在服务变更时的广播推送
Eureka仅有注册中心功能，而Nacos同时支持注册中心、配置管理
Eureka和Nacos都支持集群，而且默认都是AP模式
OpenFeign 上面利用Nacos实现了服务的治理，利用RestTemplate实现了服务的远程调用。但是远程调用的代码太复杂了。
而且这种调用方式，与原本的本地方法调用差异太大，编程时的体验也不统一，一会儿远程调用，一会儿本地调用。
因此，必须想办法改变远程调用的开发模式，让远程调用像本地方法调用一样简单 。而这就要用到OpenFeign组件了。
其实远程调用的关键点就在于四个：
所以，OpenFeign就利用SpringMVC的相关注解来声明上述4个参数，然后基于动态代理帮我们生成远程调用的代码，而无需我们手动再编写，非常方便。
快速入门 引入依赖 在服务调用者的pom.xml中引入OpenFeign的依赖和loadBalancer依赖：
<dependency > <groupId > org.springframework.cloud</groupId > <artifactId > spring-cloud-starter-openfeign</artifactId > </dependency > <dependency > <groupId > org.springframework.cloud</groupId > <artifactId > spring-cloud-starter-loadbalancer</artifactId > </dependency >
启用OpenFeign 在启动类上添加注解，启动OpenFeign功能：
@EnableFeignClients @MapperScan("...") @SpringBootApplication public class CartApplication { public static void main (String[] args) { SpringApplication.run(CartApplication.class, args); } }
编写OpenFeign客户端 定义一个新的接口，编写Feign客户端：
@FeignClient("item-service") public interface ItemClient { @GetMapping("/items") List<ItemDTO> queryItemByIds (@RequestParam("ids") Collection<Long> ids) ; }
这里只需要声明接口，无需实现方法。接口中的几个关键信息：
@FeignClient("") ：声明服务名称@GetMapping ：声明请求方式@GetMapping("") ：声明请求路径@RequestParam("ids") Collection<Long> ids ：声明请求参数List<ItemDTO> ：返回值类型
有了上述信息，OpenFeign就可以利用动态代理帮我们实现这个方法，并且向http://item-service/items发送一个GET请求，携带ids为请求参数，并自动将返回值处理为List<ItemDTO>。
我们只需要直接调用这个方法，即可实现远程调用了。
使用FeignClient 最后在服务调用者的调用ItemClient的方法：
@Service @RequiredArgsConstructor public class CartServiceImpl extends ServiceImpl <CartMapper, Cart> implements ICartService { private final ItemClient itemClient; private void handleCartItems (List<CartVO> vos) { Set<Long> itemIds = vos.stream().map(CartVO::getItemId).collect(Collectors.toSet()); List<ItemDTO> items = itemClient.queryItemByIds(itemIds); } }
feign完成了服务拉取、负载均衡、发送http请求的所有工作，不再需要RestTemplate了，还省去了RestTemplate的注册
连接池 Feign底层发起http请求，依赖于其它的框架。其底层支持的http客户端实现包括：
HttpURLConnection：默认实现，不支持连接池
Apache HttpClient ：支持连接池
OKHttp：支持连接池
因此我们通常会使用带有连接池的客户端来代替默认的HttpURLConnection。比如，使用OKHttp
引入依赖 引入依赖：
<dependency > <groupId > io.github.openfeign</groupId > <artifactId > feign-okhttp</artifactId > </dependency >
开启连接池 在application.yml中开启Feign的连接池功能：
feign: okhttp: enabled: true
重启服务，连接池就生效了。
负载均衡原理 在SpringCloud的早期版本中，负载均衡都是有Netflix公司开源的Ribbon组件来实现的，甚至Ribbon被直接集成到了Eureka-client和Nacos-Discovery中。
但是自SpringCloud2020版本开始，已经弃用Ribbon，改用Spring自己开源的Spring Cloud LoadBalancer了，我们使用的OpenFeign的也已经与其整合。
Spring在整合OpenFeign的时候，实现了org.springframework.cloud.openfeign.loadbalancer.FeignBlockingLoadBalancerClient类，其中定义了OpenFeign发起远程调用的核心流程。也就是四步：
获取请求中的serviceId
根据serviceId负载均衡，找出一个可用的服务实例
利用服务实例的ip和port信息重构url
向真正的url发起请求
而具体的负载均衡则是不是由OpenFeign组件负责。而是分成了负载均衡的接口规范 ，以及负载均衡的具体实现 两部分。
负载均衡的接口规范是定义在Spring-Cloud-Common模块中，包含下面的接口：
LoadBalancerClient：负载均衡客户端，职责是根据serviceId最终负载均衡，选出一个服务实例ReactiveLoadBalancer：负载均衡器，负责具体的负载均衡算法
OpenFeign的负载均衡是基于Spring-Cloud-Common模块中的负载均衡规则接口，并没有写死具体实现。这就意味着以后还可以拓展其它各种负载均衡的实现。
不过目前SpringCloud中只有Spring-Cloud-Loadbalancer这一种实现。
Spring-Cloud-Loadbalancer模块中，实现了Spring-Cloud-Common模块的相关接口，具体如下：
BlockingLoadBalancerClient：实现了LoadBalancerClient，会根据serviceId选出负载均衡器并调用其算法实现负载均衡。RoundRobinLoadBalancer：基于轮询算法实现了ReactiveLoadBalancerRandomLoadBalancer：基于随机算法实现了ReactiveLoadBalancerNacosLoadBalancer：基于集群优先+实例权重+随机的方式实现ReactiveLoadBalancer
网关 单体架构时只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。而微服务拆分后，每个微服务都独立部署，这就存在一些问题：
每个微服务都需要编写登录校验、用户信息获取的功能吗？
当微服务之间调用时，该如何传递用户信息？
这些问题都可以通过网关 技术解决。
网关路由 网关就是网络的关口。数据在网络间传输，从一个网络传输到另一网络时就需要经过网关来做数据的路由和转发以及数据安全的校验。微服务网关起到同样的作用。前端请求不能直接访问微服务，而是要请求网关：
网关可以做安全控制，也就是登录身份校验，校验通过才放行
通过认证后，网关再根据请求判断应该访问哪个微服务，将请求转发过去
在SpringCloud当中，提供了两种网关实现方案：
Netflix Zuul：早期实现，目前已经淘汰
SpringCloudGateway：基于Spring的WebFlux技术，完全支持响应式编程，吞吐能力更强
这里学习SpringCloudGateway
快速入门 由于网关本身也是一个独立的微服务，因此也需要创建一个模块开发功能。大概步骤如下：
创建网关微服务
引入SpringCloudGateway、NacosDiscovery依赖
编写启动类
配置网关路由
引入依赖 创建微服务后，在pom.xml文件中引入依赖：
<dependencies > <dependency > <groupId > com.heima</groupId > <artifactId > hm-common</artifactId > <version > 1.0.0</version > </dependency > <dependency > <groupId > org.springframework.cloud</groupId > <artifactId > spring-cloud-starter-gateway</artifactId > </dependency > <dependency > <groupId > com.alibaba.cloud</groupId > <artifactId > spring-cloud-starter-alibaba-nacos-discovery</artifactId > </dependency > <dependency > <groupId > org.springframework.cloud</groupId > <artifactId > spring-cloud-starter-loadbalancer</artifactId > </dependency > </dependencies >
配置路由 在application.yaml文件中添加配置：
server: port: 8080 spring: application: name: gateway cloud: nacos: server-addr: 192.168 .145 .128 :8848 gateway: routes: - id: item uri: lb://service predicates: - Path=/items/**,/search/** - id: cart uri: lb://cart-service predicates: - Path=/carts/** - id: user uri: lb://user-service predicates: - Path=/users/**,/addresses/** - id: trade uri: lb://trade-service predicates: - Path=/orders/** - id: pay uri: lb://pay-service predicates: - Path=/pay-orders/**
路由过滤 路由规则的定义语法如下：
spring: cloud: gateway: routes: - id: item uri: lb://item-service predicates: - Path=/items/**,/search/**
其中routes对应的类型为：
@NotNull @Valid private List<RouteDefinition> routes = new ArrayList <>();
是一个集合，也就是说可以定义很多路由规则。集合中的RouteDefinition就是具体的路由规则定义，其中常见的属性如下：
@Validated public class RouteDefinition { private String id; private @NotEmpty @Valid List<PredicateDefinition> predicates = new ArrayList (); private @Valid List<FilterDefinition> filters = new ArrayList (); private @NotNull URI uri; }
id：路由的唯一标示predicates：路由断言，其实就是匹配条件filters：路由过滤条件，后面讲uri：路由目标地址，lb://代表负载均衡，从注册中心获取目标微服务的实例列表，并且负载均衡选择一个访问。
这里重点关注predicates，也就是路由断言。SpringCloudGateway中支持的断言类型有很多：
名称 说明 示例
After
是某个时间点后的请求
- After=2037-01-20T17:42:47.789-07:00[America/Denver]
Before
是某个时间点之前的请求
- Before=2031-04-13T15:14:47.433+08:00[Asia/Shanghai]
Between
是某两个时间点之前的请求
- Between=2037-01-20T17:42:47.789-07:00[America/Denver], 2037-01-21T17:42:47.789-07:00[America/Denver]
Cookie
请求必须包含某些cookie
- Cookie=chocolate, ch.p
Header
请求必须包含某些header
- Header=X-Request-Id, \d+
Host
请求必须是访问某个host（域名）
- Host=.somehost.org, .anotherhost.org
Method
请求方式必须是指定方式
- Method=GET,POST
Path
请求路径必须符合指定规则
- Path=/red/{segment},/blue/**
Query
请求参数必须包含指定参数
- Query=name, Jack或者- Query=name
RemoteAddr
请求者的ip必须是指定范围
- RemoteAddr=192.168.1.1/24
weight
权重处理
网关登录校验 单体架构时只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。而微服务拆分后，每个微服务都独立部署，不再共享数据。也就意味着每个微服务都需要做登录校验，这显然不可取。
网关过滤器 登录校验必须在请求转发到微服务之前做，否则就失去了意义。而网关的请求转发是Gateway内部代码实现的，要想在请求转发之前做登录校验，就必须了解Gateway内部工作的基本原理。
客户端请求进入网关后由HandlerMapping对请求做判断，找到与当前请求匹配的路由规则（**Route**），然后将请求交给WebHandler去处理。
WebHandler则会加载当前路由下需要执行的过滤器链（**Filter chain），然后按照顺序逐一执行过滤器（后面称为 Filter**）。Filter被分为左右两部分，是因为Filter内部的逻辑分为pre和post两部分，分别会在请求路由到微服务之前 和之后 被执行。只有所有Filter的pre逻辑都依次顺序执行通过后，请求才会被路由到微服务。
微服务返回结果后，再倒序执行Filter的post逻辑。
最终把响应结果返回。
最终请求转发是有一个名为NettyRoutingFilter的过滤器来执行的，而且这个过滤器是整个过滤器链中顺序最靠后的一个。如果能够定义一个过滤器，在其中实现登录校验逻辑，并且将过滤器执行顺序定义到NettyRoutingFilter之前，这就符合需求了
网关过滤器链中的过滤器有两种：
**GatewayFilter**：路由过滤器，作用范围比较灵活，可以是任意指定的路由Route.
**GlobalFilter**：全局过滤器，作用范围是所有路由，不可配置
FilteringWebHandler在处理请求时，会将GlobalFilter装饰为GatewayFilter，然后放到同一个过滤器链中，排序以后依次执行。
Gateway中内置了很多的GatewayFilter，详情可以参考官方文档
Gateway内置的GatewayFilter过滤器使用起来非常简单，无需编码，只要在yaml文件中简单配置即可。而且其作用范围也很灵活，配置在哪个Route下，就作用于哪个Route
例如，有一个过滤器叫做AddRequestHeaderGatewayFilterFacotry，即添加请求头的过滤器，可以给请求添加一个请求头并传递到下游微服务。只需要在application.yaml中添加配置：
spring: cloud: gateway: routes: - id: test_route uri: lb://test-service predicates: -Path=/test/** filters: - AddRequestHeader=key, value
如果想要让过滤器作用于所有的路由，则可以这样配置：
spring: cloud: gateway: default-filters: - AddRequestHeader=key, value routes: - id: test_route uri: lb://test-service predicates: -Path=/test/**
自定义过滤器 GatewayFilter和GlobalFilter都支持自定义，只不过编码 方式、使用 方式略有差别
自定义GatewayFilter 自定义GatewayFilter不是直接实现GatewayFilter，而是实现AbstractGatewayFilterFactory
@Component public class PrintAnyGatewayFilterFactory extends AbstractGatewayFilterFactory <Object> { @Override public GatewayFilter apply (Object config) { return new GatewayFilter () { @Override public Mono<Void> filter (ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request = exchange.getRequest(); System.out.println("过滤器执行" ); return chain.filter(exchange); } }; } }
注意 ：该类的名称一定要以GatewayFilterFactory为后缀
然后在yaml配置中这样使用：
spring: cloud: gateway: default-filters: - PrintAny
另外，这种过滤器还可以支持动态配置参数，不过实现起来比较复杂：
@Component public class PrintAnyGatewayFilterFactory extends AbstractGatewayFilterFactory <PrintAnyGatewayFilterFactory.Config> { @Override public GatewayFilter apply (Config config) { return new OrderedGatewayFilter (new GatewayFilter () { @Override public Mono<Void> filter (ServerWebExchange exchange, GatewayFilterChain chain) { String a = config.getA(); String b = config.getB(); String c = config.getC(); System.out.println("a = " + a); System.out.println("b = " + b); System.out.println("c = " + c); return chain.filter(exchange); } }, 100 ); } @Data static class Config { private String a; private String b; private String c; } @Override public List<String> shortcutFieldOrder () { return List.of("a" , "b" , "c" ); } @Override public Class<Config> getConfigClass () { return Config.class; } }
然后在yaml文件中使用：
spring: cloud: gateway: default-filters: - PrintAny=1,2,3
上面这种配置方式参数必须严格按照shortcutFieldOrder()方法的返回参数名顺序来赋值。
还有一种用法，无需按照这个顺序，就是手动指定参数名：
spring: cloud: gateway: default-filters: - name: PrintAny args: a: 1 b: 2 c: 3
自定义GlobalFilter 自定义GlobalFilter则简单很多，直接实现GlobalFilter即可，无法设置动态参数：
@Component public class PrintAnyGlobalFilter implements GlobalFilter , Ordered { @Override public Mono<Void> filter (ServerWebExchange exchange, GatewayFilterChain chain) { System.out.println("未登录，无法访问" ); ServerHttpResponse response = exchange.getResponse(); response.setRawStatusCode(401 ); return response.setComplete(); } @Override public int getOrder () { return 0 ; } }
微服务获取用户 当网关将请求转发到微服务时，微服务又该如何获取用户身份呢？
由于网关发送请求到微服务依然采用的是Http请求，因此可以将用户信息以请求头的方式传递到微服务。然后微服务可以从请求头中获取登录用户信息。考虑到微服务内部可能很多地方都需要用到登录用户信息，因此我们可以利用SpringMVC的拦截器来实现登录用户信息获取，并存入ThreadLocal，方便后续使用。
具体实现 首先，我们修改登录校验拦截器的处理逻辑，保存用户信息到请求头中：
String userInfo = userId.toString();ServerWebExchange ex = exchange.mutate().request(b -> b.header("user-info" , userInfo)).build();
拦截器获取用户 定义拦截器：
public class UserInfoInterceptor implements HandlerInterceptor { @Override public boolean preHandle (HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String userInfo = request.getHeader("user-info" ); if (StrUtil.isNotBlank(userInfo)) { UserContext.setUser(Long.valueOf(userInfo)); } return true ; } @Override public void afterCompletion (HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { UserContext.removeUser(); } }
配置登录拦截器：
@Configuration @ConditionalOnClass(DispatcherServlet.class) public class MvcConfig implements WebMvcConfigurer { @Override public void addInterceptors (InterceptorRegistry registry) { registry.addInterceptor(new UserInfoInterceptor ()); } }
OpenFeign传递用户 前端发起的请求都会经过网关再到微服务，由于我们之前编写的过滤器和拦截器功能，微服务可以轻松获取登录用户信息。
但有些业务是比较复杂的，请求到达微服务后还需要调用其它多个微服务。比如下单业务，下单的过程中，需要调用商品服务扣减库存，调用购物车服务清理用户购物车。而清理购物车时必须知道当前登录的用户身份。但是，订单服务调用购物车时并没有传递用户信息 ，购物车服务无法知道当前用户是谁
由于微服务获取用户信息是通过拦截器在请求头中读取，因此要想实现微服务之间的用户信息传递，就必须在微服务发起调用时把用户信息存入请求头 。
微服务之间调用是基于OpenFeign来实现的，并不是我们自己发送的请求。我们如何才能让每一个由OpenFeign发起的请求自动携带登录用户信息呢？
这里要借助Feign中提供的一个拦截器接口：feign.RequestInterceptor
public interface RequestInterceptor { void apply (RequestTemplate template) ; }
只需要实现这个接口，然后实现apply方法，利用RequestTemplate类来添加请求头，将用户信息保存到请求头中。这样以来，每次OpenFeign发起请求的时候都会调用该方法，传递用户信息。
@Bean public RequestInterceptor userInfoRequestInterceptor () { return new RequestInterceptor () { @Override public void apply (RequestTemplate template) { Long userId = UserContext.getUser(); if (userId == null ) { return ; } template.header("user-info" , userId.toString()); } }; }
配置管理 现在依然还有几个问题需要解决：
网关路由在配置文件中写死了，如果变更必须重启微服务
某些业务配置在配置文件中写死了，每次修改都要重启服务
每个微服务都有很多重复的配置，维护成本高
这些问题都可以通过统一的配置管理器服务 解决。而Nacos不仅仅具备注册中心功能，也具备配置管理的功能：
微服务共享的配置可以统一交给Nacos保存和管理，在Nacos控制台修改配置后，Nacos会将配置变更推送给相关的微服务，并且无需重启即可生效，实现配置热更新。
网关的路由同样是配置，因此同样可以基于这个功能实现动态路由功能，无需重启网关即可修改路由配置。
共享配置 我们可以把微服务共享的配置抽取到Nacos中统一管理，这样就不需要每个微服务都重复配置了。分为两步：
添加共享配置 在nacos控制台分别添加这些配置。
首先是jdbc相关配置，在配置管理->配置列表中点击+新建一个配置：
在弹出的表单中填写信息：
jdbc的相关参数并没有写死，例如：
数据库ip：通过${hm.db.host:192.168.145.128}配置了默认值为，同时允许通过${hm.db.host}来覆盖默认值数据库端口：通过${hm.db.port:3306}配置了默认值为3306，同时允许通过${hm.db.port}来覆盖默认值数据库database：可以通过${hm.db.database}来设定
拉取共享配置 接下来要在微服务拉取共享配置。将拉取到的共享配置与本地的application.yaml配置合并，完成项目上下文的初始化。
不过，需要注意的是，读取Nacos配置是SpringCloud上下文（ApplicationContext）初始化时处理的，发生在项目的引导阶段。然后才会初始化SpringBoot上下文，去读取application.yaml。
也就是说引导阶段，application.yaml文件尚未读取，根本不知道nacos地址，该如何去加载nacos中的配置文件呢？
SpringCloud在初始化上下文的时候会先读取一个名为bootstrap.yaml(或者bootstrap.properties)的文件，如果我们将nacos地址配置到bootstrap.yaml中，那么在项目引导阶段就可以读取nacos中的配置了
因此，微服务整合Nacos配置管理的步骤如下：
1）引入依赖：
引入依赖：
<dependency > <groupId > com.alibaba.cloud</groupId > <artifactId > spring-cloud-starter-alibaba-nacos-config</artifactId > </dependency > <dependency > <groupId > org.springframework.cloud</groupId > <artifactId > spring-cloud-starter-bootstrap</artifactId > </dependency >
2）新建bootstrap.yaml
在的resources目录新建一个bootstrap.yaml文件：
spring: application: name: cart-service profiles: active: dev cloud: nacos: server-addr: 192.168 .150 .101 config: file-extension: yaml shared-configs: - dataId: shared-jdbc.yaml - dataId: shared-log.yaml - dataId: shared-swagger.yaml
3）修改application.yaml
server: port: 8082 feign: okhttp: enabled: true hm: swagger: title: 购物车服务接口文档 package: com.hmall.cart.controller db: database: hm-cart
重启服务，使配置生效
配置热更新 目前的项目修改了配置需要重新打包、重启服务才能生效。能不能不用重启，直接生效呢？
这就要用到Nacos的配置热更新能力了，分为两步：
添加配置到Nacos 首先在nacos中添加一个配置文件，注意文件的dataId格式：
[服务名]-[spring.active.profile].[后缀名]
文件名称由三部分组成：
服务名**spring.active.profile**：就是spring boot中的spring.active.profile，可以省略，则所有profile共享该配置
后缀名
配置热更新 接着，我们在微服务中读取配置，实现配置热更新。
@Data @Component @ConfigurationProperties(prefix = "test.cart") public class CartProperties { private Integer maxAmount; }
动态路由 网关的路由配置全部是在项目启动时由org.springframework.cloud.gateway.route.CompositeRouteDefinitionLocator在项目启动的时候加载，并且一经加载就会缓存到内存中的路由表内（一个Map），不会改变。也不会监听路由变更
因此，我们必须监听Nacos的配置变更，然后手动把最新的路由更新到路由表中。这里有两个难点：
如何监听Nacos配置变更？
如何把路由信息更新到路由表？
监听Nacos配置变更 在Nacos官网中给出了手动监听Nacos配置变更的SDK
如果希望Nacos推送配置变更，可以使用Nacos动态监听配置接口来实现
public void addListener (String dataId, String group, Listener listener)
请求参数说明：
参数名 参数类型 描述
dataId
string
配置 ID，保证全局唯一性，只允许英文字符和 4 种特殊字符（”.”、”:”、”-“、”_”）。不超过 256 字节
group
string
配置分组，一般是默认的DEFAULT_GROUP
listener
Listener
监听器，配置变更进入监听器的回调函数
示例：
String serverAddr = "{serverAddr}" ;String dataId = "{dataId}" ;String group = "{group}" ;Properties properties = new Properties ();properties.put("serverAddr" , serverAddr); ConfigService configService = NacosFactory.createConfigService(properties);String content = configService.getConfig(dataId, group, 5000 );configService.addListener(dataId, group, new Listener () { @Override public void receiveConfigInfo (String configInfo) { System.out.println("recieve1:" + configInfo); } @Override public Executor getExecutor () { return null ; } });
这里核心的步骤有2步：
创建ConfigService，目的是连接到Nacos
添加配置监听器，编写配置变更的通知处理逻辑
这里采用了spring-cloud-starter-alibaba-nacos-config自动装配，因此ConfigService已经在com.alibaba.cloud.nacos.NacosConfigAutoConfiguration中自动创建好了
因此只要拿到NacosConfigManager就等于拿到了ConfigService，第一步就实现了。
第二步，编写监听器。虽然官方提供的SDK是ConfigService中的addListener，不过项目第一次启动时不仅仅需要添加监听器，也需要读取配置，因此建议使用的API是这个：
String getConfigAndSignListener ( String dataId, // 配置文件id String group, // 配置组，走默认 long timeoutMs, // 读取配置的超时时间 Listener listener // 监听器 ) throws NacosException;
既可以配置监听器，并且会根据dataId和group读取配置并返回。我们就可以在项目启动时先更新一次路由，后续随着配置变更通知到监听器，完成路由更新。
更新路由 更新路由要用到org.springframework.cloud.gateway.route.RouteDefinitionWriter接口：
public interface RouteDefinitionWriter { Mono<Void> save (Mono<RouteDefinition> route) ; Mono<Void> delete (Mono<String> routeId) ; }
这里更新的路由，也就是RouteDefinition，包含下列常见字段：
id：路由id
predicates：路由匹配规则
filters：路由过滤器
uri：路由目的地
将来我们保存到Nacos的配置也要符合这个对象结构，将来我们以JSON来保存，格式如下：
{ "id" : "item" , "predicates" : [ { "name" : "Path" , "args" : { "_genkey_0" : "/items/**" , "_genkey_1" : "/search/**" } } ] , "filters" : [ ] , "uri" : "lb://item-service" }
以上JSON配置就等同于：
spring: cloud: gateway: routes: - id: item uri: lb://item-service predicates: - Path=/items/**,/search/**
实现动态路由 在网关gateway引入依赖：
<dependency > <groupId > com.alibaba.cloud</groupId > <artifactId > spring-cloud-starter-alibaba-nacos-config</artifactId > </dependency > <dependency > <groupId > org.springframework.cloud</groupId > <artifactId > spring-cloud-starter-bootstrap</artifactId > </dependency >
然后在网关gateway的resources目录创建bootstrap.yaml文件，内容如下：
spring: application: name: gateway cloud: nacos: server-addr: 192.168 .145 .128 config: file-extension: yaml shared-configs: - dataId: shared-log.yaml
接着，修改gateway的resources目录下的application.yml，把之前的路由移除，最终内容如下：
server: port: 8080 hm: jwt: location: alias: password: tokenTTL: 30m auth: excludePaths: - /search/** - /users/login - /items/**
然后，在gateway中定义配置监听器
@Slf4j @Component @RequiredArgsConstructor public class DynamicRouteLoader { private final RouteDefinitionWriter writer; private final NacosConfigManager nacosConfigManager; private final String dataId = "gateway-routes.json" ; private final String group = "DEFAULT_GROUP" ; private final Set<String> routeIds = new HashSet <>(); @PostConstruct public void initRouteConfigListener () throws NacosException { String configInfo = nacosConfigManager.getConfigService() .getConfigAndSignListener(dataId, group, 5000 , new Listener () { @Override public Executor getExecutor () { return null ; } @Override public void receiveConfigInfo (String configInfo) { updateConfigInfo(configInfo); } }); updateConfigInfo(configInfo); } private void updateConfigInfo (String configInfo) { log.debug("监听到路由配置变更，{}" , configInfo); List<RouteDefinition> routeDefinitions = JSONUtil.toList(configInfo, RouteDefinition.class); for (String routeId : routeIds) { writer.delete(Mono.just(routeId)).subscribe(); } routeIds.clear(); if (CollUtils.isEmpty(routeDefinitions)) { return ; } routeDefinitions.forEach(routeDefinition -> { writer.save(Mono.just(routeDefinition)).subscribe(); routeIds.add(routeDefinition.getId()); }); } }
直接在Nacos控制台添加路由，即可实现动态配置路由。
