CYK_byte的博客

a）先创建一个空项目，名字自定义.b）在刚刚的空项目下创建整个项目的父模块c）父工程下的 src 可以删了，没用d）最后直接用 IDEA 打开空项目下的父工程（否则 Java 文件不生效）

c）点击 “创建配置”，然后就可以把 kt-gateway 微服务中的 application.yml 文件中的所有内容都放在 nacos 上进行统一管理，随后点击发布.这里需要配置路由规则，分别将将请求通过负载均衡引入到 kt-user 和 kt-product。b）接着分别给 kt-user 和 kt-product 引入 kt-feign 模块，如下。kt-product 微服务拿到 kt-user 微服务的数据，远程调用引入成功.a）在 feign 模块的 pom.xml 中引入如下依赖。

a）先说结论：收益没有特别直观的感受，并且迁移成本比较高，坑很多（有时候一个坑能卡上几个小时，别问我是怎么过来的），如果是新项目，可以试试~b）改造的项目是一个 AI 图片社区，基于 JDK17、SpringBoot 2.6.3、SpringCloud 2021.0.1 的微服务项目，主要使用到的中间件有 MySQL、MongoDB、Redis、RabbitMQ、ElasticSearch、Nacos... 就是说，五脏俱全，该有的坑都有了...

就是指对服务器请求量做限制，避免因为突发的请求量过多，导致服务器宕机.比如，我们的服务器只能抗住每秒 1000 的请求量，但此时突然有 10000 的请求量来了，那么就需要把你这么大的请求量拦下来，按照服务能够承载的流量去放行，起到一个流控的效果.如何实现呢，就来看看这主流的三种限流算法~

那么当服务消费者要去消费时，就可以从注册中心拉取服务信息. 这个过程也被称为“服务发现”. 但是他这个拉去动作不是每次都要做的（压力太大），而是将拉取到的服务信息缓存到一个列表中，这样接下来的一段时间里，就不用去拉去了，而是直接从缓存列表中拿.因为一个集群中可能包含多个实例，也就是具体的节点信息（例如实例的IP、Port、健康状态），那么 Cluster 这个类中又维护了 两个 Set，分别是临时实例和非临时实例（此处，Eureka 就没有做区分，只有临时实例）.

a）Nacos 的分级存储模型对应到源码中，实际上就是一个多层嵌套Map，key 就是 String 类型的 namespace，而他的 value 又是一个 Map.b）这个第二层的 Map 就表示 group 和 服务了，key 就服务名称，而 value 就是一个服务 service.c）服务实际上就是一个类，由于一个服务往往是有多个集群的，因此在 service 类中又维护了一个 map，key 就是集群名称（例如，上海、广州、杭州...）.d）他的值 cluster 集群也是一个

RandomLoadBalancer - 随机分配策略(默认)RoundRobinLoadBalancer - 轮询分配策略//这里不用加 @Configuration 注解//将官方提供的 RandomLoadBalancer 注册为Bean@Bean通过 @LoadBalancerClient(value = "服务名", configuration = LoadBalancerConfig.class) 指定负载均衡策略为随机.

当使用ObjectMapper.readValue()方法将 JSON 字符串反序列化为AppResult对象时，如果AppResult对象的 data属性是一个泛型（如 Object），那么 Jackson 将无法知道这个属性的确切类型，因此会将其反序列化为一个LinkedHashMap.

因为 openfeign 是 伪HttpClient 对象，我们在远程调用他的客户端提供的接口时，并不知道你到底是路径传参还是问号传参，因此需要通过注解的方式来指明传参方式（就像 Spring Web 一样，只不过 Spring Web 中如果没指明传参类型，底层会按默认方式走，而 openfeign 则没有）.然而，需要注意的是，OpenFeign 只能处理简单的 Java 对象和 Map 对象，对于复杂的 Java 对象或包含特殊类型的对象，可能无法自动进行正确的序列化和反序列化。

【代码】Spring Cloud - 通过 Gateway webflux 编程实现网关异常处理。

例如，自定义一个 Token 局部过滤器，那么就可以创建一个类 filter.factory.TokenGatewayFilterFactory在 apply 中的过滤逻辑就是，判断前端是否传入 token，如果没有就抛异常，如果有就去 redis 上看看是否存在这个 token，如果存在就放行，不存在就抛异常.@Slf4j@Component // 表示在工厂中创建对象@Autowired/*** 核心方法: 处理过滤* @return*/@Override@Override。

root html 就是根路径，也就是通过 openresty-1.21.4.2-win64\html\ 路径下，去找页面（默认是 index.html 页面，也就是文章开头展示的页面）.^~ 优先级比 location / 高，但是匹配规则和 location / 类似. 例如 location ^~ /a 就表示匹配以 /a 开头的所有路由.= 优先级最高，表示完全匹配，例如 location = /a 就表示只匹配路由 location/a，其他的都不可以.

