微服务架构

一、分布式架构：根据业务功能对系统进行拆分，每个业务模块作为独立项目开发。称为一个服务
优点：降低服务耦合。 缺点：不利维护。单一职责：微服务拆分粒度更小， 每一个服务都对应唯一的业务能力，做到单一原则，避免重复业务开发。面向服务：微服务对外暴露业务接口。隔离线好：服务调用做好隔离，容错，降级。
二、Springcloud:集成了各种微服务功能组件，并基于springboot实现了这些组件的自动装配
二、Nacos:

<!-- nacos客户端依赖 --><dependency>    <groupId>com.alibaba.cloud</groupId>    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency>

在yml中加配置地址
2.1nacos服务跨集群调用问题：服务调用尽可能选择本地集群的服务，跨集群调用延迟较高。本地集群不可访问时，再去访问其它集群

2.2根据权重负载均衡：服务器设备性能有差异，部分实例所在机器性能较好，另一些比较差，我们希望性能好的机器承担更多的用户请求。nacos提供了权重配置来控制访问频率，权重越大访问频率越高
Nacos控制台可以设置实例的权重值，0~1之间
同集群内的多个实例，权重越高被访问的频率越高
权重设置为0则完全不会被访问
2.2环境隔离–namespace：nacos服务存储和数据存储的最外层都是一个名为namespace的东西，用来做外层隔离

在yml中配置：namespace:命名空间id.
总结：不同的namespace的服务互相不可见.
2.3Nacos的配置列表：


导入依赖：

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

创建一个bootstrap.yml:

自动刷新：nacos中的配置文件修改后，不需要重新启动，就可以感知到了。在类上@RefershScope。


三、Nacos集群搭建：

四、Feign:
五、网关：功能：身份证验证和权限校验。服务器路由(就是访问哪个微服务)、负载均衡。请求限流(限制访问次数).因为直接访问的话任何人都能访问到，比较不安全.
一切请求先来网关，

