当前位置： 首页 > news >正文

网站支付按钮怎么做,精品课程云网站建设,周村网站制作价格低,长沙网站seo价格一、微服务演变 1、单体架构#xff08;Monolithic Architecture#xff09; 是一种传统的软件架构模式#xff0c;应用程序的所有功能和组件都集中在一个单一的应用中。 在单体架构中#xff0c;应用程序通常由一个大型的、单一的代码库组成#xff0c;其中包含了所有… 一、微服务演变 1、单体架构Monolithic Architecture 是一种传统的软件架构模式应用程序的所有功能和组件都集中在一个单一的应用中。 在单体架构中应用程序通常由一个大型的、单一的代码库组成其中包含了所有的功能模块和业务逻辑。这个应用程序作为一个整体部署和运行在一个应用服务器上并共享相同的内存和数据库。 当单体架构项目的性能无法满足需求时但又希望继续沿用单体架构的话你可以采取以下一些优化手段来改善性能如以下方法 使用缓存引入缓存机制将经常请求的数据缓存起来减少对数据库等后端系统的访问以提高性能。 数据库优化进行数据库性能调优包括建立索引、优化查询语句、使用合适的数据库引擎等以提高数据库的响应速度。 使用消息队列引入消息队列来解耦耗时操作将其转化为异步的处理任务。这样可以提高并发处理能力和系统的响应性能。 水平扩展通过复制多个实例来处理更多的请求。可以使用负载均衡器将请求分发到不同的实例上从而提高系统的整体性能和容量。 引入分布式架构将应用程序拆分为多个独立的服务并通过网络进行通信和协作。这样可以将负载分散到多个节点上提高整体性能和可伸缩性。 接下来就说一下单体架构优化中的引入分布式架构。 2、分布式架构 将系统的各个组件部署在不同的计算机节点上并通过网络进行通信和协作的软件架构模式。在分布式架构中各个节点可以独立运行和处理任务并通过消息传递、远程过程调用或其他通信机制进行数据交换和协调。 在使用分布式时我们就会有一下的疑问 服务拆分到什么程度服务集群地址如何维护服务之间如何实现远程调用服务健康状况如何感知 3、微服务 微服务是一种经过改良好的架构设计的分布式架构方案微服务架构特征 单一职责微服务拆分力度更小每个服务都对应唯一的服务能力做的单一职责避免重复开发面向服务微服务对外暴露业务接口自治团队独立、技术独立、数据独立、部署独立隔离性强服务调用做好隔离、容错、降级避免出现级联问题 假如我们有一个电商系统其中有以下一些微服务 用户服务User Service负责用户的注册、登录、信息管理等功能。商品服务Product Service负责商品的查询、添加、更新等功能。订单服务Order Service负责订单的创建、支付、取消等功能。 现在假设用户服务依赖于商品服务来获取商品信息并且订单服务依赖于用户服务来获取用户信息。这里我们可以看到微服务的几个特征是如何应用的 单一职责每个微服务都具有清晰的职责。例如用户服务只负责用户相关的功能而不涉及商品或订单。面向服务每个微服务都对外暴露业务接口其他微服务可以通过调用这些接口来访问所需的功能。例如用户服务可以提供获取用户信息的接口给订单服务使用。自治每个微服务的团队在技术和数据上都是独立的。例如用户服务的团队可以独立开发、测试、部署和扩展该服务无需依赖其他团队。隔离性强微服务之间的调用需要做好隔离、容错和降级以避免出现级联问题。例如当商品服务不可用时用户服务可以使用缓存或默认数据来避免影响用户操作。 这个例子中提供了不同的微服务来处理不同的功能并且彼此解耦、独立运行。每个微服务都具有单一职责对外提供明确定义的业务接口团队在技术和数据上具有自治能力同时采取适当的隔离措施来保证系统的弹性和稳定性。这些特征有助于提高开发效率、灵活性和可维护性使得微服务架构在构建大型、复杂系统时具有优势。 4、 总结 单体架构特点简单方便高度耦合扩展性差合适小型项目。如:学生管理系统。 分布式架构特点:松耦合扩展性好但架构复杂难道大适合大型互联网项目。如:京东、淘宝 微服务一种良好的分布式架构方案。 优点拆分粒度更小、服务更独立、耦合更低缺点架构非常复杂运维、监控、部署难道更高 5、微服务架构 微服务这方案需要技术框架来落地实现全球的互联网公司都在积极尝试自己的微服务落地技术。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。 5.1、 微服务技术对比 Dubbo、Spring Cloud、Spring Cloud和Spring Cloud Alibaba都是用于构建分布式系统的开源框架。尽管它们的目标相同但它们在实现方式和功能特点上有所不同。 DubboDubbo是一个高性能的分布式服务框架由阿里巴巴开发。它基于传统的服务治理理念提供了服务注册、发现、路由、负载均衡、容错等功能。Dubbo的核心特点是高性能和低延迟的RPC调用适用于大规模的微服务架构。Dubbo提供了对多种协议如Dubbo协议、REST协议和注册中心如ZooKeeper、Consul的支持。 Spring CloudSpring Cloud是一个由Pivotal开发的微服务框架构建在Spring Framework之上使得构建分布式系统更加便捷。它提供了一系列的组件和模块用于实现服务注册与发现、负载均衡、断路器、配置管理、消息总线等功能。Spring Cloud采用了Spring Boot作为底层的开发框架提供了更简洁、快速搭建分布式系统的解决方案。 Spring Cloud AlibabaSpring Cloud Alibaba是Spring Cloud与Alibaba开放平台合作的结果提供了一些在云原生应用开发中常用的解决方案。它主要基于Spring Cloud框架结合了一些Alibaba技术栈如Nacos服务注册与发现、Sentinel流量控制和熔断降级、RocketMQ消息驱动等。Spring Cloud Alibaba旨在提供云原生应用开发的全栈解决方案。
虽然Dubbo和Spring Cloud都是用于构建分布式系统的框架但Dubbo更加注重于高性能的RPC调用和服务治理而Spring Cloud则提供了一整套更全面的微服务解决方案。而Spring Cloud Alibaba则是在Spring Cloud的基础上进一步整合了Alibaba的一些技术为云原生应用提供更全面的开发支持。选择适合的框架取决于具体的需求、技术栈和团队偏好。 5.2、企业需求 Spring Cloud Spring Cloud AlibabaSpring Cloud提供了丰富的微服务组件和解决方案包括服务注册与发现、负载均衡、断路器、配置管理等。Spring Cloud Alibaba扩展了Spring Cloud整合了阿里巴巴技术栈如Nacos服务注册与发现、Sentinel流量控制和熔断降级、RocketMQ消息驱动等。组合使用这两个框架可以获得全面的云原生应用开发解决方案适用于构建现代化的微服务架构。 Dubbo原生模式 Spring Cloud AlibabaDubbo是一个高性能的RPC框架提供了服务治理、负载均衡、容错等功能。Spring Cloud Alibaba扩展了Dubbo为Dubbo提供了更多云原生的支持如Nacos作为注册中心、Sentinel用于流量控制和熔断降级等。通过将Dubbo和Spring Cloud Alibaba集成可以获得高性能的RPC调用和全面的云原生的服务治理解决方案。
无论是使用Spring Cloud Spring Cloud Alibaba还是Dubbo原生模式 Spring Cloud Alibaba都可以受益于Spring Cloud和Spring Cloud Alibaba提供的丰富的微服务功能和云原生支持。具体选择哪种组合取决于企业需求、技术栈和团队实际情况。需要评估技术要求、性能需求、开发复杂度等因素选择适合的框架组合来构建稳定、高效的分布式系统。 二、spring cloud SpringCloud是目前国内使用最广泛的微服务框架。官网地址: Spring Cloud SpringCloud集成了各种微服务功能组件并基于SpringBoot实现了这些组件的自动装配从而提供了良好的开箱即用体验: springCloud与SpringBoot的版本兼容关系 本文学习版本是Hoxton.SR10因此对应的springboot版本是2.3.x版本。 1、服务拆分及远程调用 1.1、服务拆分 1.1.1、服务拆分注意事项 不同微服务不要重复开发相同业务微服务数据独立不要访问其他微服务的数据库微服务可以将自己的业务暴露为接口供其它微服务调用 1.1.2、项目实战 实战代码阿里云下载 把数据库文件那到数据库管理工具里执行和idea中导入cloud-demo项目 最终数据库结构 对与cloud-demo这个项目主要看一下用户和订单如何进行项目拆分的结合这单体架构的结果对比一下有什么变化和不同。 1.1.3、总结 微服务需要根据业务模块拆分做到单一职责不要重复开发相同业务。微服务可以将业务暴露为接口供其他微服务使用。不同微服务都应该有自己独立的数据库。 1.2、远程调用 需求根据订单id查询订单的同时把订单所属的用户信息一起返回。 1.2.1、远程调用方法 在我们的controller类中使用GetMapping(/user/{id})向外暴露了一个接口来访问可以将user信息放回为json数据格式我们可以想一下浏览器可以发一个Ajax请求来获取数据我们的订单服务可不可以发一个Ajax请求来获取数据呢 1.2.2、实现远程调用步骤 1注册RestTemplate Spring Cloud中也使用了RestTemplate类。RestTemplate是Spring框架中的一部分它在Spring Cloud项目中被广泛用于进行微服务之间的通信。在微服务架构中各个微服务之间通常通过RESTful API进行通信。为了简化这个过程Spring Cloud对RestTemplate进行了增强以便更好地支持微服务架构。在Spring Cloud中RestTemplate被称为服务调用的一部分。通过使用RestTemplate开发人员可以方便地发起HTTP请求来调用其他微服务的API。Spring Cloud还提供了一些增强功能例如服务发现和负载均衡。开发人员可以使用服务名代替具体的URLSpring Cloud会自动根据服务名找到可用的实例并进行负载均衡从而实现更灵活和高效的服务调用。需要注意的是自Spring Cloud 2020.0.0版本即Hoxton.SR9及之后的版本开始官方推荐使用WebClient替代RestTemplate作为HTTP客户端因为WebClient提供了更强大、更灵活的功能并且更适用于非阻塞的响应式编程模型。但是为了向后兼容RestTemplate仍然可以继续使用并被支持。在order-service的OrderApplication中注册ResteTemplate将ResteTemplate用Bean注解注册为spring管理的对象以后不管在什么地方都可以使用到RestTemplate对象。 完成调用主要是在service层中实现向被调用服务发起一个Rest请求在需要调用其他服务的服务中使用实现步骤 1、在服务启动类中注册RestTemplate如这里是在order的启动类中 2、在要调用其他服务的服务中的service层中自动装配RestTemplate对象 3、使用RestTemplate的api来实现即可里面有很多api这里我使用的是getForObject()方法 4、将远程调用返回的数据封装到要封装的对象中即可这里我使用的是将远程调用获取的user对象信息封装到order对象中。 1.3、提供者与消费者 服务提供者一次业务中被其他微服务调用的服务。提供接口给其他服务调用如user服务 服务消费者一次业务中调用其他微服务的服务。调用其他微服务提供的接口如order服务 总结 1.服务调用关系 服务提供者:暴露接口给其它微服务调用                           服务消费者:调用其它微服务提供的接口                           提供者与消费者角色其实是相对的                           一个服务可以同时是服务提供者和服务消费者 三、Eureka注册中心 1、服务调用出现的问题 在前面我们使用RestTemplate来实现服务远程调用在写url时使用的是硬编码方式就会产生以下的问题这些问题是值得我们考虑一下的。 服务消费者该如何获取服务提供者的地址信息?如果有多个服务提供者消费者该如何选择?消费者如何得知服务提供者的健康状态? 2、 Eureka基本原理 Eureka是Netflix开源的服务治理框架在Spring Cloud中广泛应用。它的基本原理是建立了一个分布式的服务注册中心用于管理和维护各个微服务实例的注册和发现。 以下是Eureka的基本原理 Eureka服务器Eureka由一个或多个Eureka服务器组成它们构成了服务注册中心。每个微服务实例都将自己的信息注册到Eureka服务器包括服务名、主机名、端口号等。 服务注册微服务启动时会向Eureka服务器发送注册请求将自己的信息注册到注册中心。注册中心维护一个服务注册表记录所有已注册的微服务实例。 服务发现其他微服务需要调用某个服务时首先向注册中心发送查询请求获得目标服务的实例列表。注册中心将会返回所有可用的服务实例信息包括IP地址、端口号等。 服务监控Eureka服务器会定期向已注册的微服务实例发送心跳请求微服务实例返回响应以证明自己的健康状态。如果一个微服务长时间未发送心跳消息或返回异常状态Eureka服务器将从注册表中删除该实例。 服务同步Eureka服务器之间会相互复制注册表信息以保证数据的一致性。当有新的微服务实例注册或注销时注册中心会通知其他服务器进行注册表更新。
通过Eureka提供的服务注册和发现机制微服务之间可以动态地发现和调用其他微服务从而实现了服务之间的解耦和灵活性。Eureka还提供了负载均衡、故障恢复等一些附加功能使得微服务架构更加可靠和高效。 回顾之前我们的几个问题 消费者该如何获取服务提供者具体信息? 服务提供者启动时向eureka注册自己的信息eureka保存这些信息消费者根据服务名称向eureka拉取提供者信息 如果有多个服务提供者消费者该如何选择? 服务消费者利用负载均衡算法从服务列表中挑选一个 消费者如何感知服务提供者健康状态? 服务提供者会每隔30秒向EurekaServer发送心跳请求报告健康状态eureka会更新记录服务列表信息心跳不正常会被剔除消费者就可以拉取到最新的信息 总结 在Eureka架构中微服务角色有两类 1、EurekaServer:服务端注册中心 记录服务信息心跳监控 2、EurekaClient: 客户端 1Provider:服务提供者例如案例中的 user-service 注册自己的信息到EurekaServer              每隔30秒向EurekaServer发送心跳 2consumer:服务消费者例如案例中的 order-service 根据服务名称从EurekaServer拉取服务列表                    基于服务列表做负载均衡选中一个微服务后发起远程调用 3、手动实战 3.1、搭建eureka服务注册中心服务名称 1、创建项目引入spring-cloud-starter-netflix-eureka-server的依赖 dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-netflix-eureka-server/artifactId/dependency2、启用Eureka服务器创建一个启动类并使用EnableEurekaServer注解来启用Eureka服务器功能。 SpringBootApplication EnableEurekaServer public class EurekaApplication {public static void main(String[] args) {SpringApplication.run(EurekaApplication.class,args);} }3、配置Eureka服务器在应用程序的配置文件如application.properties或application.yml中配置Eureka服务器的相关信息例如

