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

转载：https://mp.weixin.qq.com/s/BhfjVuMwXkFFQhgvw2KypA日常开发中，为了更好管理线程资源，减少创建线程和销毁线程的资源损耗，我们会使用线程池来执行一些异步任务。但是线程池使用不当，就可能会引发生产事故。线程池默认使用无界队列，任务过多导致OOMJDK 为开发者提供了线程池的实现类，我们基于 Executors 组件，就可以快速创建一个线程池。日常工作中，一些小伙伴为了开发效率，反手就用Executors 新建个线程池。写出类似以下的代码：public class NewFixedTest { public static void main(String[] args) { ExecutorService executor = Executors.newFixedThreadPool(10); for (int i = 0; i < Integer.MAX_VALUE; i++) { executor.execute(() ->

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

概述从现代计算机中所有的数据二进制的形式存储在设备中。即 0、1 两种状态，计算机对二进制数据进行的运算都是叫位运算，即将符号位共同参与运算的运算。Java 中有以下的运算符：运算符名称示例结果说明<<左移4<<216符号左边的操作数左移指定的位数>>右移4>>12将符号的左边的操作数右移指定位数>>>无符号右移4>>>10将符号左边的操作数右移指定的位数&与运算4&20两个二进制位，只要有一个为0，那么结果就为0，否则结果为1|或运算4!26两个二进制位，只要有一个为1，那么结果就为1，否则结果为0^异或运算4^26相同二进制位，结果为0；不同的二进制位，结果为1~取反-4-5二进制位，0变1；1变0与、或、异或、取反class Playground {     public static void main(String[ ] args) {         int a = 3, b = 4;   &

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

TCC 一种成熟的分布式事务解决方案，可用于解决跨库操作的数据一致性问题。TCC 是 Try - Confirm - Cancel 缩写，TCC 事务与传统的数据库事务不同，它存在于业务层面，由系统业务逻辑（事务协调器），进行事务控制。TCC 将原业务服务，拆分为了三个操作。可将这三个操作，对应想象成三个方法，每个方法里有不同的业务代码。 Try：检查预留资源 Confirm：业务执行 Cancel：回撤 Try 里执行的操作 Try在 TCC 中，这是一个初步操作，从业务逻辑上来说，这只是检查资源（数据是否正确或业务上是否可执行等）的操作，真正执行实际业务更改是在 Confirm 中。也就是说，Try 操作过后，与后续执行的 Confirm 操作一起（Try - Confirm），才真正构成一个完整的业务逻辑。但如果 Try 操作出现异常，则会执行 Cancel 操作。（Try - Cancel）。TCC服务需要保证Try操作成功之后，Confirm操作一定能成功。Confirm是对 Try 操作的一个补充。当 TCC事务管理器 决定 commit 全局事务时，就会逐个执