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状态; 尝试放行一部分请求到后端,一