服务器配置

server:port: 10001 # Eureka服务器运行的端口号# Spring应用程序配置 spring:application:name: eurekaserver # Eureka服务器应用程序的名称# Eureka客户端配置 eureka:client:service-url:defaultZone: http://localhost:10001/eureka/# Eureka客户端注册自身的Eureka服务器的URL# 在本例中将Eureka服务器的URL设置为运行在10001端口的本地服务器3.2、注册user-service 这个操作是在user-service项目下实现的,主要是将服务信息注册到Eureka服务端eureka将这些服务信息保存到注册表中进行管理。 将user-service服务注册到EurekaServer步骤 1、在user-service项目中引入spring-cloud-starter-netflix-eureka-client的依赖 dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-netflix-eureka-client/artifactId/dependency2、在application.yml位置文件中编写配置 spring:application:name: userservice #配置服务名称 eureka:client:service-url:defaultZone: http://localhost:10001/eureka/ #配置eureka服务地址信息其实orderservice的注册也是这两个步骤我就写了。 做完之后我我们可以浏览一下eureka的服务网站看一下http://localhost:10001 这里的端口号是你在自己的eureka的配置文件application.yml配置的eureka端口号一致。 总结 1.服务注册 引入eureka-client依赖在application.yml中配置eureka地址 2.无论是消费者还是提供者引入eureka-client依赖 知道eureka服务注册中心地址后都可以完成服务注册 3.3、在order-service完成服务拉取 服务拉取是基于服务名称获取服务列表然后在对服务列表做负载均衡 1.修改OrderService的代码修改访问的url路径用服务名代替ip、端口: String url http://userservice/user/ order.getUserId(); 2.在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解: Bean LoadBalanced #负载均衡 public RestTemplate restTemplate() {return new RestTemplate(); }总结 1.搭建EurekaServer 引入eureka-server依赖添加EnableEurekaServer注解在application.yml中配置eureka地址 2.服务注册 引入eureka-client依赖在application.yml中配置连接eureka服务注册中心地址 3.服务发现 引入eureka-client依赖在application.yml中配置eureka服务注册中心地址给RestTemplate添加LoadBalanced注解用服务提供者的服务名称远程调用 四、Ribbon负载均衡 Ribbon是一个负载均衡解决方案主要用于在分布式系统中将负载均匀地分发给多个服务实例。它是Netflix开 源的一个组件常用于微服务架构中。 1、负载均衡流程 Ribbon的负载均衡原理可以概括如下 服务注册Ribbon首先需要与服务注册中心如Eureka、Consul等进行交互获取可用的服务实例列表。 负载均衡策略Ribbon支持多种负载均衡策略如随机策略、轮询策略、权重策略等。根据选择的策略Ribbon会根据服务实例的状态、性能等因素来选择一个合适的服务实例。 服务调用一旦选择了一个服务实例Ribbon会将请求发送给该实例。它会维护一个与服务实例的长连接并在需要时将请求发送给该实例。 失败处理如果请求在与服务实例的通信中失败Ribbon会尝试选择另一个可用的服务实例进行重试以增加系统的可用性。
Ribbon还可以与其他组件配合使用例如Netflix的Hystrix熔断器用于实现服务的容错和故障保护。 总之Ribbon通过动态获取服务实例列表并根据负载均衡策略选择合适的实例来进行负载均衡从而提高系统的性能、可用性和可扩展性。 源码执行流程 2、Ribbon负载均衡策略 Ribbon负载均衡规则是一个叫做IRule的接口来实现的每个子接口都是一种规则 2.1、 负载均衡策略 2.2、调整负责均衡策略的规则 通过定义IRule实现可以修改负载均衡规则有两种方式 方式一代码方式 如消费者服务order-service只要在OrderApplication类中定义一个新的IRule Bean public IRule iRule(){return new RandomRule(); }其实也不一定要在OrderApplication启动类中配置也可以自己创建一个配置类来配置在有configuration注解的类就可以。 这种配置方案是全局的配置只要使用了这种配置方案以后不管你调用的是user-service服务还是order-service服务都是使用这里的配置方案。 方式二配置文件方式 在order-service的application.yml文件中添加新的配置也可以修改规则 userservice: #被调用微服务器的服务名称ribbon:NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #负载均衡规则这种配置方案是只针对某个微服务的是局部配置。 3、Ribbon饿加载 Ribbon默认是采用懒加载即第一次访问才会创建LoadBalanceClient请求时间会很长。 而饿加载则会在项目启动时创建降低每一次访问的耗时 3.1、配置开启配置饥饿加载 #当服务饥饿加载 ribbon:eager-load:enabled: true #开启饥饿加载clients: userservice #指定对userservice这个服务饥饿加载#当有多个服务需要饥饿加载可以用下面的方式 ribbon:eager-load:enabled: true #开启饥饿加载clients: #指定对userservice这个服务饥饿加载- userservice - xxservice总结 1.Ribbon负载均衡规则 规则接口是IRule默认实现是ZoneAvoidanceRule根据zone选择服务列表然后轮询 2.负载均衡自定义方式 代码方式:配置灵活但修改时需要重新打包布配置方式:直观方便无需重新打包发布但是无法做全局配置 3.饥饿加载 开启饥饿加载指定饥饿加载的微服务名称 五、Nacos注册中心 微服务的注册中心我们已经学了eureka大家肯定会有疑问为啥还有学校nacos呢 其实nacos不仅有服务注册中心和服务发现功能还有更加强大的功能。 1、nacos和eureka对比 Nacos和Eureka是两个常用的服务发现和注册工具它们都具有类似的功能但在一些方面存在一些差异。以下是Nacos和Eureka的一些对比 开发者生态圈Nacos是由Alibaba开发并开源拥有庞大的Alibaba生态圈支持而Eureka是由Netflix开发并开源得到了Netflix和Spring Cloud社区的广泛应用。 功能和特性Nacos提供了更多的功能和特性除了服务注册与发现外还包括配置管理、动态DNS、动态路由和流量管理等功能。Eureka主要关注服务注册与发现的功能。 容错性Nacos具有更强的容错性支持多数据中心的分布式部署可以保证在网络分区和节点故障情况下的高可用性。Eureka在这方面的容错性相对较弱。 数据一致性Nacos使用Raft算法来实现数据一致性和高可用性而Eureka使用的是AP模型即优先保证可用性而不保证强一致性。 社区活跃度Nacos的开源社区活跃度相对较高有更多的贡献者和更新的版本发布。Eureka的开源社区相对较少活跃更新较为缓慢。
选择使用Nacos还是Eureka可以根据具体需求和项目背景来决定。如果需要更多的功能和特性以及较强的容错性和高可用性Nacos可能是更好的选择。如果项目已经依赖于Netflix和Spring Cloud生态圈或者对于服务注册和发现的简单功能需求Eureka可能是更适合的选项。 2、Nacos下载安装服务注册中心 2.1下载nacos 在Nacos的GitHub页面提供有下载链接可以下载编译好的Nacos服务端或者源代码 GitHub主页https://github.com/alibaba/nacos GitHub的Release下载页https://github.com/alibaba/nacos/releases 这里我提供了阿里云盘下载Nacos1.4.1 2.2、解压Nacos 我这里使用的是在Windows下安装的。 直接解压到一个没有中文字符的路径下。 目录说明