1. 首先前端将用户名和密码发送给后端，后端对用户名和密码校验成功后，会将用户 id 和其他信息作为 payload ，然后将其分别进行 Base64 编码，拼接，最后再签名，形成一个 JWT（Token）. 形成的 JWT 就形同 xxx.yyy.zzz 这种结构的字符串.http 协议是一种无状态的协议，也就意味着当用户第一次通过用户名和密码登录成功以后，下一次再请求的时候，用户还需要再进行登录才行，因为根据 http 协议，我们不能知道是哪个用户发出的请求.

这里不仅仅要实现高可用，还需要实现异地容灾. 异地容灾就是说，如果你整了好几个节点部署起来，全部放到一个机房里面，那么如果这个机房出了故障，就意味着整个集群就完了，所以对于一个大型的集群来讲，都会把这些服务异地部署.问题2：如果我们要实现异地容灾，也就说某一个机房挂了，需要快速的切换到另一个可用的机房，但是这个配置在配置文件中写死了，如果要改配置文件，还需要重启服务器，这是我们不希望看到的，怎么办？进入 seata/bin 目录，运行 seata-server.bat 文件，默认端口为 8091。

第一次超时了，进行空回滚（添加 freeze，设置状态为 cancel），第二次又超时了，freeze 不为空，就会进行恢复金额逻辑. 这就出问题了，不能进行恢复金额操作，因此，这里需要进行判断，如果处理过了，直接返回 true 即可.在执行完空回滚之后，try 逻辑的请求阻塞突然通畅，就会去执行资源预留业务，但是资源预留了之后就没有后续了（已经执行过 cancel 中的空回滚了），既没有 cancel，也没有 confirm，业务只执行了一半. 这就是业务悬挂.怎么知道 try 到底有没有执行过呢？

TM 看到业务结束了，就会去通知 TC，那么 TC 就会判断是提交还是回滚. 如果分支事务的状态都是成功的，那就可以把第一阶段准备的快照给删了（删快照这个动作是异步的，因为第一阶段都成功了，也提交了，后面的事情就可以用一个线程独立去做，提高了效率）. 如果第一阶段有人失败了，就要基于 undo log 恢复数据，恢复以后这个 log 也就没用了，最后也会删除.2. XA 依赖于数据库的机制来做回滚，而 AT 模式因为已经提交了，就不能回滚，他是通过给自己生成快照的方式来实现数据的恢复.

刚刚我们已经知道了 Seata 中三个重要角色，其中 tm 和 rm 是对业务的管理，而 tc 则是脱离业务之外的独立服务，需要协调 tm 和 rm，协调全局事务和分支事务.这里我就来带大家搭建一下 Seata 的 TC 服务.

在分布式系统下的一个业务，跨越了多个服务和数据库，每个防毒物都可以任务是一个分支事务，分布式事务就是要保证，所有分支事务最终状态一致，要么大家都成功，要么大家都失败.而分布在事务出现了问题，就是因为各个分之事务之间是相互隔离，感知不到的，因此就导致无法回滚，进一步导致没法保证一致性.

前面我们学习了 Sentinel 中的常用玩法，但是在使用的过程中发现一个问题，就是每当我们的服务重启的时候，在 sentinel 控制台上配置的各种规则就都丢失了. 这是因为 sentinel 默认会把这些规则保存到内存中，重启自然就丢失了. 在生产环境中，肯定是不能容忍这种情况的.通过 sentinel 的规则持久化就可解决这个问题.

授权规则是对请求者的身份做一个判断，判断是否又权限来访问我.这里大家肯定会想起 Spring Cloud Gateway 网关，也是所有请求都需要经过网关去身份认证，看你有没有权限访问我，这里为什么还要整一个授权规则呢？可以这样想啊，所有请求经过网关路由到微服务，此时网关才能对请求者的身份做认证，但是如果你们公司出现了内鬼，把微服务的地址给泄露给不怀好意的人，那些哥们就可以绕过网关直接访问微服务，因此就需要 sentinel 的权限股则解决这个问题.

熔断降级就是通过一个短路器取统计服务调用的时候 “异常比例、慢调用比例、异常数量”，比如说统计的是异常比例，那么如果异常比例过高，触发了阈值就会熔断该服务，这样就把故障的服务隔离开了.这就像是古代的武侠人士，手被毒蛇咬了，赶紧手起刀落，把手砍断，防止毒扩散到全身，但是这把手砍了算不了什么本事啊，能接回来才是真本事.而 Sentinel 就可以在服务恢复时，让熔断器放行访问该服务的请求.

举个例子，你在淘宝上买东西，完成支付以后会进行修改订单状态的业务，与此同时，你还要查看订单，但是 查询 和 修改 都会争抢数据库的锁，产生竞争. 根据业务需求是，优先进行更新订单业务，之后进行用户查询业务，因此当修改订单业务触发阈值时，就需要对查询订单业务进行限流.排队等待这种方式，当请求超过 qps 阈值之后，不会直接抛出异常，而是让多出来的请求先进入到一个队列中进行排队，然后按照阈值允许的时间间隔依次执行，如果队列中所有的请求处理时间加起来刚好等于等待时间，那么，此时新来的请求就会被拒绝.

