如何查询一个网站所属的主机,wordpress有哪些网站吗,com域名注册情况,南京华夏天成建设有限公司网站这目录 1.Ribbon负载均衡1负载均衡原理2.负载均衡策略1.负载均衡策略2.自定义负载均衡策略 3.饥饿加载 2.Nacos注册中心与Eureka的区别3.Nacos配置中心1.从微服务拉取配置2.配置热更新1.2.1.方式一1.2.2.方式二 3.配置共享1.配置共享的优先级 4.Feign1.Feign使用优化2.配置连接… 这目录 1.Ribbon负载均衡1负载均衡原理2.负载均衡策略1.负载均衡策略2.自定义负载均衡策略 3.饥饿加载 2.Nacos注册中心与Eureka的区别3.Nacos配置中心1.从微服务拉取配置2.配置热更新1.2.1.方式一1.2.2.方式二 3.配置共享1.配置共享的优先级 4.Feign1.Feign使用优化2.配置连接池参数 5.Gateway服务网关1.网关的**核心功能特性**2.过滤器执行顺序 6.Docker7.RabbitMQ1.RabbitMQ介绍1.同步调用2.异步调用3.几种常见MQ的对比4.RabbitMQ中的一些角色 2.RabbitMQ 5个消息模型a.SpringAMQP1.Basic Queue 简单队列模型2.WorkQueue3.4.5发布/订阅的三个模型3.Fanout广播4.Direct路由定向5.Topic话题通配符 1.Ribbon负载均衡
配置Nacos或者Eureka是我们添加了LoadBalanced注解即可实现负载均衡功能这是什么原理呢
1负载均衡原理
SpringCloud底层其实是利用了一个名为Ribbon的组件来实现负载均衡功能的。
那么我们发出的请求明明是http://userservice/user/1怎么变成了http://localhost:8081的呢
SpringCloudRibbon的底层采用了一个拦截器拦截了RestTemplate发出的请求对地址做了修改。用一幅图来总结一下 基本流程如下
拦截我们的RestTemplate请求http://userservice/user/1RibbonLoadBalancerClient会从请求url中获取服务名称也就是user-serviceDynamicServerListLoadBalancer根据user-service到eureka拉取服务列表eureka返回列表localhost:8081、localhost:8082IRule利用内置负载均衡规则从列表中选择一个例如localhost:8081RibbonLoadBalancerClient修改请求地址用localhost:8081替代userservice得到http://localhost:8081/user/1发起真实请求
2.负载均衡策略
1.负载均衡策略
负载均衡的规则都定义在IRule接口中而IRule有很多不同的实现类 不同规则的含义如下
内置负载均衡规则类规则描述RoundRobinRule简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。AvailabilityFilteringRule对以下两种服务器进行忽略 1在默认情况下这台服务器如果3次连接失败这台服务器就会被设置为“短路”状态。短路状态将持续30秒如果再次连接失败短路的持续时间就会几何级地增加。 2并发数过高的服务器。如果一个服务器的并发连接数过高配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限可以由客户端的..ActiveConnectionsLimit属性进行配置。WeightedResponseTimeRule为每一个服务器赋予一个权重值。服务器响应时间越长这个服务器的权重就越小。这个规则会随机选择服务器这个权重值会影响服务器的选择。ZoneAvoidanceRule以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。BestAvailableRule忽略那些短路的服务器并选择并发数较低的服务器。RandomRule随机选择一个可用的服务器。RetryRule重试机制的选择逻辑
默认的实现就是ZoneAvoidanceRule是一种轮询方案
2.自定义负载均衡策略
通过定义IRule实现可以修改负载均衡规则有两种方式
代码方式在order-service中的OrderApplication类中定义一个新的IRule
Bean
public IRule randomRule(){return new RandomRule();
}配置文件方式在order-service的application.yml文件中添加新的配置也可以修改规则
userservice: # 给某个微服务配置负载均衡规则这里是userservice服务ribbon:NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则 注意一般用默认的负载均衡规则不做修改。 3.饥饿加载
Ribbon默认是采用懒加载即第一次访问时才会去创建LoadBalanceClient请求时间会很长。
而饥饿加载则会在项目启动时创建降低第一次访问的耗时通过下面配置开启饥饿加载
ribbon:eager-load:enabled: trueclients: userservice2.Nacos注册中心与Eureka的区别
Nacos的服务实例分为两种l类型 临时实例如果实例宕机超过一定时间会从服务列表剔除默认的类型。 非临时实例如果实例宕机不会从服务列表剔除也可以叫永久实例。
配置一个服务实例为永久实例
spring:cloud:nacos:discovery:ephemeral: false # 设置为非临时实例Nacos和Eureka整体结构类似服务注册、服务拉取、心跳等待但是也存在一些差异 Nacos与eureka的共同点 都支持服务注册和服务拉取都支持服务提供者心跳方式做健康检测 Nacos与Eureka的区别 Nacos支持服务端主动检测提供者状态临时实例采用心跳模式非临时实例采用主动检测模式临时实例心跳不正常会被剔除非临时实例则不会被剔除Nacos支持服务列表变更的消息推送模式服务列表更新更及时Nacos集群默认采用AP方式当集群中存在非临时实例时采用CP模式Eureka采用AP方式
3.Nacos配置中心
注意项目的核心配置需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。
1.从微服务拉取配置
微服务要拉取nacos中管理的配置并且与本地的application.yml配置合并才能完成项目启动。
但如果尚未读取application.yml又如何得知nacos地址呢
因此spring引入了一种新的配置文件bootstrap.yaml文件会在application.yml之前被读取流程如下 1引入nacos-config依赖
2添加bootstrap.yaml
然后在user-service中添加一个bootstrap.yaml文件内容如下
spring:application:name: userservice # 服务名称profiles:active: dev #开发环境这里是dev cloud:nacos:server-addr: localhost:8848 # Nacos地址config:file-extension: yaml # 文件后缀名这里会根据spring.cloud.nacos.server-addr获取nacos地址再根据
${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}作为文件id来读取配置。
本例中就是去读取userservice-dev.yaml 2.配置热更新
我们最终的目的是修改nacos中的配置后微服务中无需重启即可让配置生效也就是配置热更新。
要实现配置热更新可以使用两种方式
1.2.1.方式一
在Value注入的变量所在类上添加注解RefreshScope
1.2.2.方式二
使用ConfigurationProperties注解代替Value注解。
在user-service服务中添加一个类读取patterrn.dateformat属性
3.配置共享
其实微服务启动时会去nacos读取多个配置文件例如 [spring.application.name]-[spring.profiles.active].yaml例如userservice-dev.yaml [spring.application.name].yaml例如userservice.yaml
而[spring.application.name].yaml不包含环境因此可以被多个环境共享。
1.配置共享的优先级
当nacos、服务本地同时出现相同属性时优先级有高低之分 4.Feign
Feign客户端也集成了Ribbon负载均衡
1.Feign使用优化
Feign底层发起http请求依赖于其它的框架。其底层客户端实现包括 URLConnection默认实现不支持连接池 Apache HttpClient 支持连接池 OKHttp支持连接池
因此提高Feign的性能主要手段就是使用连接池代替默认的URLConnection。
2.配置连接池参数
在order-service的application.yml中添加配置
feign:client:config:default: # default全局的配置loggerLevel: BASIC # 日志级别BASIC就是基本的请求和响应信息httpclient:enabled: true # 开启feign对HttpClient的支持max-connections: 200 # 最大的连接数max-connections-per-route: 50 # 每个路径的最大连接数5.Gateway服务网关
1.网关的核心功能特性
身份验证权限控制服务路由负载均衡请求限流
权限控制网关作为微服务入口需要校验用户是是否有请求资格如果没有则进行拦截。
路由和负载均衡一切请求都必须先经过gateway但网关不处理业务而是根据某种规则把请求转发到某个微服务这个过程叫做路由。当然路由的目标服务有多个时还需要做负载均衡。
限流当请求流量过高时在网关中按照下流的微服务能够接受的速度来放行请求避免服务压力过大。 网关搭建步骤 创建项目引入nacos服务发现和gateway依赖 配置application.yml包括服务基本信息、nacos地址、路由
路由配置包括
路由id路由的唯一标示路由目标uri路由的目标地址http代表固定地址lb代表根据服务名负载均衡路由断言predicates判断路由的规则路由过滤器filters对请求或响应做处理
2.过滤器执行顺序
请求进入网关会碰到三类过滤器当前路由的过滤器、DefaultFilter、GlobalFilter
请求路由后会将当前路由过滤器和DefaultFilter、GlobalFilter合并到一个过滤器链集合中排序后依次执行每个过滤器 排序的规则是什么呢
每一个过滤器都必须指定一个int类型的order值order值越小优先级越高执行顺序越靠前。GlobalFilter通过实现Ordered接口或者添加Order注解来指定order值由我们自己指定路由过滤器和defaultFilter的order由Spring指定默认是按照声明顺序从1递增。当过滤器的order值一样时会按照 defaultFilter 路由过滤器 GlobalFilter的顺序执行。
6.Docker
过
7.RabbitMQ
1.RabbitMQ介绍
1.同步调用
同步调用的优点
时效性较强可以立即得到结果
同步调用的问题
耦合度高性能和吞吐能力下降有额外的资源消耗有级联失败问题
2.异步调用
好处 吞吐量提升无需等待订阅者处理完成响应更快速 故障隔离服务没有直接调用不存在级联失败问题 调用间没有阻塞不会造成无效的资源占用 耦合度极低每个服务都可以灵活插拔可替换 流量削峰不管发布事件的流量波动多大都由Broker接收订阅者可以按照自己的速度去处理事件
缺点
架构复杂了业务没有明显的流程线不好管理需要依赖于Broker的可靠、安全、性能
3.几种常见MQ的对比
RabbitMQActiveMQRocketMQKafka公司/社区RabbitApache阿里Apache开发语言ErlangJavaJavaScalaJava协议支持AMQPXMPPSMTPSTOMPOpenWire,STOMPREST,XMPP,AMQP自定义协议自定义协议可用性高一般高高单机吞吐量一般差高非常高消息延迟微秒级毫秒级毫秒级毫秒以内消息可靠性高一般高一般
追求可用性Kafka、 RocketMQ 、RabbitMQ
追求可靠性RabbitMQ、RocketMQ
追求吞吐能力RocketMQ、Kafka
追求消息低延迟RabbitMQ、Kafka
4.RabbitMQ中的一些角色
publisher生产者consumer消费者exchange个交换机负责消息路由queue队列存储消息virtualHost虚拟主机隔离不同租户的exchange、queue、消息的隔离
2.RabbitMQ 5个消息模型
RabbitMQ官方提供了5个不同的Demo示例对应了不同的消息模型 a.SpringAMQP
SpringAMQP是基于RabbitMQ封装的一套模板并且还利用SpringBoot对其实现了自动装配使用起来非常方便。
SpringAMQP提供了三个功能
自动声明队列、交换机及其绑定关系基于注解的监听器模式异步接收消息封装了RabbitTemplate工具用于发送消息
1.Basic Queue 简单队列模型
2.WorkQueue
Work queues也被称为Task queues任务模型。简单来说就是让多个消费者绑定到一个队列共同消费队列中的消息。 当消息处理比较耗时的时候可能生产消息的速度会远远大于消息的消费速度。长此以往消息就会堆积越来越多无法及时处理。
此时就可以使用work 模型多个消费者共同处理消息处理速度就能大大提高了。
Work模型的使用
多个消费者绑定到一个队列同一条消息只会被一个消费者处理通过设置prefetch消息预取来控制消费者预取的消息数量
3.4.5发布/订阅的三个模型
发布订阅的模型如图 可以看到在订阅模型中多了一个exchange角色而且过程略有变化
Publisher生产者也就是要发送消息的程序但是不再发送到队列中而是发给X交换机Exchange交换机图中的X。一方面接收生产者发送的消息。另一方面知道如何处理消息例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作取决于Exchange的类型。Exchange有以下3种类型 Fanout广播将消息交给所有绑定到交换机的队列Direct定向把消息交给符合指定routing key 的队列Topic通配符把消息交给符合routing pattern路由模式 的队列 Consumer消费者与以前一样订阅队列没有变化Queue消息队列也与以前一样接收消息、缓存消息。
Exchange交换机只负责转发消息不具备存储消息的能力因此如果没有任何队列与Exchange绑定或者没有符合路由规则的队列那么消息会丢失
3.Fanout广播
Fanout英文翻译是扇出我觉得在MQ中叫广播更合适。 在广播模式下消息发送流程是这样的
1 可以有多个队列2 每个队列都要绑定到Exchange交换机3 生产者发送的消息只能发送到交换机交换机来决定要发给哪个队列生产者无法决定4 交换机把消息发送给绑定过的所有队列5 订阅队列的消费者都能拿到消息
交换机的作用是什么
接收publisher发送的消息将消息按照规则路由到与之绑定的队列不能缓存消息路由失败消息丢失FanoutExchange的会将消息路由到每个绑定的队列
声明队列、交换机、绑定关系的Bean是什么
QueueFanoutExchangeBinding
4.Direct路由定向
在Fanout模式中一条消息会被所有订阅的队列都消费。但是在某些场景下我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange。 在Direct模型下
队列与交换机的绑定不能是任意绑定了而是要指定一个RoutingKey路由key消息的发送方在 向 Exchange发送消息时也必须指定消息的 RoutingKey。Exchange不再把消息交给每一个绑定的队列而是根据消息的Routing Key进行判断只有队列的Routingkey与消息的 Routing key完全一致才会接收到消息
描述下Direct交换机与Fanout交换机的差异
Fanout交换机将消息路由给每一个与之绑定的队列Direct交换机根据RoutingKey判断路由给哪个队列如果多个队列具有相同的RoutingKey则与Fanout功能类似
基于RabbitListener注解声明队列和交换机有哪些常见注解
QueueExchange
5.Topic话题通配符
Topic类型的Exchange与Direct相比都是可以根据RoutingKey把消息路由到不同的队列。只不过Topic类型Exchange可以让队列在绑定Routing key 的时候使用通配符
Routingkey 一般都是有一个或多个单词组成多个单词之间以”.”分割例如 item.insert
通配符规则
#匹配一个或多个词
*匹配不多不少恰好1个词
举例
item.#能够匹配item.spu.insert 或者 item.spu
item.*只能匹配item.spu
图示 解释
Queue1绑定的是china.# 因此凡是以 china.开头的routing key 都会被匹配到。包括china.news和china.weatherQueue2绑定的是#.news 因此凡是以 .news结尾的 routing key 都会被匹配。包括china.news和japan.news
描述下Direct交换机与Topic交换机的差异
Topic交换机接收的消息RoutingKey必须是多个单词以 **.** 分割Topic交换机与队列绑定时的bindingKey可以指定通配符#代表0个或多个词*代表1个词