• bin启动脚本- conf配置文件 2.2.1、配置端口 Nacos的默认端口是8848如果你电脑上的其它进程占用了8848端口请先尝试关闭该进程。 如果无法关闭占用8848端口的进程也可以进入nacos的conf目录修改配置文件中的端口 修改其中的内容修改为一个没有被占用的端口号。 2.2.2.启动nacos服务注册中心 启动非常简单进入bin目录进入cmd窗口执行下面的命令 startup.cmd -m standalone#startup.cmd -m standalone 的含义是执行Nacos服务器的启动脚本并使用独立模式启动Nacos服务器。 #这将在单个节点上运行Nacos并使用默认的配置文件和端口。这个命令适用于简单部署或测试并非生产环境下常见的集群模式启动命令。执行后的效果如图  在浏览器输入地址http://127.0.0.1:8848/nacos即可 用户名和密码都是nacos 网页直接就是中文的对于英语不太好的比eureka的友好。 3、将服务注册到nacos服务注册中心 1、在cloud-demo父工程中添加spring-cloud-alibaba的管理依赖 !–nacos版本管理–dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-alibaba-dependencies/artifactIdversion2.2.5.RELEASE/versiontypepom/typescopeimport/scope/dependency2、注释掉order-service和user-service中原有的eureka依赖。 3、添加nacos的客户端依赖 !– nacos客户端依赖包 –dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId/dependency4、修改user-service order-service中的application.yml文件注释掉eureka的地址添加nacos地址 spring:cloud:nacos:server-addr: localhost:8848启动项目测试 其实eureka和nacos在spring-cloud中除了依赖和端口号配置不同外其他的使用都是一样的他们底层使用的接口都是一样的所以代码其他地方根本不用做改变。 总结 1.Nacos服务搭建 下载安装包解压在bin目录下运行指令:startup.cmd -mstandalone 2.Nacos服务注册或发现 引入nacos.discovery依赖配置nacos地址spring.cloudnacos.server-addr 4、Nacos服务分级存储模型 之前我们在学中我们的服务分层都是只有两层的第一层是服务第二层是实例如user-service、order-service在我们部署时都是将这些服务我实例部署到一个机器上或者一个机房里但是如果这个机房收到破坏地震、火灾时服务就无法访问了。 而nacos服务分层存储模型则引出了集群的概念一个集群就好比是我们的一个机房而我们的一个服务下面就可以部署很多个集群每个集群就可以部署在全球各地北京、上海、深圳等因此服务的层次结构就变成了三层服务、集群、实例。 4.1、服务跨集群调用问题 服务调用尽可能选择本地集群的服务跨集群调用延迟高本地集群不可以访问时在去访问其他集群 4.2、服务集群实现 1、修改application.yml添加如下内容配置服务集群名称 spring:cloud:nacos:server-addr: localhost:8848 #nacos 服务端地址cluster-name: YN #配置集群名称也就是机房位置例如YN ,云南2、在Nacos控制台可以看到集群变化 现在的集群变成了yn在没有配置集群名称是default。 总结 1.Nacos服务分级存储模型 一级是服务例如userservice二级是集群例如杭州或上海三级是实例例如杭州机房的某台部署了userservice的服务器 2.如何设置实例的集群属性 修改application.yml文件添加spring.cloud.nacos.discovery.cluster-name属性即可 4.3、Nacos集群负载均衡 Nacos集群负载均衡的规则其实是优先选择本集群内的服务如果本服务挂了才会去选择其他集群的服务来访问。 配置 1、修改order-service中的application.yml设置集群为HZ: spring:cloud:nacos:server-addr: Localhost:8848 # nacos 服务端地加discovery:cLuster-name: HZdiscovery:cluster-name: bj #配集群名称也就是机房位置2、然后在order-service中设置负载均衡的IRule为NacosRule这个规则优先会寻找与自己同集群的服务: userservice: #服务名称ribbon:NFLoadBalancerRulecassName: com.alibaba.cloud.nacos.ribbon.NacosRule #负载均衡规则3、注意将user-service的权重都设置为1 总结 1.NacosRule负载均衡策略 优先选择同集群服务实例列表本地集群找不到提供者才去其它集群寻找并且会报警告确定了可用实例列表后再采用随机负载均衡挑选实例 4.4、根据权重负载均衡 假设有一个微服务架构的电子商务网站其中包括以下几个服务商品服务、订单服务和用户服务。这些服务都注册到了Nacos中进行服务发现并且它们有不同的实例数和性能配置。在这种情况下可以通过基于权重的负载均衡来实现对这些服务实例的合理请求分配。以下是一些示例场景 不同实例性能差异较大 假设商品服务有3个实例其中实例A和实例B配置较高实例C配置较低。此时可以设置实例A和实例B的权重为2实例C的权重为1。这样每次有请求到来时有较高性能的实例A和实例B将会处理更多的请求而较低性能的实例C将会处理较少的请求从而实现了性能调控。 服务实例容量不均衡 假设订单服务有5个实例其中实例A、B和C的容量比实例D和E大。可以为实例A、B和C设置较高的权重值如3而为实例D和E设置较低的权重值如1。这样请求将均衡分配到实例A、B和C之间并保持实例D和E的请求数较少。 降低故障实例的负载 假设用户服务有4个实例其中实例A由于某种原因出现了故障或不稳定情况。为了减少对实例A的请求分配可以为其设置较低的权重值如0而将其他正常的实例设置为较高的权重值如3。这样请求将主要被分配给其他正常的实例降低了对故障实例A的负载。
  通过在Nacos中设置服务实例的权重可以根据实际情况动态调整请求的负载比例。这样能够充分利用资源、提高系统性能、保证服务稳定性并对不同实例进行合理分配。 Nacos提供了权重配置来控制访问频率权重越大则访问频率越高。 配置 4.5、环境隔离-namespace 1、认识环境隔离-namvespace 应用场景 假设有一个电商平台该平台设计了一个基于Nacos的命名空间配置和服务注册方案以支持环境隔离和多租户功能。 首先假设该电商平台有三个环境开发环境、测试环境和生产环境。每个环境都有独立的配置和服务需求。 环境隔离和配置管理 使用Nacos的命名空间功能平台管理员可以创建三个命名空间dev-namespace、test-namespace和prod-namespace。 在dev-namespace中可以配置开发环境所需的各种参数如数据库连接信息、调试模式等。 在test-namespace中可以配置测试环境所需的参数如测试数据库连接信息、测试数据源等。 在prod-namespace中可以配置生产环境所需的参数如正式数据库连接信息、生产级别的服务配置等。 每个命名空间下的配置项是相互隔离的这样就保证了不同环境配置的独立性并且可根据需求灵活管理和更新配置信息。 服务注册和版本管理 在每个命名空间中可以注册相应环境需要的服务实例如商品服务、订单服务等。 平台管理员可以使用命名空间功能来管理不同环境的服务注册表确保每个环境只能访问属于自己的服务实例。 每个命名空间可以独立管理服务实例的版本例如在开发环境中可以注册和测试新的服务版本而在生产环境中则使用稳定的服务版本。
  通过这样的命名空间配置和服务注册方案电商平台能够实现对不同环境的配置和服务进行隔离并支持多租户功能。开发团队可以独立管理各自环境的配置和服务而不会相互干扰。此外平台还可以利用灰度发布和版本管理功能在不同命名空间中进行服务版本控制确保系统稳定性和可用性。 2、配置命名空间 1创建命名空间在nacos服务页面创建 2、将服务配置到指定的命名空间中修改application.yml配置文件 server:port: 8081 spring:datasource:url: jdbc:mysql://192.168.10.130:3306/cloud-user?useSSLfalseusername: rootpassword: rootdriver-class-name: com.mysql.jdbc.Driverapplication:name: userservice #配置服务名称cloud:nacos:server-addr: localhost:8848discovery:cluster-name: yn #集群名称地址在云南namespace: 074da7cb-c3e3-4848-b893-3d15114e8729 #命令空间id此时配置了namespace的服务已经被配置到dev中了 如果此时使用order-service去调用user-service就会报错了 Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.IllegalStateException: No instances available for userservice] with root causeservlet .service()的servlet [dispatcherServlet]在上下文与路径[]抛出异常[请求处理失败;嵌套异常是java.lang.IllegalStateException: No instances available for userservice]有根本原因5、nacos注册中介细节分析 服务注册服务提供者启动时会向服务注册中心发起注册请求包括服务名、IP 地址、端口等。注册中心会将这些信息保存起来。 服务发现服务发现有两种pull和push相结合 pull服务消费者会每隔30秒定时主动向服务注册中心发起请求来拉取服务信息在服务消费者中有一个服务列表缓存用于缓存从服务注册中心拉取下的服务信息。push当有服务停掉后服务注册中心会主动推送变更信息给消费者消费者就会更新服务列表缓存。 心跳与健康检查也是有两种对临时实力和非临时实例 临时实例采用心跳检测是临时实例主动向注册中心发送心跳检测如果一段时间注册中心没有收到临时实例心跳检测就会剔除该临时实例。非临时实例采用nacos主动询问nacos主动询问非临时实例的健康状态如果非临时实例停止了也不会剔除非临时实例只是修改非临时实例的健康转态会等待非临时实例健康。 负载均衡负载均衡和流量控制是由服务消费者一侧的客户端组件来实现的而不是由注册中心来处理。当客户端从Nacos注册中心获取到可用的服务实例列表后负载均衡和流量控制的责任落在了客户端的实现上。 5.1、临时实例与非临时实例 Nacos中的实例分为临时实例和非临时实例它们在生命周期和用途上有所不同 1、非临时实例Persistent Instance 非临时实例是指注册到Nacos注册中心的服务实例其生命周期不会受到外部因素的影响除非主动取消注册或服务下线。这种实例适用于通常情况下稳定运行的服务它们的注册信息会被持久化存储在Nacos服务器中提供持久性的服务发现和注册功能。 2、临时实例Ephemeral Instance 临时实例是指服务实例在持有连接的客户端断开连接时会自动从Nacos注册中心上注销的一种实例类型。当客户端与Nacos注册中心建立心跳连接后临时实例会周期性地向注册中心进行连接进行检测。如果一段时间注册中心没有收到临时实例的心态检测注册中心会将对应的实例注销。临时实例适用于动态扩缩容、临时性访问等场景允许实例根据连接状态进行动态管理。 临时实例和非临时实例在实践中有不同的应用场景 对于稳定运行的服务应使用非临时实例。这样服务实例的注册信息将持久存在于注册中心中即使服务发生故障或重启也能保证注册信息的持久性其他服务能够继续发现和使用该实例。 对于临时性的任务如定时任务、临时数据处理服务等可以选择使用临时实例。这样在任务完成后实例会自动注销降低注册中心中无用实例的数量也能更好地适应动态需求变化。
  需要注意的是临时实例的自动注销是基于与Nacos注册中心之间的心跳连接而非基于服务实例的具体运行状态。因此在使用临时实例时需要相应地配置和管理心跳连接以保证实例的不间断注册和注销。 5.2、配置临时实例与非临时实例默认是临时实例 服务注册到nacos时可以选择注册为临时或非临时实例通过在application.yml文件中添加下面的配置来设置 spring:cloud:nacos:discovery: #discovery发现透露 ephemeral短暂的ephemeral: false #设置为非临时实例总结 1.Nacos与eureka的共同点 都支持服务注册和服务拉取都支持服务提供者心跳方式做健康检测 2.Nacos与Eureka的区别 Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式非临时实例采用主动检测模式临时实例心跳不正常会被剔除非临时实例则不会被剔除Nacos支持服务列表变更的消息推送模式服务列表更新更及时Nacos集群默认采用AP方式当集群中存在非临时实例时采用CP模式;Eureka采用AP方式 6、Nacos配置管理 以下是几个使用Nacos配置管理的实际业务场景的例子 微服务配置管理 假设你的公司采用了微服务架构有多个微服务需要连接到不同的数据库。通过使用Nacos配置管理你可以将每个微服务的数据库连接信息存储在Nacos中并动态地更新配置。例如当你需要更改数据库的连接地址或密码时你可以直接在Nacos中修改配置而无需重新部署微服务所有微服务将自动获取最新的配置信息。 多环境配置管理 假设你的应用在开发、测试和生产环境中运行并且每个环境都有不同的配置。使用Nacos配置管理你可以为每个环境创建不同的配置文件并通过Nacos的命名空间和配置组进行组织。开发人员可以通过选择不同的命名空间和配置组轻松地切换到不同的环境而不必手动修改配置文件。 动态路由配置 假设你的微服务架构中使用了Spring Cloud Gateway作为API网关并且你希望能够动态路由请求到不同的后端服务。通过使用Nacos配置管理你可以将路由规则存储在Nacos中并通过Spring Cloud Gateway与Nacos集成。当需要更新路由规则时你可以直接在Nacos中修改配置Spring Cloud Gateway将自动更新路由并将请求动态地转发到相应的后端服务。 定时任务配置 假设你的应用需要执行定时任务例如生成报表或清理数据。通过使用Nacos配置管理你可以将定时任务的触发时间、任务参数等信息存储在Nacos中并由任务调度器定期从Nacos获取最新的配置。当你需要调整定时任务的执行时间或参数时只需在Nacos中修改配置任务调度器将自动根据最新的配置执行任务。
  这些例子只是Nacos配置管理功能的一部分Nacos还提供了更多的特性例如配置监听、配置推送等可以根据具体的业务需求进行灵活使用。 6.1、统一配置管理 6.1.1、配置更改热更新 在Nacos中添加配置信息 在弹出表单中填写配置信息 在nacos服务页面中配置让服务找到nacos的配置 1、引入nacos的配置管理客户依赖 !–nacos配置管理依赖–dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-config/artifactId/dependency2、在userservice中的resource目录添加一个bootstrap.yml文件这个文件是引导文件优先级高于application.yml spring:application:name: userservice #配置服务名称cloud:nacos:server-addr: localhost:8848 #配置nacos服务地址config:file-extension: yaml #文件后缀profiles:active: dev #开发环境这里是dev可以在Usercontroller类中获取一下nacos配置的信息来验证一下 Value(${pattern.dateformat})private String dateformat;GetMapping(/now)public String now(){return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateformat));}6.1.2、配置自动刷新 nacos中的配置文件变更后微服务无需重新启动就可以感知。不过需要通过下面两种配置实现 方式一在Value注入的变量所在类上添加注解RefreshScope 方式二使用ConfigurationProperties注解 这种方式使用的是约束大于配置的配置方法。 Data Component ConfigurationProperties(prefix pattern) public class PatternProperties {private String dateformat; }使用了Spring框架的注解DataComponentConfigurationProperties。这段代码定义了一个名为PatternProperties的类。 ConfigurationProperties注解是Spring框架中用于绑定配置属性的注解。它的prefix属性指定了配置文件中的属性前缀为pattern这意味着在配置文件中所有以pattern开头的属性会被绑定到PatternProperties类的对应属性上。 PatternProperties类中只有一个私有的String类型属性dateformat它对应配置文件中的pattern.dateformat属性。在配置文件中你可以设置这个属性的值例如 patterndateformat: yyyy-MM-dd HH:mm:ss这样当你运行程序时Spring框架会自动将配置文件中的值绑定到PatternProperties类的dateformat属性上你可以通过获取PatternProperties实例的方式来访问并使用这个属性的值。 在类中使用nacos中配置时可以通过以下方式获取 总结 Nacos配置更改后微服务可以实现热更新方式 通过Value注解注入结合RefreshScope来刷新通过ConfigurationProperties注入自动刷新 注意事项: 不是所有的配置都适合放到配置中心维护起来比较麻烦建议将一些关键参数需要运行时调整的参数放到nacos配置中心一般都是自定义配置 7、Nacos集群搭建 7.1、集群结构图 官方给出的Nacos集群图 其中包含3个nacos节点然后一个负载均衡器代理3个Nacos。这里负载均衡器可以使用nginx。 DNSDomain Name System、SLBServer Load Balancer和Nacos可以一起使用来构建一个完整的服务发现和负载均衡的系统。 DNS是用于将域名解析为对应的IP地址的系统。在服务发现和负载均衡中DNS可以被用来解析服务名称为对应的服务实例的IP地址。例如假设有一个服务名为my-service通过将其注册到DNS中可以将my-service解析为具体的服务实例的IP地址。 SLB是一种负载均衡器用于将流量分发到多个后端服务实例上从而实现负载均衡和高可用性。SLB可以接收客户端请求并根据负载均衡算法将请求分发到多个服务实例上。例如当有多个服务实例提供相同的服务时SLB可以根据负载情况将请求分发到负载较低的实例上以实现流量的均衡分布。 Nacos是一个用于服务发现、配置管理和服务治理的开源项目。在服务发现和负载均衡中Nacos作为服务注册中心和配置中心可以用来管理各个服务实例的注册和注销以及维护服务实例的元数据信息。Nacos可以提供给SLB和DNS所需的服务实例信息从而实现服务发现和负载均衡的功能。 结合这三个组件整体的架构可以如下所示 服务实例注册服务实例可以将自己的元数据信息注册到Nacos中包括服务名称、IP地址、端口等信息。 Nacos服务注册中心Nacos注册中心负责存储和管理所有服务实例的元数据信息。 Nacos配置中心Nacos配置中心负责存储和管理应用程序的配置信息。 DNS解析客户端可以通过DNS解析服务名称为具体的服务实例的IP地址。 SLB负载均衡器SLB可以接收客户端请求并根据负载均衡算法将请求分发到多个服务实例上。
  通过这样的结构客户端可以通过DNS解析获取到服务实例的IP地址并通过SLB将请求发送到可用的服务实例上实现负载均衡。同时Nacos作为服务注册中心和配置中心可以管理服务实例的注册和配置信息以确保服务的可用性和配置的一致性。这样的架构既提供了可靠的服务发现和负载均衡也保证了配置的集中管理和动态更新能力。 我们计划的集群结构 三个nacos节点的地址 | 节点   | ip            | port || nacos1 | 192.168.150.1 | 8845 || nacos2 | 192.168.150.1 | 8846 || nacos3 | 192.168.150.1 | 8847 |7.2、集群搭建 搭建集群的基本步骤

