springcloud相关组件介绍

Nacos

一个更易于构建云原生应用的动态服务发现(NacosDiscovery)、服务配置(NacosConfig)和服务管理平台。

核心功能:

服务注册:NacosClient会通过发送REST请求的方式向NacosServer注册自己的服务,提供自身的元数据,比如ip地址、端口等信息。NacosServer接收到注册请求后,就会把这些元数据信息存储在一个双层的内存Map中。

服务心跳:在服务注册后,NacosClient会维护一个定时心跳来持续通知NacosServer,说明服务一直处于可用状态,防止被剔除。默认5s发送一次心跳。

服务同步:NacosServer集群之间会互相同步服务实例,用来保证服务信息的一致性。leader raft

服务发现:服务消费者(NacosClient)在调用服务提供者的服务时,会发送一个REST请求给NacosServer,获取上面注册的服务清单,并且缓存在NacosClient本地,同时会在NacosClient本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存

服务健康检查:NacosServer会开启一个定时任务用来检查注册服务实例的健康情况,对于超过15s没有收到客户端心跳的实例会将它的healthy属性置为false(客户端服务发现时不会发现),如果某个实例超过30秒没有收到心跳,直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)

Ribbon

目前主流的负载方案分为以下两种:

       1. 集中式负载均衡,在消费者和服务提供方中间使用独立的代理方式进行负载,有硬件的(比如F5),也有软件的(比如Nginx)。

通过Nginx进行负载均衡,先发送请求,然后通过负载均衡算法,在多个服务器之间选择一个进行访问;即在服务器端再进行负载均衡算法分配。

 

        2.客户端根据自己的请求情况做负载均衡,Ribbon就属于客户端自己做负载均衡。

客户端会有一个服务器地址列表,在发送请求前通过负载均衡算法选择一个服务器,然后进行访问,这是客户端负载均衡;即在客户端就进行负载均衡算法分配。

3.常见负载均衡算法

        1.随机,通过随机选择服务进行执行,一般这种方式使用比较少。

        2.轮询,负载均衡默认实现方式,请求来以后排队处理。

        3.加权轮询,通过服务器性能的分型,给高配置,低负载的服务器分配更好的权重,均衡各个服务器的压力。

        4.地址hash,通过客户端请求的地址的hash值取模映射进行服务器调度。

        5.最小链接数,及时请求均衡了,压力也不一定均衡,最小链接数法就是根据服务器的情况,比如请求基数等参数,将请求分配到当前压力最小的服务器上。

4.Ribbon负载均衡策略

IRule

所有负载均衡策略的父接口,里面的核心是choose方法,用来选择一个服务实例。

AbstractLoadBalancerRule

是一个抽象类,主要定义了一个ILoadBalancer,这里定义他的目的主要是 辅助负责负责均衡策略选取合适的服务端实例。

        1.RandomRule:随机选择一个服务实例。

        2.RoundRobbinRule:线性轮询负载均衡策略。

        3.RetryRule:在轮询的基础上进行重试,每次还是使用RoundRobbinRule中的choose规则来选择一个服务实例,如果选到的实例正常就返回,如果选择的服务实例为null或者已经失效,则在失效时间deadline之前不断的进行重试(重试时获取服务的策略还是RoundRobbinRule中定义的策略),如果超过deadline还是没取到则会返回一个null。

        4.WeigthedResponseTimeRule:权重,WeightedResponseTimeRule中会根据每一个实例的运行情况来给计算出该实例的一个权重,然后在挑选实例的时候则根据权重进行挑选,这样能够实现更优的实例调用。WeightedResponseTimeRule中有一个名叫DynamicServerWeightTask的定时任务,默认情况下每隔30秒会计算一次各个服务实例的权重,权重的计算规则也很简单,如果一个服务的平均响应时间越短则权重越大,那么该服务实例被选中执行任务的概率也就越大。

        5.BestAvailableRule:根据loadBalancerStatus中保存的服务实例的状态信息来过滤掉失效的服务实例,然后顺便找出并发请求最小的服务实例使用。

        6.ZoneAvoidanceRule:默认规则 复合判断 服务器性能和可用性选择服务器

Feign

Feign是Netflix开发的声明式,模板化的HTTP客户端,可帮助我们更加便捷、优雅的调用HTTP API。

SpringCloudopenfeign对Feign进行了增强,使其支持SpringMVC注解,另外还整合了Ribbon和Nacos,从而使得Feign的使用更加方便。

优势: Feign可以做到使用HTTP请求远程服务时就像调用本地方法一样的体验,开发者完全感知不到这是远程方法,更感知不到这是个HTTP请求。它像Dubbo一样,consumer直接调用接口方法调用provider,而不需要通过常规的HttpClient构造请求再解析返回数据。它解决了让开发者调用远程接口就跟调用本地方法一样,无需关注与远程的交互细节,更无需关注分布式环境开发。

服务容错-resilience4j

 服务容错和雪崩效应-

服务容错的五种方案:

1.超时

2.限流(RateLimiter)

3.仓壁模式(@Bulkhead)

仓壁模式

        1.基于Semaphore

2.基于ThreadPool(效率低于Reference 因为会引起线程上下文切换的开销)

4.断路器(CircuitBreaker)

5.重试(Retry)

配置管理

1.配置"可视化"API: RateLimiterRegistry

同理 BulkheadRegistry、CircuitBreakerRegistry、RetryRegistry

可获得当前应用所有限流器的详情信息。

2.默认配置

对于RateLimiter,当且仅当指定名称的RateLimiter 没有任何自定义配置时,名为default 的配置才有效。

3.配置引用

4.配置刷新

利用consul或nacos

配置组合使用与执行顺序 

默认顺序 : ordered 越小,越先执行。

自定义顺序配置

消息驱动的微服务

基于MQ的通信流程

MQ使用场景(合理使用可提升用户体验,提升系统吞吐量)

1.异步处理

2.流量削峰填谷-(常用于秒杀)

3.解耦

使用spring Cloud Stream 实现RabbitMQ

spring Cloud Stream是什么?

一个用于构建消息驱动的微服务的框架

核心组件:

Binder 

Binder 是Spring Cloud Steram的一个重要的抽象,目前Spring Cloud Stream实现了面向Kafka和RabbitMQ的Binder。有了Binder有很方便的连接中间件了。Binder提供了消费者分组和消息分区的特性。

Channel

 即通道,是队列Queue的一种抽象,在具体的消息通讯系统中,队列作用就是实现存储和转发的媒介,我们通过Channel对队列进行配置。

Source和Sink

        我们不是第一次看到Source和Sink了,简单的可理解为输入和输出。注意:这里的参照对象是Spring Cloud Stream自身,从Stream发布消息就是输出,接受消息就是输入。

 在Spring Cloud Stream中,Source组件是使用一个POJO对象发布消息的,该对象需要序列化然后发布到Channel中,Sink反序列化POJO对象。在底层的处理机制上,需要借助Spring Integration这个企业服务总线的组件。

网关GateWay

底层是Netty(网络通信框架)、Reactor(reactive)、 WebFlux(reactive web框架)

优点:

性能强劲 是Zuul的1.6倍

功能强大:内置了很多实用功能-如转发、监控、限流等

设计优雅,易扩展

缺点:

核心概念

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值