Feign是声明式的 Web Service客户端，它让微服务之间的调用变得更简单了，类似 Controller 调用 Service。Spring Cloud 集成了 Ribbon 和 Eureka ，可在使用 Feign 时提供负载均衡的 HTTP 客户端。使用方法添加依赖<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> [email protected]("userservice") public interface UserClient { @GetMapping("/user/{id}") User findById(@PathVariable("id") Long id); } [email protected] private Us

新增配置 DataID：需要唯一不重复，建议使用 微服务名称 + 环境名 + 后缀名(yaml等) 启动流程 项目启动 读取 Nacos 配置文件，通过 bootstrap.yml 文件 读取本地配置文件 application.yml 创建 Spring 容器 加载 bean …… 读取配置 引入客户端依赖 <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency> 在项目的 resource 目录新增 bootstrap.yml 文件，此文件是引导文件，优先级高于 application.yml spring: application: name: userservic

角色注册中心一般有三种角色： 服务提供者：启动时，向 Nacos 注册服务信息。 服务消费者：定时（间隔30s）拉取服务（pull），将拉取的信息缓存在服务列表中。同时 Nacos 发现服务信息变更，会主动推送变更消息 （push）。 注册中心：Nacos 。 实例Nacos 会将服务提供者划分为 临时实例 和 非临时实例 ，Nacos 对这两种实例的健康监测是不一样的。默认情况下：所有的实例都是临时实例。推荐临时实例，非临时实例对服务器压力大。 临时实例：采用心跳监测。如果服务不存在，从列表中删除。 非临时实例：Nacos 发起请求检测。如果服务不存在，并不会从列表中删除，而是标记不健康，等待恢复健康。 配置非临时实例，通过更改项目配置spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: GZ namespace: 62c75d23-5839

Eureka 是 Netflix 开发的服务发现框架，本身是一个基于 REST 的服务，主要用于定位运行在 AWS 域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。 Spring Cloud 将它集成在其子项目 spring-cloud-netflix 中，以实现 Spring Cloud 的服务发现功能。Eureka 角色在 Eureka 架构中，微服务角色有两类：Eureka Server：服务端，注册中心 记录服务信息 心跳监控 Eureka Client：客户端 Provider：服务提供者 注册自己的信息到 Eureka Server 每隔 30 秒向 Eureka Server 发送心跳 Consumer：服务消费者 根据服务名称从 Eureka Server 拉取服务列表 基于服务列表做负责均衡，选中一个微服务后发起远程调用 搭建 Eureka Server 创建项目，引入下面依赖 <!-- https://mvnrepository.com/artifact/org.springframework.cloud/spr

服务拆分注意事项 不同微服务，不要重复开发相同业务。 微服务数据独立，不要访问其它微服务的数据库。 微服务可以将自己的业务暴露为接口，供其它微服务调用。 远程调用提供者与消费者 服务提供者：一次业务中，被其它微服务调用的服务（提供接口给其它微服务）。 服务消费者：一次业务中，调用其它微服务的服务（调用其它微服务提供的接口）。

微服务是一种经过良好架构设计的分布式架构方案，微服务具有以下特征： 单一职责：微服务拆分粒度更小，每个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发。 面向服务：微服务对外暴露业务接口。 自治：团队独立、技术独立、数据独立、部署独立。 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题。 架构优缺点单体架构简单方便、高度耦合、扩展性差，适合小型项目。将业务的所有功能集中在一个项目中开发，打成一个包部署。优点 架构简单 部署成本低 缺陷 耦合度高 分布式架构松耦合，扩展性好。但架构复杂，难度大。适合大型互联网项目。微服务是一种良好的分布式架构方案。优点 降低耦合度 有利于服务升级扩展 缺点 复杂度增加 部署难度增加 技术栈作用 \ 框架DubboSpring CloudSpring Cloud Alibaba注册中心ZooKeeper、RedisEureka、ConsulNacos、Eureka服务远程调用Dobbo 协议Feign (http 协议)Dubbo、Feign配置中心无Spring Cloud ConfigSpring C

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。分布式事务处理过程1个ID+3个组件transaction ID – XID全局唯一的事务ID3个组件 TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。 TM (Transaction Manager) - 事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。 RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。 处理过程 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID ； XID 在微服务调用链路的上下文中传播； RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖； TM 向 TC 发起针对 XID 的全局提交或回滚决议；

Ribbon 是什么Ribbon 是 Netflix 公司发布的一个客户端 IPC 库，主要提供以下功能： 负载均衡（Load Balance） 容错（Fault tolerance） 多协议支持（HTTP\TCP\UDP） 缓存和批处理 负载均衡方案主流的负载均衡策略可以分为两种：一种是集中式Load Balance(缩写：LB), 即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件，如F5, 也可以是软件，如nginx), 由该设施负责把访问请求通过某种策略转发至服务的提供方；另一种是进程内Load Balance，将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。Ribbon就属于后者，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。Ribbon 的均衡负载策略Ribbon 支持多种均衡负载策略，在源代码中，Ribbon 中的 IRule 接口代表均衡负载策略：实现类作用RoundRobinRule轮询策略RandomRule随机策略RetryRule先使用轮询策略，如果

在微服务架构中，微服务是完成一个单一的业务功能，这样做的好处是可以做到解耦，每个微服务可以独立演进。但是，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。服务熔断熔断机制是应对雪崩效应的一种微服务链路保护机制。当下游的服务因为某种原因突然变得不可用，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。需要说明的是熔断其实是一个框架级的处理，那么这套熔断机制的设计，基本上业内用的是断路器模式，如Martin Fowler提供的状态转换图如下所示 最开始处于closed状态，一旦检测到错误到达一定阈值，便转为open状态； 这时候会有个 reset timeout，到了这个时间了，会转移到half open状态； 尝试放行一部分请求到后端，一