文章目录
1. Spring Cloud之Eureka
- 作用:将应用根据不同的功能划分成不同的服务,方便维护和复用,但是服务如何找到需要的服务地址较为麻烦,在配置文件中写死,硬编码并不可取。该组件的功能就是提供一个服务的注册和发现的功能。特点:高可用,由以下几点保证,1.客户端会缓存服务的注册表信息,2.服务端会向客户端发起心跳,确认是否断开,3.可以存在多个服务端,他们之间的数据可以相互同步。
- 实现:
- 创建Eureka Server(注册中心)
- 创建Maven工程
- 引入Cloud的依赖,加入eureka-server的包
- 编写启动类
- application.yml配置文件中进行配置
- 启动
- 创建Eureka Client
- 创建Maven工程
- 引入Cloud的依赖,加入eureka-server的包
- 编写启动类,启动类上加入@EnableDiscoveryClient注解
- application.yml配置文件中进行配置服务端的地址,从而注册
- 注入DiscoveryClient,并通过服务ID获取服务实例,从而获取IP和端口
- 启动
- 创建Eureka Server(注册中心)
- 原理:客户端将服务的信息注册到注册中心,Eureka Server会将这些信息存储在自己的注册表中,当有其他的Eureka Server注册时,注册表中的内容会进行同步,并且Eureka Server会定时对客户端发起心跳,确保客户端可用的状态。客户端也会缓存一份服务端的注册表,即使注册中心和客户端间出现网络故障,客户端依然能够找到需要的服务的地址,从而保证系统高可用。
springcloud(十三):注册中心 Consul 使用详解
2. Spring Cloud之Ribbon
-
作用:可切换服务间调用的负载均衡算法
-
实现:
- 引入Ribbon的依赖
- 在定义RestTemplate的实例方法上加@LoadBalanced注解
-
原理:底层使用了拦截器,在调用服务时,会经过Ribbon的拦截器,将服务名解析为服务的地址:IP+端口的形式替换原有的服务名,从而完成调用
-
负载均衡的策略
策略类 | 命名 | 描述 |
---|---|---|
RandomRule | 随机策略 | 随机选择server |
RoundRobinRule | 轮询策略 | 按照顺序选择server(ribbon默认策略) |
RetryRule | 重试策略 | 在一个配置时间段内,当选择server不成功,则一直尝试选择一个可用的server |
BestAvailableRule | 最低并发策略 | 逐个考察server,如果server断路器打开,则忽略,再选择其中并发链接最低的server |
AvailabilityFilteringRule | 可用过滤策略 | 过滤掉一直失败并被标记为circuit tripped的server,过滤掉那些高并发链接的server(active connections超过配置的阈值) |
ResponseTimeWeightedRule | 响应时间加权重策略 | 根据server的响应时间分配权重,响应时间越长,权重越低,被选择到的概率也就越低。响应时间越短,权重越高,被选中的概率越高,这个策略很贴切,综合了各种因素,比如:网络,磁盘,io等,都直接影响响应时间 |
ZoneAvoidanceRule | 区域权重策略 | 综合判断server所在区域的性能和server的可用性,轮询选择server并且判断一个AWS Zone的运行性能是否可用,剔除不可用的Zone中的所有server |
3. Spring Cloud之Hystrix
- 作用:解决因其中的一个服务挂掉而无法调用,导致级联故障,整个系统都无法使用,从而产生雪崩的结果,提供容错保护的机制,
- 实现:
- 引入Hystrix的依赖
- 在应用上加入@EnableHystrix注解
- 在调用服务的Service方法上加入@HystrixCommand注解,并标明备用方法
- 实现备用方法,调用即可
- 原理:发起请求通过Histrix线程池,不同的服务调用会走不同的线程池,实现了服务调用的隔离,在调用达到容错的阈值时,会调用备用的方法进行处理,避免级联故障
4. Spring Cloud之Feign
- 作用:使用Spring MVC申明式注解调用,基于Ribbon实现,有负载均衡的功能,还整合了Hystrix,但在Dalston版本中是关闭的
- 实现:
- 引入Feign的依赖
- 在应用上加入@EnableFeignClients注解
- 在调用服务的Service类上加上@FeignClient注解,标注服务名,并根据Spring MVC的注解格式注解接口的方法
- 调用服务,直接调用上述的接口方法即可
- 原理:通过动态代理实现,实际调用的是根据注解解析生成的一个代理,代理实现的功能是找到服务地址,调用后再将数据组装返回
5. Spring Cloud之Zuul
- 作用:对外提供统一的网关功能,统一的调用方式,校验、权限控制、负载均衡的功能
- 实现:
- 创建项目,引入zuul依赖
- 在应用上加入@EnableZuulProxy注解
- 配置路由规则
- 配置ZuulFilter
- 启动测试
- 原理:在服务调用前,先通过一层网关,统一封装了网关的功能
6. Spring Cloud之Config
- 作用:集中管理服务的配置,提高了复用性和维护性
- 实现:
- 创建Config Server
- 引入Cloud的依赖,加入config-server的包
- 编写启动类
- application.yml配置文件中进行配置,配置获取配置文件的方式和位置
- 启动
- 创建Config Client
- 引入Cloud的依赖,加入config和actuator(加入refresh配置的功能)的包
- bootstrap.yml配置文件中加入配置服务的地址,在application.yml配置文件中启用actuator
- 通过注解的方式引入配置,在类上加入@RefreshScope的功能
- 调用refresh请求会进行配置文件的刷新
- 创建Config Server
- 原理(猜测):客户端在启动时,会首先根据配置的Config服务取获取相应的配置文件,当收到refresh方法时,会再去获取一遍参数,进行更新
7. Spring Cloud之Bus
- 作用:统一的通知所有的服务或者配置的维度的服务
- 实现:
- 在conifg-server中加入bus-amqp依赖
- 配置文件中加入rabbitmq配置
- web-hook地址修改为config-server地址/bus/refresh
- 启动测试
- 原理:会将refresh统一分发出去
8. Spring Cloud与Dubbo区别
- spring cloud集成的组件更多,本身含有注册中心,而dubbo的注册中心是zookeeper
- 服务和注册中心间的连接协议不同,spring cloud是http,而dubbo的协议更加多样,基于长连接的方式交互,性能相对更好
- spring cloud通过心跳通知服务的消费者,而zookeeper通过长连接通知服务的变更
- dubbo是RPC,依赖关系更大,需要接口相同,而spring cloud是REST方式,更为轻量化,但是容易导致接口定义和文档不一致,但可通过swagger解决