• 搭建数据库初始化数据库表结构- 下载nacos安装包- 配置nacos- 启动nacos集群- nginx反向代理六、Feign远程调用 RestTemplate方法调用存在的问题 先看一下我们以前利用RestTemplate发起远程调用的代码 存在下面的问题 代码可读性差编程体验不统一参数复杂URL难维护 1、Feign的介绍 Feign 提供了一种简单且优雅的方式来定义和调用基于HTTP的远程服务。通过使用Feign您可以在客户端代码中定义接口然后Feign会根据这些接口的定义自动生成实际的HTTP请求并将其转发到远程服务。这样您可以像调用本地方法一样调用远程服务的方法无需显式地处理HTTP请求和响应。 Feign 还支持对请求进行编码和解码、错误处理、请求和响应拦截器等功能使得在微服务架构中处理远程服务变得更加方便和高效。 使用Feign的一些优点包括 简化了客户端代码使其更易于维护和理解。减少了手动处理HTTP请求和响应的工作量。支持多种编解码器可处理多种数据格式。可与Spring Cloud等微服务框架无缝集成。 在使用Feign时您需要定义一个Java接口该接口包含与远程服务相对应的方法和参数。然后通过在应用程序的配置中启用Feign并使用Spring的依赖注入功能您可以将Feign客户端注入到您的代码中从而实现对远程服务的调用。 Feign作为一个声明式的HTTP客户端在微服务架构和分布式系统中有许多应用场景。以下是一些常见的使用场景 微服务间的通信在微服务架构中各个服务之间需要频繁地进行通信Feign可以帮助简化服务间的HTTP通信使得调用远程服务更加方便。 服务消费者当一个服务需要调用其他服务提供的API时可以使用Feign来作为客户端来消费这些服务而无需手动处理HTTP请求和响应。 代理远程APIFeign可以将远程服务的API映射为本地接口使得调用远程服务的过程就像调用本地方法一样简单。 负载均衡结合负载均衡的工具如RibbonFeign可以实现在多个服务实例之间进行负载均衡从而提高系统的可用性和性能。 声明式的错误处理Feign支持定义统一的错误处理逻辑使得在发生错误时可以采取一致的处理方式从而减少重复代码。 数据格式处理Feign支持多种编解码器可以处理不同的数据格式例如JSON、XML等使得数据的传输和解析更加灵活和便捷。 请求拦截与日志Feign支持请求和响应拦截器可以在发送请求和接收响应时进行拦截和处理例如记录日志、鉴权等。
  总体而言Feign适用于任何需要在微服务架构中进行HTTP通信的场景特别是当您希望简化远程服务调用的代码并增加可读性和可维护性时Feign是一个非常有用的工具。 2、定义和使用Feign客户端 在之前我是在调用其他服务提供的接口是使用的是RestTempale为什么还要学Feign呢 Feign和RestTemplate都是在Spring框架中用于进行HTTP请求的工具但它们在使用方式和特点上有一些区别。 声明式 vs. 编程式 Feign是一个声明式的HTTP客户端它允许您通过定义接口来描述对远程服务的请求并自动生成底层HTTP调用。Feign使用注解来配置请求的URL、HTTP方法、请求参数等信息使得代码更加简洁和易读。RestTemplate是一个编程式的HTTP客户端您需要在代码中显式地构建HTTP请求包括指定URL、HTTP方法、请求头、请求体等信息。虽然可以通过RestTemplate灵活地控制请求细节但相比Feign代码可能会更冗长和复杂。 整合Spring Cloud vs. 单独使用 Feign是Spring Cloud项目的一部分它与Spring Cloud的其他组件如Eureka、Ribbon、Hystrix等紧密集成使得在微服务架构中使用Feign更加方便并且提供了一些额外的特性如负载均衡、服务发现等。RestTemplate是Spring Framework的一部分它可以单独使用没有与Spring Cloud的深度集成。如果您在非微服务环境中或者不需要Spring Cloud提供的其他功能RestTemplate是一个不错的选择。 自动化的负载均衡 Feign与RibbonSpring Cloud中的负载均衡组件集成可以自动进行负载均衡使得在多个服务实例中选择合适的目标服务。RestTemplate在默认情况下不支持自动的负载均衡您需要手动编写代码来实现负载均衡或者结合Ribbon来实现自动化负载均衡。 请求拦截器和错误处理 Feign允许您定义请求和响应拦截器从而可以在发送请求和接收响应时进行拦截和处理例如记录日志、鉴权等。它还提供了声明式的错误处理机制让您可以统一处理请求错误。RestTemplate也支持请求和响应拦截器但是在处理错误时可能相对繁琐需要通过捕获异常等方式来处理请求错误。 综上所述如果您在使用Spring Cloud和微服务架构特别是在Feign与Ribbon、Eureka等组件进行集成时Feign可能是更好的选择因为它提供了一种简单且声明式的方式来定义和调用远程服务。然而如果您在非微服务环境或不需要Spring Cloud提供的其他功能RestTemplate仍然是一个可行的选择尤其是当您需要更多的灵活性和对HTTP请求的直接控制时。 2.1、Feign实战 定义和使用Feign客户端需要以下步骤 1、添加依赖首先您需要在项目中添加Feign的依赖。如果您是使用Spring Boot项目可以在pom.xml中添加以下依赖 dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-openfeign/artifactId /dependency2、启用Feign客户端为了使Feign客户端生效您需要在Spring Boot应用程序的主类上添加EnableFeignClients注解这将启用Feign客户端的自动配置和发现。 MapperScan(cn.itcast.order.mapper) SpringBootApplication EnableFeignClients public class OrderApplication {public static void main(String[] args) {SpringApplication.run(OrderApplication.class, args);}}3、创建Feign客户端接口接下来您需要定义一个Java接口该接口将包含与远程服务相对应的方法和参数。这些方法的定义类似于普通的Spring组件接口但是您可以使用Spring的注解来定义远程服务的URL、HTTP方法和其他相关信息。 package cn.itcast.order.clients;import cn.itcast.order.pojo.User; import org.springframework.cloud.openfeign.FeignClient; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable;FeignClient(userservice) //使用FeignClient来指导这个接口所有接口方法要访问的服务名称 public interface UserClient {//定义调用接口GetMapping(/user/{id}) User findUserById(PathVariable(id) Long id); }4、使用Feign客户端现在您可以在其他组件或服务中注入Feign客户端并使用它来调用远程服务的方法。 package cn.itcast.order.service;import cn.itcast.order.clients.UserClient; import cn.itcast.order.mapper.OrderMapper; import cn.itcast.order.pojo.Order; import cn.itcast.order.pojo.User; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service;Service public class OrderService {Autowiredprivate OrderMapper orderMapper;Autowiredprivate UserClient userClient; //注入User的Feign客户端public Order queryOrderById(Long id){Order order orderMapper.findById(id);Long userId order.getUserId();//使用Feign远程调用User user userClient.findUserById(userId);order.setUser(user);return order;} }总结 Feign的使用步骤 引入依赖添加EnableFeignClients注解编写FeignClient接口使用FeignClient中定义的方法代替RestTemplate 3、自定义Feign的配置 Feign运行自定义配置来覆盖默认配置可以修改的配置如下 一般我们需要配置的就是日志级别。 日志级别 Feign支持四种不同的日志级别您可以根据需要选择适合的日志级别。这些日志级别用于控制Feign在发送请求和接收响应时记录的日志信息的详细程度。 NONE该日志级别最低不记录任何日志信息。如果您不想在控制台输出任何关于Feign请求和响应的日志可以选择此级别。 BASIC在BASIC级别下Feign仅记录请求方法、URL和响应状态码的基本信息。这对于快速了解请求的基本情况很有帮助但不会记录请求和响应的详细内容。 HEADERS在HEADERS级别下Feign将记录请求和响应的头部信息包括请求头和响应头。这样可以更详细地查看请求和响应的头部信息有助于调试和了解请求的上下文。 FULLFULL级别是最详细的日志级别它会记录请求和响应的所有详细信息包括请求头、请求体、响应头和响应体。如果您需要完整的请求和响应信息来进行详细的调试和排查问题FULL级别是最合适的选择。
  3.1自定义Feign的配置方式 方式一配置文件方式 当使用配置文件的方式来配置Feign的自定义配置时您可以借助Spring Boot的属性配置功能来实现。通过在配置文件如application.properties或application.yml中添加特定的属性您可以自定义Feign的行为。 首先您需要在配置文件中添加Feign的相关属性。以YAML格式的配置文件为例假设您想要配置Feign的日志级别为FULL可以这样写 1、全局生效

  application.yml

  feign:client:config:default: #这里用default就是全局配置如果是写服务器名称则是针对在某个微服务的配置loggerLevel: full #日志级别2、局部生效

  application.yml

  feign:client:config:orderservice: #这里用服务名称则只针对这个服务的配置loggerLevel: full #日志级别方式二java代码方式需要先声明一个Bean: 在使用Feign时您可以通过自定义配置来修改其行为和属性。为了自定义Feign的配置您需要创建一个配置类并在其中添加相关的Bean定义。下面是一个简单的示例来说明如何自定义Feign的配置 package cn.itcast.order.config;import feign.Logger; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration;Configuration public class FeignConfig {Beanpublic Logger.Level feignLogLevel(){return Logger.Level.BASIC;} }全局配置 如果是全局配置则把它放到EnableFeignClients这个注解中 EnableFeignClients(defaultConfiguration FeignConfig.class) 局部配置 如果是局部配置则把它放到FeignClient这个注解中 FeignClient(value userservice,configuration FeignConfig.class)
  总结 Feign的日志配置 1.方式一是配置文件feign.client.config.xxx.loggerLevel O如果xxx是default则代表全局如果xxx是服务名称例如userservice则代表某服务 2.方式二是java代码配置Logger.Level这个Bean 如果在EnableFeignClients注解声明则代表全局如果在FeignClient注解中声明则代表某服务 4、Feign的性能优化 Feign的底层客户端实现是通过集成了其他HTTP客户端库来实现的。具体来说Feign支持两种主要的HTTP客户端实现JDK的URLConnection和Apache HttpClient。 JDK的URLConnection这是Java标准库中提供的用于HTTP通信的API。Feign可以直接使用JDK的URLConnection来发送HTTP请求。它是轻量级的对于简单的HTTP通信可能足够满足需求。如果您在项目中没有引入其他HTTP客户端库Feign会默认使用JDK的URLConnection作为底层的客户端实现。 Apache HttpClientApache HttpClient是Apache基金会提供的一个功能丰富、灵活的HTTP客户端库。它提供了许多高级功能如连接池、重试机制、认证等。如果您在项目中引入了Apache HttpClient的依赖Feign会自动选择使用Apache HttpClient作为底层的客户端实现。 OkHttpOkHttp是Square公司开发的一款高效的HTTP客户端库。它支持HTTP/2、连接池、拦截器等现代特性。如果您在项目中引入了OkHttp的依赖Feign会自动切换到OkHttp作为底层实现。
  Feign的这种设计使得您可以根据需要灵活地选择底层的HTTP客户端。默认情况下如果项目中没有引入其他HTTP客户端库Feign将使用JDK的URLConnection作为底层客户端。如果您希望使用Apache HttpClient或OkHttp只需在项目中添加相应的依赖Feign会自动检测并使用它们作为底层实现。 通过这种方式Feign可以同时满足不同项目对HTTP客户端的需求并提供简便的远程服务调用方式。 因此优化Feign的性能主要包括 使用连接池代替默认的URLConnection日志级别做好使用basic或者none 4.1、 Feign性能优化HttpClient的支持 1、Feign添加HttpClient的支持 引入依赖 dependencygroupIdio.github.openfeign/groupIdartifactIdfeign-httpclient/artifactId/dependency配置连接池 #feign自定义配置配置日志级别 feign:client:config:default: #这里用default就是全局配置如果是写服务器名称则是针对在某个微服务的配置loggerLevel: basic #日志级别httpclient:enabled: true #开启feign对HttpClient的支持max-connections: 200 #最大连接数量max-connections-per-route: 50 #每个路径的最大连接数量总结 Feign的优化 1.日志级别尽量用basic 2.使用HttpClient或OKHttp代替URLConnection 引入feign-httpClient依赖配置文件开启httpClient功能设置连接池参数 5、Feign的最佳实际 方式一继承给消费者的FeignClient和提供者的controller系统定义一个父接口作为标准。 这种实现方式虽然可以让Controller和Feign Client共享同一个接口定义但存在一些问题和注意事项 潜在的耦合共享同一个接口定义会让Controller和Feign Client在代码层面产生耦合导致它们紧密地关联在一起。一旦接口定义发生变化两者都需要进行相应的修改这可能影响到多个模块。 不符合单一职责原则Controller负责处理HTTP请求和返回响应而Feign Client负责远程服务调用。将它们共享同一个接口可能会让代码功能变得混乱违反了单一职责原则。 难以做到完全解耦尽管接口定义可以共享但是在Feign Client的实现中仍然需要涉及到远程服务调用的逻辑。这会让Feign Client的实现和Controller之间仍然有一定的耦合。 接口定义可能会变得复杂为了适应不同的调用场景共享接口可能会变得复杂可能需要添加各种参数和注解从而导致接口的冗长和不易维护。 功能不一致问题在Controller和Feign Client共享同一个接口的情况下两者的功能可能不完全一致。在Controller中可能需要做一些本地逻辑处理而在Feign Client中可能需要进行额外的远程服务调用。
  综上所述虽然共享接口可以在一定程度上减少重复代码但也会引入潜在的问题和复杂性。在实际开发中更常见的做法是将Controller和Feign Client分别定义独立的接口通过接口定义来规范各自的功能和职责。在需要共享方法定义的情况下可以使用Java接口继承来实现方法的复用而避免在Feign Client中直接实现Controller的方法。这样可以更好地保持代码的清晰和可维护性并符合单一职责原则。 方式二抽取将FeignClient抽取为独立模块并且把接口有关的POJO、默认的Feign配置都放到这个模块中提供给所有消费者使用 以前实现  假如我们有order-service、pay-service和user-service两个服务现在order-service和pay-service都要去调用user-service提供的接口我们就得order-service和pay-service服务里都要实现UserClient假如我们不止只有这两个服务调用user-service呢有10个、20个服务都要调用那UserClient就得写10遍、20遍就会重复的开发代码了。 现在 我们独立创建一个项目将哪些重复的代码编写的东西全部放到这个项目/模块中如UserClient、User实体类、DefaultConfig等我们可以把这个项目的内容打成jar包假如以后服务需要的时候直接引用依赖就可以 总结 Feign的最佳实践 让controller和FeignClient继承同一接口将FeignClient、poJo、Feign的默认配置都定义到一个项目中供所有消费者使用 抽取FeignClient 实现最佳实践方式二的步骤如下 1、创建一个module命名为feign-api然后引入feign的starter依赖 引入feign的starter依赖 dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-openfeign/artifactId/dependency2、将order-service中编写的UserClient、User、DefaultFeignConfiguration都复制到feign-api项目中 之前在order-service服务模块中饿这些东西就可以删除了。 3、在order-service中引入feign-api的依赖 !–引入feign的同一api–dependencygroupIdcn.itcast.demo/groupIdartifactIdfeign-api/artifactIdversion1.0/version/dependency这个依赖是我们项目中的feign-api模块里的内容。 4、修改order-service中的所有与上述三个组件有关的import部分改成导入feign-api中的包 5、重启测试 当定义的FeignClient不在springApplication的包扫描范围时这些FeignClient无法使用问题 重启order-service服务后我们会发现报错了 Field userClient in cn.itcast.order.service.OrderService required a bean of type cn.itcast.feign.clients.UserClient that could not be found.该错误信息表明在OrderService类中的userClient字段的类型为cn.itcast.feign.clients.UserClient但是Spring容器中找不到该类型的Bean。说明我们在自动装配UserClient时是找不到这个对象的实例的原因是我们现在在order-service模块中使用的UserClient是通过添加了feign-api依赖而导进来的在order-service模块启动时spring只会对启动类所在目录及这个目录里所有类进行扫描注册到spring容器中的而UserClient所在的包就没有被扫描到所在在order-service这个模块中的spring容器中就找不到了对于的对象实例了。 解决办法方式一指定FeignClient所在包 EnableFeignClients(basePackages cn.itcast.feign.clients) 解决办法方式二指定FeignClient字节码 EnableFeignClients(clients {UserClient.class}) 总结 不同包的FeignClient的导入有两种方式 在EnableFeignClients注解中添加basePackages指定FeignClient所在的包在EnableFeignClients注解中添加clients指定具体FeignClient的字节码 七、Gateway服务网关 网关Gateway服务在微服务架构中起着重要的作用。它是位于客户端和后端微服务之间的中间层用于处理和转发请求。为什么要使用网关服务呢以下是一些主要的原因 统一入口网关服务提供了一个统一的入口客户端只需要向网关发送请求而不需要直接调用各个微服务。这样简化了客户端的调用逻辑同时也方便地对请求进行统一管理和处理。 路由和负载均衡网关服务可以根据请求的URL路径或其他条件将请求路由到相应的微服务实例。它还可以配合负载均衡算法确保请求被均匀地分发给不同的服务实例提高了系统的可用性和性能。 安全控制通过网关服务可以实现对请求进行安全控制和认证。网关可以验证请求的身份、权限以及合法性确保只有授权的请求能够访问相应的微服务。 聚合和分解请求网关服务可以聚合多个微服务的请求将它们合并为一个请求返回给客户端从而减少了客户端与后端服务之间的请求次数降低了网络开销。 缓存网关服务可以对请求的响应进行缓存从而减少重复请求对后端服务的压力提高了系统的性能和响应速度。 降级和容错网关服务可以实现对后端服务的降级和容错处理。当某个微服务出现故障或不可用时网关可以提供默认的响应或调用备用服务避免了系统级的故障。 监控和日志通过网关服务可以实现对请求和响应进行监控和日志记录。这有助于实时追踪请求的流程和性能发现问题并进行及时的处理。
  综上所述网关服务在微服务架构中扮演了一个重要的角色它提供了统一入口、路由和负载均衡、安全控制、聚合和分解请求、缓存、降级和容错、监控和日志等功能为整个系统提供了更高效、更安全、更稳定的请求处理和管理能力。 1、网关技术 在springcloud中网关的实现有两种gateway和zuul Zuul和Spring Cloud Gateway都是常用的网关实现用于在微服务架构中处理和转发请求。它们都可以作为反向代理和请求路由器但在设计和功能上有一些区别。 Zuul Zuul是Netflix提供的网关服务被称为Netflix Zuul。它是一个基于Servlet的网关实现构建在传统的Spring Cloud项目上。Zuul 1.x版本采用阻塞式I/O模型Zuul 2.x版本采用非阻塞式I/O模型基于Netty。 特点 Zuul 1.x的阻塞式I/O模型限制了并发性能虽然可以通过多实例部署来提高吞吐量但对于高并发场景可能不够高效。Zuul 2.x基于非阻塞式I/O模型可以提供更好的性能和吞吐量。Zuul支持动态路由和过滤器等功能可以实现请求的动态转发和预处理。配置方式较为灵活可以使用Groovy或Java DSL配置路由和过滤器。 Spring Cloud Gateway Spring Cloud Gateway是Spring Cloud项目中的网关服务从Spring Cloud 2.x版本开始引入。它是基于Spring 5和Spring Boot 2构建的采用了WebFlux框架支持响应式编程。 特点 Spring Cloud Gateway采用基于异步非阻塞的WebFlux框架提供了更好的性能和响应能力适用于高并发场景。支持动态路由和过滤器等功能可以实现请求的动态转发和预处理。提供了丰富的过滤器支持全局和局部过滤器的定义和使用。配置方式灵活可以使用YAML或Java配置路由和过滤器。 综合来说Zuul和Spring Cloud Gateway都是成熟的网关实现各有优势。如果您在使用Spring Cloud项目推荐使用Spring Cloud Gateway特别是在需要高并发和响应能力的场景下。而如果您在使用Netflix项目可以选择使用Netflix Zuul 2.x版本或更高的版本或考虑迁移到Spring Cloud Gateway。选择哪个网关取决于您的项目需求、技术栈和预期的性能要求。 总结 网关的作用: 对用户请求做身份认证、权限校验将用户请求路由到微服务并实现负载均衡对用户请求做限流 2、搭建网关服务 2.1、搭建网关服务的步骤 创建Gateway项目首先创建一个新的Spring Boot项目作为Gateway服务网关。 添加依赖在Gateway项目中添加Spring Cloud Gateway和Nacos的依赖以便使用Gateway和Nacos的功能。在pom.xml文件中添加以下依赖
  dependencies!– Spring Cloud Gateway –dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-gateway/artifactId/dependency!– Spring Cloud Nacos 作为服务注册和发现中心 –dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId/dependency!– 其他依赖 – /dependencies3、配置网关路由在application.yml中配置网关的路由规则将请求路由到对应的微服务。例如 server:port: 10009 # 配置服务端口spring:application:name: gateway # 服务名称cloud:nacos:server-addr: localhost:8848 # 配置Nacos注册中心的地址和端口gateway:routes:- id: userservice_route # 路由规则的唯一标识用于识别该路由规则。自定义的标识可以方便管理和维护。uri: lb://userservice # 指定目标微服务的服务名。lb://前缀表示使用负载均衡器来选择目标微服务的实例。这里目标微服务的服务名是userservice。predicates: # 断言条件列表用于匹配请求是否符合该路由规则。- Path/user/** # 匹配的URL路径当请求的URL路径以/user/开头时该路由规则会匹配。表示匹配任意后续路径。- id: orderservice_route # 另一个路由规则的唯一标识用于识别该路由规则。uri: lb://orderservice # 指定目标微服务的服务名。这里目标微服务的服务名是orderservice。predicates: # 断言条件列表用于匹配请求是否符合该路由规则。- Path/order/ # 匹配的URL路径当请求的URL路径以/order/开头时该路由规则会匹配。表示匹配任意后续路径。4、启动nacos服务 #Windows系统命令 startup.cmd -m standalone#Linux系统命令 sh startup.sh -m standalone就可以直接使用gateway的ip端口来访问数据了可以直接让gateway来将这些访问地址转发到相应的服务实例上从而来访问数据如访问地址localhost:10009/order/101 2.2、搭建网关服务流程图 客户端发起请求客户端如Web应用、移动端应用、或其他服务发起HTTP请求。 请求到达Gateway请求首先到达Gateway服务网关。 Gateway进行路由匹配Gateway根据预先配置的路由规则匹配请求的URL路径、请求头等信息找到对应的微服务实例。 服务发现Gateway需要通过服务注册中心如Nacos来获取微服务实例的信息。它向Nacos发送服务发现请求Nacos会返回目标微服务的实例列表。 负载均衡Gateway使用负载均衡算法从目标微服务实例列表中选择一个实例将请求转发给该微服务实例。 微服务接收请求目标微服务实例接收到请求。 微服务处理请求微服务实例处理请求并根据业务逻辑执行相应的操作。 微服务返回响应微服务实例生成响应结果并将响应返回给Gateway。 Gateway接收响应Gateway接收到微服务实例的响应。 Gateway处理响应Gateway可以对微服务实例的响应进行处理如添加响应头、日志记录等。 响应返回客户端Gateway将处理后的响应返回给客户端。
  通过服务注册中心如Nacos来进行服务发现Gateway能够动态地获取微服务的实例信息从而实现请求的动态转发和负载均衡。这样Gateway就能找到相应的服务并将请求转发给它们。感谢您的指正希望这次的回答更加准确。 总结 网关搭建步骤 创建项目引入nacos服务发现和gateway依赖 配置application.yml包括服务基本信息、nacos地址、路由
  路由配置包括 路由id:路由的唯一标示路由目标 (uri):路由的目标地址http代表固定地址lb代表根据服务名负载均衡路由断言 (predicates): 判断路由的规则路由过滤器 (filters):对请求或响应做处理 3、路由断言工厂Route Predicate Factory 路由断言工厂Route Predicate Factory是Spring Cloud Gateway中的一种配置方式用于根据请求的条件来进行路由匹配。它可以根据请求的不同属性例如URL路径、请求头、请求方法等来判断请求是否匹配某个路由规则如果匹配成功则将请求转发到相应的目标地址服务实例。例如Path/order/是按照路径匹配这个规则是由org.springframework.cloud.gateway.handler.predicata.PathRoutePredicateFactory类来处理像这种短语工厂在SpringCloudGateway还有十几个 3.1、spring提供了11种基本的Predicate工厂 当使用其他的Predicate工厂时可到spring官网上看如何使用spring route 总结 PredicateFactory的作用是什么? 读取用户定义的断言条件对请求做出判断 Path/user/是什么含义? 路径是以/user开头的就认为是符合的 4、路由过滤器Route Filter 路由过滤器Route Filter是Spring Cloud Gateway中的另一个重要组件它用于在请求被路由到目标服务之前或之后对请求或响应进行一系列的处理操作。通过路由过滤器您可以对请求和响应进行修改、增强或验证从而实现更加灵活和强大的网关功能。 例如 假设我们有一个微服务架构包含多个服务其中一个是认证服务Authentication Service负责处理用户的身份认证。其他服务如用户服务、订单服务等需要保护某些资源只允许经过认证的用户访问。 在这种情况下我们可以使用Spring Cloud Gateway作为网关通过路由过滤器来实现请求认证和授权 全局过滤器Global Filter我们可以创建一个全局过滤器来拦截所有的请求在这个过滤器中进行用户身份认证的检查。比如我们可以检查请求中是否包含有效的身份令牌Token以确定请求是否是经过认证的用户发起的。 局部过滤器Route-Specific Filter对于特定需要授权访问的服务我们可以在路由配置中使用局部过滤器。在这个过滤器中我们可以对请求进行权限验证检查用户是否有权限访问该服务提供的资源。如果用户没有合法的权限则可以拒绝请求或返回相应的错误信息。
  这样通过路由过滤器我们可以实现全局的请求认证并对需要授权访问的服务进行权限控制。用户在发起请求时首先经过全局过滤器进行认证然后再经过局部过滤器进行权限验证。只有通过认证和授权的请求才能继续访问后端的微服务。 这种方式使得认证和授权逻辑从业务服务中剥离出来统一交给网关进行处理简化了业务服务的实现和管理同时提高了系统的安全性和可维护性。 4.1、过滤工厂 GratewayFilterFactory 在Spring Cloud Gateway中过滤工厂Filter Factory是用于创建过滤器的工厂类它用于生成过滤器实例并配置过滤器的行为。过滤工厂是一种更高级别的抽象它将过滤器的创建和配置过程封装在一起使得配置网关过滤器更加简单和灵活。 过滤工厂与过滤器的区别在于 过滤器是过滤器实际的执行逻辑它需要开发者自己实现并继承特定的Filter接口如GlobalFilter或GatewayFilter完成请求和响应的处理。过滤工厂是用于创建过滤器的工厂类它将过滤器的创建和配置封装起来通过配置工厂的参数可以快速创建不同类型的过滤器并指定过滤器的行为。 过滤工厂的优势在于它提供了一些预定义的工厂可以轻松地为常见的过滤器场景创建过滤器而无需开发者自己编写过滤器的实现。通过简单的配置开发者可以使用这些预定义的过滤工厂创建自定义的过滤器从而实现特定的路由和请求处理逻辑。 spring提供了31种不同的路由过滤器工厂一些常用的过滤工厂包括 通过使用过滤工厂您可以在网关中快速配置和管理过滤器实现对请求和响应的灵活处理。过滤工厂是Spring Cloud Gateway提供的一种高级配置方式帮助开发者更加方便地定制和扩展网关的功能。 如果想使用其他的可以到过往进行学习spring GatewayFilterFactory 4.1.1、案例 给所有进入userservice的请求添加一个请求头 默认过滤器 总结 过滤器的作用是什么? 对路由的请求或响应做加工处理比如添加请求头 配置在路由下的过滤器只对当前路由的请求生效 defaultFilters的作用是什么? 对所有路由都生效的过滤器 5、全局过滤器 GlobalFilter 全局过滤器Global Filter我们可以创建一个全局过滤器来拦截所有的请求在这个过滤器中进行用户身份认证的检查。比如我们可以检查请求中是否包含有效的身份令牌Token以确定请求是否是经过认证的用户发起的。 全局过滤器的作用也是处理一切进入网关的请求和微服务响应与GatewayFilter的作用一样。区别在于GatewayFilter通过配置定义处理逻辑是固定的。而GlobalFilter的逻辑需要自己写代码实现。定义方式是实现GlobalFilter接口。 5.1、实现步骤 自定义来实现GlobalFilter接口添加Order注解 import org.springframework.cloud.gateway.filter.GlobalFilter; import org.springframework.core.Ordered; import org.springframework.http.HttpStatus; import org.springframework.stereotype.Component; import org.springframework.util.MultiValueMap; import org.springframework.web.server.ServerWebExchange; import reactor.core.publisher.Mono;/* 自定义全局过滤器用于校验请求中的authorization参数是否合法/ Component Order(-1) public class AuthorizeFilter implements GlobalFilter {/** 过滤器方法用于校验请求中的authorization参数是否合法* param exchange 服务器WebExchange对象包含请求和响应信息* param chain GatewayFilterChain对象用于传递请求给下一个过滤器或路由处理器* return MonoVoid表示请求的处理结果*/Overridepublic MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) {// 获取请求参数MultiValueMapString, String params exchange.getRequest().getQueryParams();// 获取authorization参数String authorization params.getFirst(authorization);// 校验authorization参数if (ltc.equals(authorization)) {// 授权通过请求继续传递给下一个过滤器或路由处理器return chain.filter(exchange);} else {// 授权不通过设置响应状态码为403禁止访问并结束处理返回禁止访问的响应exchange.getResponse().setStatusCode(HttpStatus.FORBIDDEN);return exchange.getResponse().setComplete();}} }总结 全局过滤器的作用是什么? 对所有路由都生效的过滤器并且可以自定义处理逻辑 实现全局过滤器的步骤? 实现GlobalFilter接口添加Order注解或实现Ordered接口编写处理逻辑 6、过滤器执行顺序 请求进入网关会碰到三类过滤器: 当前路由的过滤器、DefaultFilter、GlobalFilter 请求路由后会将当前路由过滤器和DefaultFilter、GlobalFilter合并到一个过滤器链(集合)中排序后依次执行每个过滤器。 这是我们就会想这三个过滤器相同吗怎么就可以放在同一个集合中进行排序了别着急。 对于当前路由过滤器和DefaultFilter的配置方法是非常相似的区别就是当前路由过滤器放在路由内而DefaultFilter是放在默认的过滤器内的。从java的底层来看他两个本质是一样的只是作用范围不一样而已。 在配置文件中配置的当前路由过滤器和DefaultFilter默认过滤器都是由AddRequestHeaderGatewayFilterFactory过滤器工厂来读取然后生成了GatewayFilter过滤器所以这两个过滤器本质都是同一类他们两个都叫GatewayFilter过滤器。 但是GlobalFilter全局过滤器为什么又可以和GatewayFilter来进行配置执行呢 在网关中有一个适配器GatewayFilterAdapter他就可以将GlobalFilter适配成GatewayFilter来用。 GatewayFilterAdapter适配器这个类就实现了GatewayFilter接口他内部还接收了GlobalFilter全局过滤器如果我们给他传入一个GlobalFilter全局过滤器他就会将GlobalFilter适配成GatewayFilter来用。所以在网关中所有的过滤器都会被适配成Gateway来使用所以这些过滤器就可以放到一个集合中来进行排序了。 这时就会出现一个新的问题了那放到了一个集合后有怎么进行排序呢 6.1、过滤器执如何排序 每个过滤器都必须指定一个int类型的order值order值越小优先级越高执行顺序越靠前。GlobalFilter通过实现Order接口或者添加Order注解来指定order值由我们自己指定。路由过滤器和defaultFilter的order由Spring指定默认是按照声明顺序从1递增。 多余多个路由过滤器 和多个默认路由器 如果有多个路由过滤器那他们是按照声明的顺序来递增order的值的来排序他们的执行顺序。多个默认路由也是如此的也是按声明的顺序来递增order的值来排序他们的执行顺序。 但是当默认过滤器、路由过滤器和GlobalFilter全局过滤器的order值相同呢那又该怎么办呢 当过滤器的order值一样时会按照defaultFilter 路由过滤器 GlobalFilter全局过滤器的顺序执行。 底层源码中有两个类是用来加载这三种过滤器的 当服务启动后RouteDefinitionRouteLocator类的getFilter()方法会首先执行会先去配置文件中加载defaultFilters,然后才会去加载某个路由的route的filter然后合并。  当getFilter()方法执行完后FilteringWebHandler类的handle()方法才会进行加载全局过滤器加载后会与之前加载的过滤器合并后更具order排序组织过过滤器链 总结 路由过滤器、defaultFilter、全局过滤器的执行顺序? order值越小优先级越高当order值一样时顺序是defaultFilter最先然后是局部的路由过滤器最后是全局过滤器 7、跨域问题处理 7.1、跨越问题 跨域问题Cross-Origin Issue是由浏览器的同源策略引起的。同源策略是一种安全机制限制了网页文档或脚本从一个源协议、域名、端口号的组合加载或操作另一个源的内容。如果两个网页的协议、域名和端口号都相同它们就是同源的否则就被认为是跨域的。 跨域:域名不一致就是跨域主要包括: 域名不同:www.taobao.com和 www.taobao.org 和 wwwjd.com 和 miaoshajd.com域名相同端口不同: localhost:8080和localhost8081 跨越问题浏览器禁止请求的发起者和服务端发生跨域Ajax请求请求被浏览器拦截的问题。 跨域问题的出现是为了防止恶意网站利用客户端的漏洞进行攻击保护用户的隐私和安全。浏览器会强制执行同源策略禁止网页在不同源之间进行以下操作 通过 XMLHttpRequest 或 Fetch API 发送跨域请求。访问其他源的 Cookie、LocalStorage 和 IndexedDB。获取其他源的 DOM 元素。在其他源的窗口中执行脚本。 举个例子来说明跨域问题假设网站A的域名是 https://www.example.com网站B的域名是 https://api.example.com。如果网站A的网页中使用 XMLHttpRequest 或 Fetch API 向网站B发送请求那么由于它们不是同源的浏览器会阻止这个请求返回一个错误。这就是跨域问题。 7.2、跨越问题解决办法 CORS 只需要在application.yml文件中添加下面的配置即可。 spring:cloud:gateway:globalcors:corsConfigurations:[/]: # 配置所有路径的全局CORS设置allowedOrigins: https://example.com # 允许的跨域请求源这里设置为https://example.comallowedMethods: GET, POST, PUT, DELETE # 允许的请求方法这里设置为GET、POST、PUT、DELETEallowedHeaders: * # 允许的请求头这里设置为*表示允许任意请求头allowCredentials: true # 是否允许发送凭证信息如Cookie这里设置为true表示允许发送凭证信息maxAge: 3600 # 预检请求的缓存时间单位秒这里设置为3600秒add-to-simple-url-handler-mapping: true #处理option请求被拦截问题配置详细介绍 corsConfigurations: 这个属性用于配置全局的CORS设置。[/] 表示匹配所有路径也就是对所有请求生效的全局CORS配置。 allowedOrigins: 允许的跨域请求源。这里设置为 https://example.com表示只允许来自 https://example.com 域名的请求进行跨域访问。你可以根据实际需求设置允许的域名也可以使用通配符 * 表示允许所有域名的请求。 allowedMethods: 允许的请求方法。这里设置为 GET, POST, PUT, DELETE表示只允许这些HTTP方法的请求进行跨域访问。你可以根据需要添加或删除允许的方法。 allowedHeaders: 允许的请求头。这里设置为 *表示允许任意请求头。你也可以设置具体的请求头名称比如 Content-Type, Authorization只允许这些请求头进行跨域访问。 allowCredentials: 是否允许发送凭证信息如Cookie。这里设置为 true表示允许发送凭证信息。如果设置为 false则不允许发送凭证信息。 maxAge: 预检请求的缓存时间单位秒。预检请求是指浏览器在发送跨域请求前先发送一个 OPTIONS 请求来检查服务器是否允许跨域访问。这里设置为 3600 秒表示预检请求的结果在 3600 秒内可以被缓存减少预检请求的次数。 add-to-simple-url-handler-mapping: 这个属性设置为 true将CORS配置添加到简单URL处理程序映射中。这是一个内部属性通常不需要手动设置。
  通过以上配置Spring Cloud Gateway 将会在响应中添加相应的CORS响应头允许来自 https://example.com 域名的跨域请求允许的方法有 GET、POST、PUT、DELETE允许任意请求头允许发送凭证信息如 Cookie并且预检请求的缓存时间为 3600 秒。 总结 ·CORS跨域要配置的参数包括哪几个? 允许哪些域名跨域?允许哪些请求头?允许哪些请求方式?是否允许使用cookie?有效期是多久? 此篇是在学习黑马课springcloud程是做的详细的笔记内容是自己总结过后易懂但是就是篇幅有点多需要大家多花时间去看。 ——————— 作者m0_62498006 来源CSDN 原文https://blog.csdn.net/m0_62498006/article/details/131927338 版权声明本文为作者原创文章转载请附上博文链接 内容解析ByCSDN,CNBLOG博客文章一键转载插件