SpringCloud微服务技术栈微服务治理异步通信技术—>mq缓存技术—>Redis搜索技术—>ES集群Devops—>Jenkins…微服务微服务是一种将各个模块拆分开独立运行以提高系统整体效率的技术，其主要特征为：单一职责：每个服务对应唯一的业务能力、做到单一职责。面向服务：对外要暴露微服务的业务接口自治：团队独立、技术独立、数据独立、部署独立，可以根据业务进行不同的技术选型隔离型强：服务的调用要做好隔离、容错、降级，避免出现一个模块的错误影响到其他模块的问题微服务框架国内的知名微服务框架有SpringCloud和Dubbo（阿里巴巴）用户访问服务网关，服务网关请求路由负载均衡（服务集群
版本Springboot版本采用的是最新的：parent>groupId>org.springframework.bootgroupId>artifactId>spring-boot-starter-parentartifactId>version>2.6.9version>relativePath/>parent>网关主要采用的是：dependency>groupId>org.springframework.cloudgroupId>artifactId>spring-cloud-starter-gatewayartifactId>dependency>dependency>groupId>
一、实现原理1、ConfigServer(配置中心服务端)从远端git拉取配置文件并在本地git一份，ConfigClient（微服务）从ConfigServer端获取自己对应配置文件；2、当远端git仓库配置文件发生改变，ConfigServer如何通知到ConfigClient端，即ConfigClient如何感知到配置发生更新？SpringCloudBus会向外提供一个http接口，即图中的/bus/refresh。我们将这个接口配置到远程的git的webhook上，当git上的文件内容发生变动时，就会自动调用/bus-refresh接口。Bus就会通知config-server，con
写在前面Feign是微服务中服务间调用的优选组件，后来的OpenFeign也是基于此来开展的。为什么要梳理一下Feign注解@FeignClient中的各个参数？踩坑太多面试总问参数一栏表@FeignClient的源码示例图如下：今天我们接着来说最后的几个参数。终于要大功告成了！fallbackFactoryfallbackFactory参数，和我们在上篇文章中学习的fallback很相似，可以说是具备fallback的功能，但比起fallback要更加完善。fallbackFactory是可以捕获到Feign接口所有发生的异常，并且同样可以实现fallback相关接口来进行自定义回滚代码或者
写在前面Feign是微服务中服务间调用的优选组件，后来的OpenFeign也是基于此来开展的。为什么要梳理一下Feign注解@FeignClient中的各个参数？踩坑太多面试总问参数一栏表@FeignClient的源码示例图如下：今天我们接着来说最后的几个参数。终于要大功告成了！fallbackFactoryfallbackFactory参数，和我们在上篇文章中学习的fallback很相似，可以说是具备fallback的功能，但比起fallback要更加完善。fallbackFactory是可以捕获到Feign接口所有发生的异常，并且同样可以实现fallback相关接口来进行自定义回滚代码或者
一、简介： Eureka是由Netflix公司开源的一款提供服务注册和发现的产品。因此，在添加依赖时，会有NetFlix。 该组件管理各种的服务功能：注册、发现、熔断、负载、降级等。 Eureka采用的是基于C/S的设计架构。 Eureka由两部分组成（Server/Client）：Eureka服务器和Eureka客户端。其中服务器可以用作服务注册服务器。而客户端是一个Java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。 由上图我们可以简单的看到Eureka组件的架构图，主要由三部分组成： EurekaServer：提供服务注
项目原来是单体架构，现拆分成springcloud微服务架构。过程中，整理了一下项目“认证授权”功能的微服务之间的调用思路：如下两个方法的切入点都是在ShiroConfig配置类（@Configuration）中@Bean注入的： 1shiroFilterFactoryBean-> JwtFilter中的onAccessDenied() ->无token：直接放过 -->登录/login --->远程调用oauth模块 ---->去验证(usern
Nacos、Eureka和Zookeeper都是服务注册中心，它们的主要功能是管理分布式系统中各个微服务实例的注册与发现。它们之间的主要区别在于：1.语言支持：Nacos是用Java语言开发的，Eureka是用Java语言开发的，Zookeeper则是用C语言开发的。2.功能特性：Nacos支持服务发现、配置管理、流量管理、DNS、动态DNS等多种特性，而Eureka只支持服务注册和发现功能，Zookeeper可以实现可靠的数据存储和协调。3.应用场景：Nacos适用于Kubernetes、ServiceMesh、SpringCloud等云原生场景，Eureka适用于SpringCloud
一：两个工作原理 二：相同点1.都支持服务注册和服务拉取。2.都支持服务提供者心跳方式做健康检测。三：区别 1.Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式 2.临时实例心跳不正常会被剔除，非临时实例则不会被剔除 3.Nacos支持服务列表变更的消息推送模式，服务列表更新更及时 4.Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式四：个人理解 1.在提供者和注册中心之间。 1.Eureka中会定时向注册中心发送心跳，如果在短期内没有发送心跳，则就会直接剔除。
在传统的单体应用中，所有的业务都集中在一个服务器中，当浏览器发起请求时，通过前端请求调用后端接口，后端接口调用相应的业务并在前端进行响应，整个的调用就是从请求到响应的一条龙服务。所以不存在服务之间的中转，也就不存在注册中心。 但是随着项目越做越大，传统的单体项目已经无法满足我们的需求（用户数量增加，业务功能增多，服务器压力变大），所以我们需要用微服务思想，对项目进行拆分，拆分后的每个模块都会再一个服务器上独立的运行。虽然解决了一些单体项目所带来的的诸多瓶颈，但是又有一个新的问题产生，就是模块与模块之间的调用，一个模块的使用可能需要依赖很多模块，例如A调用B，那么就要在A中写上