5.1服务路由：-id:路由Id，自定义，唯一即可
uri: lb://. #路由的目标地址，也就是在nacos注册起的名字
predicates:#路由断言
-Path=/user/** #这个事按照路径匹配，也就是只要以/user/开头的就统统转发到uri中.
5.2路由断言工厂：
我们在配置文件中写的断言规则只是字符串，这些字符串将会被Predicate Factory(断言工厂)读取并处理。转变为路由判断的条件


EG:在这个时间之前访问可以被访问到，不然就会报404
5.3路由过滤器：GaetwayFilter是网关提供的一种过滤器，可以对网关的请求和微服务返回的响应做处理:!

请求进入网关之后，网关到路由，再经过过滤器处理，然后才到微服务。微服务收到以后，也会给网关响应，响应也可以到过滤器，过滤器可以对其进行处理.


-AddRequestHeader过滤器名字= Truth(是key),Itcast xxx(是value)。就是给这个服务的请求体添加了这个值
5.4全局过滤器：之前的过滤器只能给指定的参数就行过滤，处理逻辑是固定的。而全局过滤器GlobalFilter的逻辑需要自己写代码：实现GlobalFilter接口：


在类上要添加2个注解。@Component .@Order(int),order注解表示过滤器的优先级，因为不是只有你一个可以创建过滤器，数字越小优先级越高
5.4过滤器执行顺序：Order值越小，越先执行。当过滤器的order值一样时，会按照defaultFilter>路由过滤器>GlobalFilter执行
5.5网关跨域：
六、Docker:是一个快速交付应用，运行应用的技术。可以将程序及其依赖，运行环境一起打包为一个镜像，可以迁移到任意Linux操作系统。运行时利用沙箱机制形成隔离容器，各个应用互不干涉。启动和移除只通过一个命令就可以了。
6.1docker与虚拟机的差别：
6.3认识Docker:镜像：Dokcer将应用程序及依赖，函数库，环境，配置等文件打包在一起的，称为镜像。
容器：镜像中的应用程序运行后形成的进程就是容器，只是docker会给容器做隔离，对外不可见。

6.4镜像相关命令：镜像名称一般分为两部分：repostitory(镜像名称):tag。 镜像名称：repostitory:tag
docker images查询镜像。 docker rmi 删除镜像. docker push推送镜像到服务
容器相关命令：docker run. docker pause暂停。 docker stop 停止. docker start开始
重点：创建一个容器：docker run --name 给容器起个名. -p 90:80 -d nginx
-p 80:80代表端口映射。90代表宿主机端口，可以随便起。80代表镜像端口。-d代表后台运行 nginx代表启动哪个镜像。不写tags代表启动最新版
修改docker 容器里镜像的文件：首先进入容器内部：docker exec -it 容器名字 bash #bash进入容器后执行的命令，bash是一个linux终端交互的命令。
sed -i ‘s#Welcome to nginx#传智教育欢迎您#g’ index.html
sed -i ‘s###g’ index.html

通过exec退出容器.
6.5容器挂载：数据卷：是一个虚拟目录，指向宿主机文件系统的某个目录。
挂载：通过-v来进行挂载。docker run --name mn -v html:/root/html. 把名为html的数据卷挂载到容器内的/root/html文件中
然后通过docker volume inspect html查看它的位置消息。再cd 进入就看到了。
-v 容器需要被挂载的目录：/挂载到哪里

也可以自己挂载，就是要自己创建目录，自己维护。
6.6自定义镜像：
七、DockerCOmpose:可以基于compose文件帮我们快速的部署分布式应用，而无需手动一个个创建和运行容器。
八、Seata:微服务保护。
8.1雪崩问题：微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。
解决方式：超时处理：设定超时时间，请求超过后直接返回响应消息，不会无停止等待.
舱壁模式：限定每个业务能使用的线程数，避免耗尽Tomcat的资源，也叫线程隔离
熔断降级：如果请求次数故障超过阀值，就不会在让该请求访问，拦截它。
流量控制：限制住它每秒的请求次数qps。避免服务因流量的突增而故障!

8.2SpringBoot整合sentinel:
8.3限流规则：
簇点链路：就是项目中调用链路，链路中的每个接口就是一个资源
点击限流后就可以进入以上界面。针对来源：表示从哪来的请求，default表示一切来源。单机阀值1：表示1秒只能有1个请求。通过jemeter测试来填写即可
点击高级后，出现上图：直接：代表直接访问。关联：代表当前资源与另一个资源，触发阀值时，对当前资源限流(就是a,b两个请求，b到了阀值，对a进行限流)。给谁限流就给谁添加规则

链路：指定链路访问到本资源的请求，触发阀值时，对指定的链路进行限流。就是是同一个业务方法，但是访问路径不同.比如：/a/d请求
/b/d请求。链路就是只会对其中一个做限流。
sentinel默认只会对Controller中的方法为资源，如果要标记其它方法，
8.4流控效果：就是达到流量阀值时应该采取的措施：
快速失败：到达就失败。
warm up:预热模式，对超出阀值的请求同样拒绝抛出异常，但这种模式阀值会动态变化，从一个较小值逐渐增加到最大阀值。
排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长。
warm up:就是在启动规定时间内只能为最大阀值的三分之一，过了规定时间才能达到最大阀值
排队等待：到达阀值，不会抛异常，进入队列等待，只有请求预期时长大于了超时时间，才会报错
8.4热点参数限流：
需要在要添加的Controller中添加@SentinelResource(“起个名字”)
点击热点规则进行配置，并不是在簇点链路中配置.

8.5隔离和降级：虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离和熔断降级手段了
就是在调用Feign的时候指定一个类，调用Fegin出错就指向这个类,FallbackFoctory=类.class
8.9熔断降级：是解决学崩问题的重要手段，其思路就是由断路器统计服务调用的异常比例，如果超出阀值则会熔断该服务，就是拦截该服务的一切请求，而当服务恢复时，断路器会放行访问该服务的请求


8.1:授权规则：对请求者的来源做一个判断!
8.2自定义异常：就是被拒绝后应该向页面显示什么？

8.8规则持久化：就是sentinel重启后不让规则丢失
九、分布式事务：CAp:
c(一致性):用户访问分布式系统中的任意节点，的到的数据必须一致
A(可用性):用户访问集群中的任意健康节点，必须得到响应，而不是超时或者拒绝。
p(分区容错)：分区：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区
容错：在集群出现分区时，整个系统也要持续对外提供服务。
9.1Base理论：Base理论是对Cap的一种解决思路：
基本可用：分布式系统在出现故障时，允许损失部分可用性，即保障核心可用。
软状态：在一定时间内，允许出现中间状态，比如临时的不一致。也就是临时的数据不一致
最终一致：软状态结束后，数据最终达到一致。
而分布式事务最大的问题就是各个子事务的一致性问题，因此可以借鉴Cap定理和Base理论。
Ap模式：各个子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致
Cp模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但是事务等待状态中，处于弱可用状态
不管是ap还是cp，都有一个事务协调者

9.3Seata框架：


十、Seata–XA模式：
执行流程：第一阶段：TM向Tc注册全局事务，然后像RM调用分支，rm像tc注册分支事务，rm开始执行业务sql语句，并且向tc报告分支事务的状态。第二阶段：TM向tc提交或者回滚事务，TC检查分支事务的状态，tc向各个rm也就是分支事务通知，到底最后应该是提交呢还是回滚.
10.1XA模式的优势：实现了强一致性,一阶段模式后会进行等待，所以性能较差.
10.2实现模式：修改application.yml，每个参与的事务都要添加，开启xa模式，(2).给发起全局事务的入口方法添加@GlobalTransactional注解就可以了，然后重启每个服务
10.3AT模式：at模式同样是分阶段提交，但是它弥补了xa模式中资源锁定周期过长的不足，就是一阶段直接提交，不需要等待：

实现流程：tm向tc开启全局事务，并且调用分支事务，rm向tc注册自己的分支事务，tc直接执行sql语句并且直接提交不需要等待，然后生成快照，记录自己当前的状态。之后就想tc报告自己的事务状态。第二阶段：tm向tc提交，回滚事务，tc检查自己的分支事务状态，tc向rm发出命令，你到底是该提交呢还是该回滚呢，同时删除快照.

10.4xA模式与At模式有什么区别？
xa模式一阶段不提交，锁定资源，At模式一阶段直接提交，不提交资源，生成快照。xa模式依赖数据库机制实现回滚，at模式利用数据快照实现数据回滚。Xa模式强一致性。At模式最终一致
At模式下会发生脏写的问题：就是当前事务正在执行at,但是另外一个事务要修改这个表，就会发生脏写，解决方案如上

10.5TCC模式：不需要加锁