显然不能，请求来了以后，就要等待 服务d 的响应，因为 服务d 出现故障了以后不能正常返回响应，因此就会阻塞在这里，导致 服务a 内部的业务阻塞在这里. 也就不会释放 tomcat 连接.拿之前的栗子讲，服务a 里有一个业务时访问 服务d 的，然后呢第一次访问时正常的，结果后面两次都出现了故障，这个时候熔断器就会统计这个异常比例是怎么样的. 假设阈值时 50%，而三个请求中，两个都出了问题，肯定超出了阈值，这个时候就会出现熔断，那么在 服务a 内部，访问 服务d 的业务都会被拦截下来，然后快速释放资源.

目录 一、前置知识1.镜像结构2.Dockerfile是什么二、自定义一个 java 项目镜像1.创建一个空目录，在这个空目录中创建一个文件，命名为 DockerFile，最后将 java 项目打包成 jar 包，放到这个目录中2.编写 Dockerfile 文件3.使用 docker build 构建为一个镜像4.使用 docker run 运行镜像我们知道镜像是将应用程序及其需要的系统函数库、环境、配置、依赖打包而成，那么它的层次结构是怎么的呢？镜像是分层结构，每一层称为一个LayerDockerfil

p ：将宿主机端口与容器端口映射，冒号左侧是宿主机端口，右侧是容器端口（配置映射是因为用户只能通过 http 请求访问到服务器，不能直接访问到对应的容器，因此需要服务器端口与容器端口建立映射关系）这里我们有两种启动 redis 的方式，第一种是直接启动 redis ，第二种是以 AOF 持久化的方式启动容器（--appendonly yes），如下图。如果需要持续查看日志信息可以添加 -f 参数，例如：docker logs -f mn ，这里 mn 是自定义容器名称， ctrl + c 可以停止跟踪。

Docker 分为 CE 和 EE 两大版本。CE 即社区版（免费，支持周期 7 个月），EE 即企业版，强调安全，付费使用，支持周期 24 个月。Docker CE 分为stabletest和nightly三个更新频道。官方网站上有各种环境下的，这里主要介绍 Docker CE 在 CentOS上的安装。

是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能，因此作为比较推荐实现网关的方式。是基于Servlet的实现，属于阻塞式编程。

Feign运行自定义配置来覆盖默认配置，可以修改的配置如下类型作用说明修改日志级别包含四种不同的级别：NONEBASICHEADERSFULL响应结果的解析器http远程调用的结果做解析，例如解析json字符串为java对象请求参数编码将请求参数编码，便于通过http请求发送支持的注解格式默认是SpringMVC的注解失败重试机制请求失败的重试机制，默认是没有，不过会使用Ribbon的重试我们最常使用的就是修改日志级别，其他的可以暂时不考虑~配置。

经过前面的步骤，我们已经新建一个 nacos 的配置文件，项目一启动就会去加载这个配置文件然后合并到 application.yml 中，那么怎么才能先去加载这个 nacos 新建的配置文件呢？无论profile如何变化，[spring.application.name].yaml这个文件一定会加载，因此多环境共享配置可以写入这个文件。获取到 nacos 的地址，然后才找到并加载 nacos 配置文件~访问 nacos 主页，点击配置管理查看配置列表，然后新建配置如下。可以看到控制台打印相应日志内容。

nacos 默认配置端口为 8848，如果你电脑上的 8848 端口被占用，那么就可以对 nacos 端口信息进行配置~c）修改完后点击确定，就完成啦，可以达到这样一个效果——使得端口为 8081 的服务访问频率是端口号为 8082 的服务访问频率的十分之一！服务调用尽可能选择本地集群的服务，跨集群调用延迟较高，当本地集群不可访问时，再去访问其它集群。前面我们提到 Nacos 的服务分级模型，他会优先访问本地集群，实际上这也是需要进行配置的~

ps：案例是上一章所讲的 “根据订单id查询订单的同时，把订单所属的用户信息一起返回”。上一章我们讲到 order-service（订单服务） 使用 RestTemplate 发送 Http 请求到 user-service（用户服务），同时我们使用 @LoadBalanced 注解增加负载均衡，通过负载均衡算法分配到 user-service 集群，那么中间这个负载均衡到底是什么东西在起作用？负载均衡算法到底是什么？接下来我们就一起来了解一下吧~

上一章我们讲到，利用 RestTemplate 发送 http 请求时，将 url 写成了 "http://localhost:8081/user/" + order.getUserId() ，这无疑将 url 写死了，？这只是其中一个背景，总的来讲，有以下三种原因：服务消费者该如何获取服务提供者的？如果有多个服务提供者，消费者该？消费者如何得知服务提供者的？

微服务是一种架构风格，按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。