首先的话还是感谢黑马提供的快速入门课程。当然，仅仅是快速入门。
视频如下：
https://www.bilibili.com/video/BV1kH4y1S7wz/?share_source=copy_web&vd_source=3362e6914fb759983690e6e0f1072453
在课前资料中给大家提供了黑马商城项目的资料，先导入这个单体项目。不过需要注意的是，你必须做好一些准备：
Centos7的环境及一个好用的SSH客户端
安装好Docker
会使用Docker
如果你没有这样的Linux环境，或者不是Centos7的话，那么这里有一篇参考文档：
建议按照上面的文档来搭建虚拟机环境，使用其它版本会出现一些环境问题，比较痛苦。
如果已经有Linux环境，但是没有安装Docker的话，那么这里还有一篇参考文档：
微服务 微服务架构，首先是服务化，就是将单体架构中的功能模块从单体应用中拆分出来，独立部署为多个服务。同时要满足下面的一些特点：
单一职责 ：一个微服务负责一部分业务功能，并且其核心数据不依赖于其它模块。团队自治 ：每个微服务都有自己独立的开发、测试、发布、运维人员，团队人员规模不超过10人（2张披萨能喂饱）服务自治 ：每个微服务都独立打包部署，访问自己独立的数据库。并且要做好服务隔离，避免对其它服务产生影响
例如，黑马商城项目，我们就可以把商品、用户、购物车、交易等模块拆分，交给不同的团队去开发，并独立部署：
那么，单体架构存在的问题有没有解决呢？
团队协作成本高？
由于服务拆分，每个服务代码量大大减少，参与开发的后台人员在1~3名，协作成本大大降低
系统发布效率低？
每个服务都是独立部署，当有某个服务有代码变更时，只需要打包部署该服务即可
系统可用性差？
每个服务独立部署，并且做好服务隔离，使用自己的服务器资源，不会影响到其它服务。
综上所述，微服务架构解决了单体架构存在的问题，特别适合大型互联网项目的开发，因此被各大互联网公司普遍采用。大家以前可能听说过分布式架构，分布式就是服务拆分的过程，其实微服务架构正式分布式架构的一种最佳实践的方案。
SpringCloud 其中我们将会学到Nacos，OpenFeign,Gateway,Sentinel的使用
而且SpringCloud依托于SpringBoot的自动装配能力，大大降低了其项目搭建、组件使用的成本。对于没有自研微服务组件能力的中小型企业，使用SpringCloud全家桶来实现微服务开发可以说是最合适的选择了！
单体项目拆分为微服务 将每个板块单独拆分出来，变成一个个微服务。比如，购物车、商品、支付、用户这些都能够提取为单独的一个模块。
怎么拆 之前我们说过，微服务拆分时粒度要小 ，这其实是拆分的目标。具体可以从两个角度来分析：
高内聚 ：每个微服务的职责要尽量单一，包含的业务相互关联度高、完整度高。低耦合 ：每个微服务的功能要相对独立，尽量减少对其它微服务的依赖，或者依赖接口的稳定性要强。
高内聚 首先是单一职责， 但不能说一个微服务就一个接口，而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时，最好就只修改当前微服务，这样变更的成本更低。
一旦微服务做到了高内聚，那么服务之间的耦合度 自然就降低了。
当然，微服务之间不可避免的会有或多或少的业务交互，比如下单时需要查询商品数据 。这个时候我们不能在订单服务直接查询商品数据库，否则就导致了数据耦合。而应该由商品服务对应暴露接口 ，并且一定要保证微服务对外接口的稳定性 （即：尽量保证接口外观不变）。虽然出现了服务间调用，但此时无论你如何在商品服务做内部修改，都不会影响到订单微服务，服务间的耦合度就降低了。
明确了拆分目标，接下来就是拆分方式了。我们在做服务拆分时一般有两种方式：
所谓纵向拆分 ，就是按照项目的功能模块来拆分。例如黑马商城中，就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务，就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。
而横向拆分 ，是看各个功能模块之间有没有公共的业务部分，如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知，记录风控数据，下单时也要发送短信，记录风控数据。因此消息发送、风控数据记录就是通用的业务功能，因此可以将他们分别抽取为公共服务：消息中心服务、风控管理服务。这样可以提高业务的复用性，避免重复开发。同时通用业务一般接口稳定性较强，也不会使服务之间过分耦合。
一般微服务项目有两种不同的工程结构：
完全解耦：每一个微服务都创建为一个独立的工程，甚至可以使用不同的开发语言来开发，项目完全解耦。
优点：服务之间耦合度低
缺点：每个项目都有自己的独立仓库，管理起来比较麻烦
Maven聚合：整个项目为一个Project，然后每个微服务是其中的一个Module
优点：项目代码集中，管理和运维方便（授课也方便）
缺点：服务之间耦合，编译时间较长
我们这里使用纵向拆分的形式，以及Maven聚合。
拆分的时候，可以优先把controller拆过去，如果合理的话，一般名字就已经对应好了。然后根据引入的类再进行迁移。
拆分环境就不多说了，这里变化很多，最好根据实际情况灵活变通。
服务调用 拆分后不可避免的出现很多的问题。由于项目之间完全没有耦合，也就意味着，两个微服务之间无法进行相互调用，显然是不行的，就像购物车不可能不调用商品服务。而且大多数服务也都需要获取用户信息啊。
因此要想解决这个问题，我们就必须改造其中的代码，把原本本地方法调用，改造成跨微服务的远程调用（RPC ，即R emote P roduce C all）。
因此，现在查询购物车列表的流程变成了这样：
代码中需要变化的就是这一步：
类似思路的话，就跟我们前端获取数据，或者使用爬虫的时候很类似。通过使用http请求去调用。
RestTemplate
Spring给我们提供了RestTemplate的APi，可以方便实现发送Http请求（也可用来搞爬虫）
先将RestTemplate注册为一个Bean：
package com.hmall.cart.config;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;import org.springframework.web.client.RestTemplate;@Configuration public class RemoteCallConfig { @Bean public RestTemplate restTemplate () { return new RestTemplate (); } }
使用方法：
ResponseEntity<List<ItemDTO>> exchange = restTemplate.exchange( "http://localhost:8081/items?ids={ids}" , HttpMethod.GET, null , new ParameterizedTypeReference <List<ItemDTO>>() {}, Map.of("ids" ,CollUtils.join(itemIds, "," )) ); if (!response.getStatusCode().is2xxSuccessful()){ return ; } List<ItemDTO> items = response.getBody();
爬虫用起来也还好，其实主要是信息筛选老火
@Test public void TestRestTemplate () { ResponseEntity<String> exchange = restTemplate.exchange( "https://www.bing.com/images/search?q=明日方舟德克萨斯" , HttpMethod.GET, null , new ParameterizedTypeReference <String>() { } ); String body = exchange.getBody(); System.out.println("body = " + body); }
服务注册 上述调用我们也发现了问题，就是必须知道调用的具体地址，但是实际开发我们都分成好几个小组了，总不能每次改端口都口口相传，那服务宕机了该怎么办？
item-service这么多实例，cart-service如何知道每一个实例的地址？
http请求要写url地址，cart-service服务到底该调用哪个实例呢？
如果在运行过程中，某一个item-service实例宕机，cart-service依然在调用该怎么办？
如果并发太高，item-service临时多部署了N台实例，cart-service如何知道新实例的地址？
为了解决上述问题，就必须引入注册中心的概念了，接下来我们就一起来分析下注册中心的原理。
注册中心原理 其实就有点类似于学校管理一样，只不过这个更快。
在微服务远程调用的过程中，包括两个角色：
服务提供者：提供接口供其它微服务访问，比如item-service
服务消费者：调用其它微服务提供的接口，比如cart-service
在大型微服务项目中，服务提供者的数量会非常多，为了管理这些服务就引入了注册中心 的概念。注册中心、服务提供者、服务消费者三者间关系如下：
流程如下：
服务启动时就会注册自己的服务信息（服务名、IP、端口）到注册中心
调用者可以从注册中心订阅想要的服务，获取服务对应的实例列表（1个服务可能多实例部署）
调用者自己对实例列表负载均衡，挑选一个实例
调用者向该实例发起远程调用
当服务提供者的实例宕机或者启动新实例时，调用者如何得知呢？
服务提供者会定期向注册中心发送请求，报告自己的健康状态（心跳请求）
当注册中心长时间收不到提供者的心跳时，会认为该实例宕机，将其从服务的实例列表中剔除
当服务有新实例启动时，会发送注册服务请求，其信息会被记录在注册中心的服务实例列表
当注册中心服务列表变更时，会主动通知微服务，更新本地服务列表
就跟老师找学生一样,不需要到处找,去教务系统查询你的相关信息然后去教室或者你家堵你就行了.(额,别杠,不然你对)
Nacos 目前开源的注册中心框架有很多，国内比较常见的有：
Eureka：Netflix公司出品，目前被集成在SpringCloud当中，一般用于Java应用
Nacos：Alibaba公司出品，目前被集成在SpringCloudAlibaba中，一般用于Java应用
Consul：HashiCorp公司出品，目前集成在SpringCloud中，不限制微服务语言
使用Nacos前,需要使用数据库保存一些信息,所以先准备好MySQL数据库表.
-- -------------------------------------------------------- -- 主机: 192.168.87.132 -- 服务器版本: 8.0.27 - MySQL Community Server - GPL -- 服务器操作系统: Linux -- HeidiSQL 版本: 12.2.0.6576 -- -------------------------------------------------------- /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET NAMES utf8 */; /*!50503 SET NAMES utf8mb4 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */; -- 导出 nacos 的数据库结构 DROP DATABASE IF EXISTS `nacos`; CREATE DATABASE IF NOT EXISTS `nacos` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci */ /*!80016 DEFAULT ENCRYPTION='N' */; USE `nacos`; -- 导出 表 nacos.config_info 结构 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'; -- 正在导出表 nacos.config_info 的数据：~0 rows (大约) DELETE FROM `config_info`; -- 导出 表 nacos.config_info_aggr 结构 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='增加租户字段'; -- 正在导出表 nacos.config_info_aggr 的数据：~0 rows (大约) DELETE FROM `config_info_aggr`; -- 导出 表 nacos.config_info_beta 结构 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'; -- 正在导出表 nacos.config_info_beta 的数据：~0 rows (大约) DELETE FROM `config_info_beta`; -- 导出 表 nacos.config_info_tag 结构 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'; -- 正在导出表 nacos.config_info_tag 的数据：~0 rows (大约) DELETE FROM `config_info_tag`; -- 导出 表 nacos.config_tags_relation 结构 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'; -- 正在导出表 nacos.config_tags_relation 的数据：~0 rows (大约) DELETE FROM `config_tags_relation`; -- 导出 表 nacos.group_capacity 结构 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容量信息表'; -- 正在导出表 nacos.group_capacity 的数据：~0 rows (大约) DELETE FROM `group_capacity`; -- 导出 表 nacos.his_config_info 结构 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='多租户改造'; -- 正在导出表 nacos.his_config_info 的数据：~0 rows (大约) DELETE FROM `his_config_info`; -- 导出 表 nacos.permissions 结构 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; -- 正在导出表 nacos.permissions 的数据：~0 rows (大约) DELETE FROM `permissions`; -- 导出 表 nacos.roles 结构 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; -- 正在导出表 nacos.roles 的数据：~1 rows (大约) DELETE FROM `roles`; INSERT INTO `roles` (`username`, `role`) VALUES ('nacos', 'ROLE_ADMIN'); -- 导出 表 nacos.tenant_capacity 结构 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='租户容量信息表'; -- 正在导出表 nacos.tenant_capacity 的数据：~0 rows (大约) DELETE FROM `tenant_capacity`; -- 导出 表 nacos.tenant_info 结构 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'; -- 正在导出表 nacos.tenant_info 的数据：~0 rows (大约) DELETE FROM `tenant_info`; -- 导出 表 nacos.users 结构 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; -- 正在导出表 nacos.users 的数据：~1 rows (大约) DELETE FROM `users`; INSERT INTO `users` (`username`, `password`, `enabled`) VALUES ('nacos', '$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu', 1); /*!40103 SET TIME_ZONE=IFNULL(@OLD_TIME_ZONE, 'system') */; /*!40101 SET SQL_MODE=IFNULL(@OLD_SQL_MODE, '') */; /*!40014 SET FOREIGN_KEY_CHECKS=IFNULL(@OLD_FOREIGN_KEY_CHECKS, 1) */; /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; /*!40111 SET SQL_NOTES=IFNULL(@OLD_SQL_NOTES, 1) */;
其中的nacos/custom.env文件中，有一个MYSQL_SERVICE_HOST也就是mysql地址
PREFER_HOST_MODE =hostname MODE =standalone SPRING_DATASOURCE_PLATFORM =mysql MYSQL_SERVICE_HOST =192.168.87.132 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
使用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
Java项目中添加下列依赖
<dependency > <groupId > com.alibaba.cloud</groupId > <artifactId > spring-cloud-starter-alibaba-nacos-discovery</artifactId > </dependency >
yml配置
spring: application: name: item-service cloud: nacos: server-addr: 192.168 .78 .132 :8848
启动项目后就可以看到nacos控制台中,服务列表有对应内容.
服务发现 服务的消费者要去nacos订阅服务，这个过程就是服务发现，步骤如下：
提供者和消费者都需要在nacos中进行注册
服务发现需要用到一个工具，DiscoveryClient，SpringCloud已经帮我们自动装配，我们可以直接注入使用：
List<ServiceInstance> instances = discoveryClient.getInstances("item-service" ); ServiceInstance instance = instances.get(RandomUtil.randomInt(instances.size())); URI uri = instance.getUri(); ResponseEntity<List<ItemDTO>> exchange = restTemplate.exchange( uri+"/items?ids={ids}" , HttpMethod.GET, null , new ParameterizedTypeReference <List<ItemDTO>>() { }, Map.of("ids" ,CollUtils.join(itemIds, "," )) );
这里主要就是能实现动态化.有新服务的时候可以得知,服务死了也能得知并更换.且无需重启项目!(这里的原理我觉得有必要了解一下)
OpenFeign 使用RestTemplate加上Nacos后虽然灵活,但是感觉挺麻烦的,而且由于灵活的话,包装为一个函数感觉更不太容易了.
所以可以使用接口的形式进行统一.
我感觉更重要的是,微服务调用更偏向于本地调用,用Rest Template调用浏览器那些更舒服.
远程调用的关键点就在于四个：
OpenFeign就利用SpringMVC的相关注解来声明上述4个参数，然后基于动态代理帮我们生成远程调用的代码，而无需我们手动再编写，非常方便。
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客户端 @FeignClient(value = "item-service", // 服务名称,在Application.yaml中有配置 configuration = DefaultConfig.class, fallbackFactory = ItemClientFallback.class) public interface ItemClient { @GetMapping("/items") List<ItemDTO> queryItemByIds (@RequestParam Collection<Long> ids) ; @PutMapping("/items/stock/deduct") public void deductStock (@RequestBody List<OrderDetailDTO>items) ; }
可以看到,跟mvc的使用很类似.
其他服务调用时只需要依赖注入ItemClient,然后就能直接进行使用
连接池(了解?) Feign底层发起http请求，依赖于其它的框架。其底层支持的http客户端实现包括：
HttpURLConnection：默认实现，不支持连接池
Apache HttpClient ：支持连接池
OKHttp：支持连接池
因此我们通常会使用带有连接池的客户端来代替默认的HttpURLConnection。比如，我们使用OK Http.
在cart-service的pom.xml中引入依赖：
<dependency > <groupId > io.github.openfeign</groupId > <artifactId > feign-okhttp</artifactId > </dependency >
在cart-service的application.yml配置文件中开启Feign的连接池功能：
feign: okhttp: enabled: true
重启服务，连接池就生效了。
抽取客户端 刚刚的实践中不难发现,由于服务之间已经隔离,采用http远程调用就能获取数据了,但是的话就算使用Openfegin后代码仍会很冗余,毕竟远程调用的地方很多,那代码重复也会很多,我们需要在每个微服务都建立很多个客户端?
避免重复编码的办法就是抽取 。不过这里有两种抽取思路：
思路1：抽取到微服务之外的公共module
思路2：每个微服务自己抽取一个module
如图：
方案1抽取更加简单，工程结构也比较清晰，但缺点是整个项目耦合度偏高。
方案2抽取相对麻烦，工程结构相对更复杂，但服务之间耦合度降低。
第一种的话我是比较喜欢的,虽然会引入其他用不着的客户端.第二种感觉pom文件会很不得了.
(其实吧,是快速入门用第一种,两种还是根据实际情况分析)
第一种也有点冗余的,毕竟你得把dto也搞到api模块里面,所以第二种感觉适合大型项目
使用时,在service的启动类上添加声明即可，两种方式：
网关 在微服务中,用户登录后得到的jwt令牌怎么传递是个问题.当然使用redis存储是个办法(我个人想到的是这种方法)
认识网关 顾明思议，网关就是网 络的关 口。数据在网络间传输，从一个网络传输到另一网络时就需要经过网关来做数据的路由和转发以及数据安全的校验 。
更通俗的来讲，网关就像是以前园区传达室的大爷。
外面的人要想进入园区，必须经过大爷的认可，如果你是不怀好意的人，肯定被直接拦截。
外面的人要传话或送信，要找大爷。大爷帮你带给目标人。
现在，微服务网关就起到同样的作用。前端请求不能直接访问微服务，而是要请求网关：
网关可以做安全控制，也就是登录身份校验，校验通过才放行
通过认证后，网关再根据请求判断应该访问哪个微服务，将请求转发过去
感觉有点类似于设计模式的门卫模式?
O(∩_∩)O
我们这里采用SpringcloudGateway实现网关功能
SpringCloudGateway：基于Spring的WebFlux技术，完全支持响应式编程，吞吐能力更强
官方网站：
https://spring.io/projects/spring-cloud-gateway#learn
大概步骤如下：
创建网关微服务
引入SpringCloudGateway、NacosDiscovery依赖
编写启动类
配置网关路由
额,可以发现,又用到了nacos.毕竟守门老大爷也需要知道名册表查询啊.
gateway模块引入依赖
<artifactId > hm-gateway</artifactId > <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 > <build > <finalName > ${project.artifactId}</finalName > <plugins > <plugin > <groupId > org.springframework.boot</groupId > <artifactId > spring-boot-maven-plugin</artifactId > </plugin > </plugins > </build > </project >
配置路由 server: port: 8080 //正好前端请求的是8080端口 spring: application: name: gateway cloud: nacos: server-addr: 192.168 .150 .101 :8848 gateway: routes: - id: item uri: lb://item-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/**
路由过滤 这里的话就耗子尾汁吧.感觉没怎么用上这里.
感觉后面可以做很多文章.这种加请求头,和过滤啊什么的
网关登录校验 单体架构时我们只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。而微服务拆分后，每个微服务都独立部署，不再共享数据。也就意味着每个微服务都需要做登录校验，这显然不可取。
鉴权思路分析 我们的登录是基于JWT来实现的，校验JWT的算法复杂，而且需要用到秘钥。如果每个微服务都去做登录校验，这就存在着两大问题：
每个微服务都需要知道JWT的秘钥，不安全
每个微服务重复编写登录校验代码、权限校验代码，麻烦
既然网关是所有微服务的入口，一切请求都需要先经过网关。我们完全可以把登录校验的工作放到网关去做，这样之前说的问题就解决了：
只需要在网关和用户服务保存秘钥
只需要在网关开发登录校验功能
此时，登录校验的流程如图：
不过这里存在问题:
网关路由是配置的，请求转发是Gateway内部代码，我们如何在转发之前做登录校验？
网关校验JWT之后，如何将用户信息传递给微服务？
微服务之间也会相互调用，这种调用不经过网关，又该如何传递用户信息？
网关过滤器 登录校验必须在请求转发到微服务之前做，否则就失去了意义。而网关的请求转发是Gateway内部代码实现的，要想在请求转发之前做登录校验，就必须了解Gateway内部工作的基本原理。
客户端请求进入网关后由HandlerMapping对请求做判断，找到与当前请求匹配的路由规则（**Route**），然后将请求交给WebHandler去处理。
WebHandler则会加载当前路由下需要执行的过滤器链（**Filter chain），然后按照顺序逐一执行过滤器（后面称为 Filter**）。图中Filter被虚线分为左右两部分，是因为Filter内部的逻辑分为pre和post两部分，分别会在请求路由到微服务之前 和之后 被执行。
只有所有Filter的pre逻辑都依次顺序执行通过后，请求才会被路由到微服务。
微服务返回结果后，再倒序执行Filter的post逻辑。
最终把响应结果返回。
如图中所示，最终请求转发是有一个名为NettyRoutingFilter的过滤器来执行的，而且这个过滤器是整个过滤器链中顺序最靠后的一个。如果我们能够定义一个过滤器，在其中实现登录校验逻辑，并且将过滤器执行顺序定义到 NettyRoutingFilter之前，这就符合我们的需求了！
网关过滤器链中的过滤器有两种：
**GatewayFilter**：路由过滤器，作用范围比较灵活，可以是任意指定的路由Route.
**GlobalFilter**：全局过滤器，作用范围是所有路由，不可配置。
Gateway中内置了很多的GatewayFilter，详情可以参考官方文档：
https://docs.spring.io/spring-cloud-gateway/docs/3.1.7/reference/html/#gatewayfilter-factories
自定义过滤器 自定义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
动态参数配置这里就不说了,我也没怎么用到,还不大懂应用
自定义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 ; } }
登录校验 登录校验的过滤器感觉跟拦截器的写法也挺类似的
@Component @Slf4j public class AuthGlobalFilter implements GlobalFilter , Ordered { @Resource private JwtTool jwtTool; jwt工具 @Resource private AuthProperties authProperties; private final AntPathMatcher antPathMatcher = new AntPathMatcher (); @Override public Mono<Void> filter (ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request = exchange.getRequest(); RequestPath path = request.getPath(); List<String> excludePaths = authProperties.getExcludePaths(); if (isExclude(path.toString())) { return chain.filter(exchange); } HttpHeaders headers = request.getHeaders(); List<String> authorization = headers.get("Authorization" ); String token=null ; if (!CollUtils.isEmpty(authorization)){ token= authorization.get(0 ); } Long userId=null ; try { userId = jwtTool.parseToken(token); }catch (Exception e){ ServerHttpResponse response = exchange.getResponse(); response.setStatusCode(HttpStatus.UNAUTHORIZED); return response.setComplete(); } String userInfo = userId.toString(); ServerWebExchange swe = exchange.mutate().request(builder -> builder.header("user-info" , userInfo)) .build(); return chain.filter(swe); } private boolean isExclude (String path) { List<String> excludePaths = authProperties.getExcludePaths(); for (String excludePath : excludePaths) { if (antPathMatcher.match(excludePath, path)) { return true ; } } return false ; } @Override public int getOrder () { return 0 ; } }
微服务获取用户信息 网关拦截方面实现了,但是微服务内部之间需要互相传递信息啊
由于网关发送请求到微服务依然采用的是Http请求，因此我们可以将用户信息以请求头的方式传递到下游微服务。然后微服务可以从请求头中获取登录用户信息。考虑到微服务内部可能很多地方都需要用到登录用户信息，因此我们可以利用SpringMVC的拦截器来实现登录用户信息获取，并存入ThreadLocal，方便后续使用。
据图流程图如下：
因此，接下来我们要做的事情有：
改造网关过滤器，在获取用户信息后保存到请求头，转发到下游微服务(上面的代码已经携带了)
编写微服务拦截器，拦截请求获取用户信息，保存到ThreadLocal后放行
在common模块中编写登录拦截器.
@Configuration @ConditionalOnClass(DispatcherServlet.class) public class MvcConfig implements WebMvcConfigurer { @Override public void addInterceptors (InterceptorRegistry registry) { registry.addInterceptor(new UserInfoInterceptor ()); } }
@Component 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(); } }
需要注意的是，这个配置类默认是不会生效的，因为它所在的包是com.hmall.common.config，与其它微服务的扫描包不一致，无法被扫描到，因此无法生效。
基于SpringBoot的自动装配原理，我们要将其添加到resources目录下的META-INF/spring.factories文件中：
内容如下：
org.springframework.boot.autoconfigure.EnableAutoConfiguration =\ com.hmall.common.config.MyBatisConfig,\ com.hmall.common.config.MvcConfig,\ com.hmall.common.config.JsonConfig
Openfegin传递用户 前端发起的请求都会经过网关再到微服务，由于我们之前编写的过滤器和拦截器功能，微服务可以轻松获取登录用户信息。
但有些业务是比较复杂的，请求到达微服务后还需要调用其它多个微服务。比如下单业务，流程如下：
下单的过程中，需要调用商品服务扣减库存，调用购物车服务清理用户购物车。而清理购物车时必须知道当前登录的用户身份。但是，订单服务调用购物车时并没有传递用户信息 ，购物车服务无法知道当前用户是谁！
由于微服务获取用户信息是通过拦截器在请求头中读取，因此要想实现微服务之间的用户信息传递，就必须在微服务发起调用时把用户信息存入请求头 。
微服务之间调用是基于OpenFeign来实现的，并不是我们自己发送的请求。我们如何才能让每一个由OpenFeign发起的请求自动携带登录用户信息呢？
这里要借助Feign中提供的一个拦截器接口：feign.RequestInterceptor
public interface RequestInterceptor { void apply (RequestTemplate template) ; }
我们只需要实现这个接口，然后实现apply方法，利用RequestTemplate类来添加请求头，将用户信息保存到请求头中。这样以来，每次OpenFeign发起请求的时候都会调用该方法，传递用户信息。
public class DefaultConfig {@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()); } }; } }
Lambda简化(可读性感觉不太好,)
public class DefaultConfig { @Bean public RequestInterceptor userInfoRequestInterceptor () { return requestTemplate -> { Long userId = UserContext.getUser(); if (userId!=null ){ requestTemplate.header("user-info" , userId.toString()); } }; } }
@FeignClient(value = "item-service", configuration = DefaultConfig.class) public interface ItemClient { @GetMapping("/items") List<ItemDTO> queryItemByIds (@RequestParam Collection<Long> ids) ; @PutMapping("/items/stock/deduct") public void deductStock (@RequestBody List<OrderDetailDTO>items) ; }
配置管理 我们已经解决微服务中几个问题了,小项目基本就ok了
微服务之间的远程调用
微服务的注册和发现(nacos)
微服务请求路由和负载均衡
微服务之间用户信息传递
现在依然还有几个问题需要解决：
网关路由在配置文件中写死了，如果变更必须重启微服务
某些业务配置在配置文件中写死了，每次修改都要重启服务
每个微服务都有很多重复的配置，维护成本高
这些问题都可以通过统一的配置管理器服务 解决。而Nacos不仅仅具备注册中心功能，也具备配置管理的功能：
微服务共享的配置可以统一交给Nacos保存和管理，在Nacos控制台修改配置后，Nacos会将配置变更推送给相关的微服务，并且无需重启即可生效，实现配置热更新。
网关的路由同样是配置，因此同样可以基于这个功能实现动态路由功能，无需重启网关即可修改路由配置。
感觉有点小牛批哈这个nacos,但是它是怎么做到的,俺很好奇.
配置共享 我们可以把微服务共享的配置抽取到Nacos中统一管理，这样就不需要每个微服务都重复配置了。分为两步：
添加共享配置 以cart-service为例，我们看看有哪些配置是重复的，可以抽取的：
首先是jdbc相关配置：
然后是日志配置：
然后是swagger以及OpenFeign的配置：
在nacos中添加相应的配置.
spring: datasource: url: jdbc:mysql://${hm.db.host:192.168.87.132}:${hm.db.port:3306}/${hm.db.database}?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai driver-class-name: com.mysql.cj.jdbc.Driver username: ${hm.db.un:root} password: ${hm.db.pw:123} mybatis-plus: configuration: default-enum-type-handler: com.baomidou.mybatisplus.core.handlers.MybatisEnumTypeHandler global-config: db-config: update-strategy: not_null id-type: auto
改为hm.db.host:192.168.87.132,即默认为虚拟机ip地址,但是有值的话就用配置的值
拉取共享配置 接下来，我们要在微服务拉取共享配置。将拉取到的共享配置与本地的application.yaml配置合并，完成项目上下文的初始化。
不过，需要注意的是，读取Nacos配置是SpringCloud上下文（ApplicationContext）初始化时处理的，发生在项目的引导阶段。然后才会初始化SpringBoot上下文，去读取application.yaml。
也就是说引导阶段，application.yaml文件尚未读取，根本不知道nacos 地址，该如何去加载nacos中的配置文件呢？
SpringCloud在初始化上下文的时候会先读取一个名为bootstrap.yaml(或者bootstrap.properties)的文件，如果我们将nacos地址配置到bootstrap.yaml中，那么在项目引导阶段就可以读取nacos中的配置了。
引入依赖：
<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 >
spring: application: name: cart-service profiles: active: dev cloud: nacos: server-addr: 192.168 .87 .132 :8848 config: file-extension: yaml shared-configs: - data-id: shared-log.yaml - data-id: shared-jdbc.yaml - data-id: shared-knife4j.yaml - data-id: shared-seata.yaml - data-id: shared-feign.yaml
到此application.yaml就可以简化为
server: port: 8082 feign: okhttp: enabled: true hm: swagger: title: 购物车服务接口文档 package: com.hmall.cart.controller db: database: hm-cart
配置热更新 有很多的业务相关参数，将来可能会根据实际情况临时调整。例如购物车业务，购物车数量有一个上限，默认是10，对应代码如下：
现在这里购物车是写死的固定值，我们应该将其配置在配置文件中，方便后期修改。
但现在的问题是，即便写在配置文件中，修改了配置还是需要重新打包、重启服务才能生效。能不能不用重启，直接生效呢？
这就要用到Nacos的配置热更新能力了，分为两步：
添加配置到Nacos 首先，我们在nacos中添加一个配置文件，将购物车的上限数量添加到配置中：
注意文件的dataId格式：
[服务名]-[spring.active.profile].[后缀名]
不写spring acvite profile的话默认所有环境都共享
文件名称由三部分组成：
**服务名**：我们是购物车服务，所以是cart-service
**spring.active.profile**：就是spring boot中的spring.active.profile，可以省略，则所有profile共享该配置
**后缀名**：例如yaml
@Component @Data @ConfigurationProperties(prefix = "hm.cart") public class CartProperties { private Integer maxItems; }
然后就可以写一个类动态读取数据了
动态路由 网关的路由配置全部是在项目启动时由org.springframework.cloud.gateway.route.CompositeRouteDefinitionLocator在项目启动的时候加载，并且一经加载就会缓存到内存中的路由表内（一个Map），不会改变。也不会监听路由变更，所以，我们无法利用上节课学习的配置热更新来实现路由更新。
因此，我们必须监听Nacos的配置变更，然后手动把最新的路由更新到路由表中。这里有两个难点：
如何监听Nacos配置变更？
如何把路由信息更新到路由表？
在Nacos官网中给出了手动监听Nacos配置变更的SDK：
https://nacos.io/zh-cn/docs/sdk.html
如果希望 Nacos 推送配置变更，可以使用 Nacos 动态监听配置接口来实现。
public void addListener (String dataId, String 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 ; } });
更新路由 package org.springframework.cloud.gateway.route;import reactor.core.publisher.Mono;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 >
@Component @Data @Slf4j public class DynamicRoute { @Resource private RouteDefinitionWriter routeDefinitionWriter; @Resource private 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) { updateRouteConfig(configInfo); } }); updateRouteConfig(configInfo); } public void updateRouteConfig (String configInfo) { log.debug("监听到路由配置变更: {}" ,configInfo); List<RouteDefinition> routeDefinitionList = JSONUtil.toList(configInfo, RouteDefinition.class); for (String routeId : routeIds) { routeDefinitionWriter.delete(Mono.just(routeId)).subscribe(); } routeIds.clear(); if (CollUtil.isEmpty(routeDefinitionList)){ return ; } routeDefinitionList.forEach(routeDefinition -> { routeDefinitionWriter.save(Mono.just(routeDefinition)).subscribe(); routeIds.add(routeDefinition.getId()); }); } }
我们直接在Nacos控制台添加路由，路由文件名为gateway-routes.json，类型为json：
配置内容如下：
[ { "id" : "item" , "predicates" : [ { "name" : "Path" , "args" : { "_genkey_0" : "/items/**" , "_genkey_1" : "/search/**" } } ] , "filters" : [ ] , "uri" : "lb://item-service" } , { "id" : "cart" , "predicates" : [ { "name" : "Path" , "args" : { "_genkey_0" : "/carts/**" } } ] , "filters" : [ ] , "uri" : "lb://cart-service" } , { "id" : "user" , "predicates" : [ { "name" : "Path" , "args" : { "_genkey_0" : "/users/**" , "_genkey_1" : "/addresses/**" } } ] , "filters" : [ ] , "uri" : "lb://user-service" } , { "id" : "order" , "predicates" : [ { "name" : "Path" , "args" : { "_genkey_0" : "/orders/**" } } ] , "filters" : [ ] , "uri" : "lb://order-service" } , { "id" : "pay" , "predicates" : [ { "name" : "Path" , "args" : { "_genkey_0" : "/pay-orders/**" } } ] , "filters" : [ ] , "uri" : "lb://pay-service" } ]
事务管理 (sentinel,seata)感觉用组件一点感觉都没有…
