Nacos注册中心
Nacos是SpringCloudAlibaba推出的一款注册中心。
1. 服务注册到nacos
Nacos是SpringCloudAlibaba的组件，而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说，并没有太大区别。
主要差异在于：
依赖不同
服务地址不同
1.1 引入依赖在cloud-demo父工程的pom文件中的<dependencyManagement>中引入SpringCloudAlibaba的依赖：
1234567<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2023.0.1.2</version> <type>pom</typ ...
Nacos安装指南1.Windows安装开发阶段采用单机安装即可。
1.1.下载安装包在Nacos的GitHub页面，提供有下载链接，可以下载编译好的Nacos服务端或者源代码：
GitHub主页：https://github.com/alibaba/nacos
GitHub的Release下载页：https://github.com/alibaba/nacos/releases
如图：
本课程采用1.4.1.版本的Nacos，课前资料已经准备了安装包：
windows版本使用nacos-server-1.4.1.zip包即可。
1.2.解压将这个包解压到任意非中文目录下，如图：
目录说明：
bin：启动脚本
conf：配置文件
1.3.端口配置Nacos的默认端口是8848，如果你电脑上的其它进程占用了8848端口，请先尝试关闭该进程。
如果无法关闭占用8848端口的进程，也可以进入nacos的conf目录，修改配置文件中的端口：
修改其中的内容：
1.4.启动启动非常简单，进入bin目录，结构如下：
然后执行命令即可：
windows命令：
1startup.cm ...
SpringCloud
未读Ribbon负载均衡
在Eureka服务拉取中，通过添加@LoadBalanced注解，即可实现负载均衡功能，这是什么原理呢？
1. 负载均衡原理
SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。
2. LoadBalancerInterceptor
还有我们发出的请求明明是http://userservice/user/1，但为什么变成了http://localhost:8081的呢？为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。
显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。
2.1 LoadBalancerIntercepor
可以看到这里的intercept方法，拦截了用户的HttpRequest请求，然后做了几件事：
request.getURI()：获取请求uri，本例 ...
SpringCloud
未读Eureka注册中心
假如我们的服务提供者user-service部署了多个实例，如图：
思考几个问题：
order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？
有多个user-service实例地址，order-service调用时该如何选择？
order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？
1. Eureka的结构和作用
这些问题都需要利用SpringCloud中的注册中心来解决，其中最广为人知的注册中心就是Eureka，其结构如下：
问题1：order-service如何得知user-service实例地址？
user-service服务实例启动后，将自己的信息注册到eureka-server（Eureka服务端），这个叫服务注册。
eureka-server保存服务名称到服务实例地址列表的映射关系
order-service根据服务名称，拉取实例地址列表，这个叫服务发现或服务拉取。
问题2：order-service如何从多个user-service实例中选 ...
服务拆分和远程调用
任何分布式架构都离不开服务的拆分，微服务也是一样。
1. 服务拆分原则
不同微服务，不要重复开发相同业务
微服务数据独立，不要访问其它微服务的数据库
微服务可以将自己的业务暴露为接口，供其它微服务调用
2. 服务拆分示例
以用户订单的微服务cloud-demo为例，其结构如下：
cloud-demo：父工程，管理依赖。
order-service：订单微服务，负责订单相关业务。
user-service：用户微服务，负责用户相关业务。
要求：
订单微服务和用户微服务都必须有各自的数据库，相互独立
订单服务和用户服务都对外暴露Restful的接口
订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据库
3. 实现远程调用案例
分别编写用户信息业务、订单业务，和编写单体项目一样，把每个业务当视为一个独立的项目配置依赖编写业务，只是它们各自拥有独立的数据库。
对每个业务进行测试，确保组装没问题。
在order-service服务中，有一个根据id查询订单的接口：
根据id查询订单，返回值是Order对象，如图 ...
认识微服务
1. 单体架构
单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。
单体架构的优缺点如下：
优点：
架构简单
部署成本低
缺点：
耦合度高（维护困难、升级困难）
2. 分布式架构
分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。
分布式架构的优缺点：
优点：
降低服务耦合
有利于服务升级和拓展
缺点：
服务调用关系错综复杂
分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：
服务拆分的粒度如何界定？
服务之间如何调用？
服务的调用关系如何管理？
人们需要制定一套行之有效的标准来约束分布式架构。
3. 微服务
微服务的架构特征：
单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
自治：团队独立、技术独立、数据独立，独立部署和交付
面向服务：服务提供统一标准的接口，与语言和技术无关
隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚 ...
Redis常见命令
1. Redis数据结构介绍
Redis是一个key-value的数据库，key一般是String类型，不过value的类型多种多样：
Redis为了方便我们学习，将操作不同数据类型的命令也做了分组，在官网（ https://redis.io/commands ）可以查看到不同的命令：
当然我们也可以通过Help命令来帮助我们去查看命令
2. Redis 通用命令
通用指令是部分数据类型的，都可以使用的指令，常见的有：
KEYS：查看符合模板的所有key
DEL：删除一个指定的key
EXISTS：判断key是否存在
EXPIRE：给一个key设置有效期，有效期到期时该key会被自动删除
TTL：查看一个KEY的剩余有效期
通过help [command] 可以查看一个命令的具体用法，例如：
KEYS
123456789127.0.0.1:6379> keys *1) "name"2) "age"127.0.0.1:6379># 查询以a开头的key127.0.0.1:6379> ...
[!TIP]
记住：如果别名中有空格的话，可以将这个别名使用双引号或者单引号将其括起来。
123SELECT ename, sal * 12 "year sal" FROM EMP;SELECT ename, sal*12 as "year sal" FROM EMP;
select * from dept; 在执行的时候会被解析为 select DEPTNO, DNAME, LOC from dept; 再执行，所以这种效率方面弱一些。
别名是中文是可以的，但是对于低版本的MySQL来说会报错，需要添加双引号或单引号。
1SELECT ename, sal*12 年薪 FROM EMP;
在MySQL当中，字符串可以使用单引号，也可以使用双引号
查询的数据是字符串类型，要用 ‘ ‘或者” “。
1234# 查询工作岗位不是MANAGER的员工姓名和岗位SELECT ENAME , JOB FROM EMP WHERE JOB<> 'MANAGER';SELECT ENAME , JOB FROM E ...
Redis实现共享存储(session)Redis 是一个开源的内存键值存储数据库，广泛应用于需要高性能和高并发的场景中。
安装redis
redis管理工具：Another Redis Desktop Manager
引入redis
提供可对redis操作的依赖
123456<!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-data-redis --><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> <version>3.3.1</version></dependency>
整合springsession
引入springsession 和 redis 的 ...
Tips
未读设置种session的范围共享 Cookie 是在多个子域之间实现状态或数据共享的常见需求。例如，在一个公司的多个子网站之间（如 sub1.example.com 和 sub2.example.com）共享用户的登录状态。在 HTTP 协议中，Cookie 是通过域名和路径来确定其作用范围的。当服务器向客户端发送一个 Cookie 时，可以指定 Cookie 的 Domain 属性。浏览器会根据这个属性来决定 Cookie 是否在特定域名或子域名下发送。
为了使多个子域共享一个 Cookie，可以将 Cookie 的 Domain 属性设置为一个更高层的公共域名，例如将 sub1.example.com 和 sub2.example.com 的 Cookie 设置为 example.com。这样做的好处在于：
共享状态： 用户在一个子域登录后，在其他子域也可以保持登录状态，不需要再次登录。
统一管理： 可以通过一个公共域名来统一管理和操作 Cookie，简化了操作和维护。
以下是设置共享 Cookie 的示例代码：
12345Cookie cookie = new Cookie(& ...
