SpringCloud之Eureka注册中心和负载均衡

时间：2024-02-15 17:11:00

SpringCloud之Eureka注册中心和负载均衡

    • 微服务技术栈
    • 认识微服务
      • 单体架构
      • 分布式架构
      • 微服务
    • 微服务拆分及远程调用
      • 微服务拆分注意事项
    • Eureka注册中心
      • 提供者与消费者
      • 原理分析
        • 服务调用出现的问题
        • Eureka的作用
      • 使用流程
        • 1、搭建EurekaServer
        • 2、注册user-service
        • 3、在order-service完成服务拉取
    • Ribbon负载均衡
      • 负载均衡流程
      • 负载均衡策略
      • 饥饿加载

微服务技术栈

image-20240204192821766

认识微服务

单体架构

简介：将业务内的所有功能集中在一个项目中开发，打成一个包部署。

  1. 优点

    • 架构简单

    • 部署成本低

  2. 缺点

    • 耦合度高

分布式架构

简介：根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务。

  1. 优点
    • 降低服务耦合
    • 有利于服务升级拓展
  2. 缺点
    • 服务治理麻烦

微服务

简介：是一种经过良好架构设计的分布式架构方案。

特征：

  • 单一职责：微服务拆分粒度更小，每个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
  • 面向服务：微服务对外暴露业务接口
  • 自治：团队独立，技术独立，数据独立，部署独立
  • 隔离性强：服务调用做好隔离、若错、降级、避免出现级联失败

微服务拆分及远程调用

微服务拆分注意事项

  1. 不同微服务，不要重复开发相同业务
  2. 微服务数据独立，不要访问其它微服务的数据库
  3. 微服务可以将自己的业务暴露为接口，供其它微服务调用

当我们某一个服务需要获取到其他服务的数据库信息时，我们就需要从当前服务向目标服务发送http请求，调用对应的接口获取数据。

  1. 在配置类中将RestTemplate注入容器
@Bean
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
  1. 在对应服务功能下注入容器并发送http请求
@Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.利用restTemplate发送http请求，查询用户
        String url = "http://localhost:8081/user/" + order.getUserId();
        User user= restTemplate.getForObject(url, User.class);
        // 3.封装成Order对象
        order.setUser(user);
        // 4.返回
        return order;
    }

在这里插入图片描述

从结果可以看到成功拿到用户信息。

Eureka注册中心

提供者与消费者

  • 服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）
  • 服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

原理分析

在这里插入图片描述
在服务调用的时候，地址固定，当项目环境发生变化时，对项目很不友好。

服务调用出现的问题
  • 服务消费者该如何获取服务提供者的地址信息？
  • 如果有多个服务提供者，消费者该如何选择？
  • 消费者如何得知服务提供者的健康状态？
Eureka的作用

在这里插入图片描述

  1. 消费者该如何获取服务提供者具体信息？

    ◆服务提供者启动时向eureka注册自己的信息

    ◆eureka保存这些信息

    ◆消费者根据服务名称向eureka拉取提供者信息

  2. 如果有多个服务提供者，消费者该如何选择？

    ◆服务消费者利用负载均衡算法，从服务列表中挑选一个

  3. 消费者如何感知服务提供者健康状态？

    ◆服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态

    ◆eureka会更新记录服务列表信息，心跳不正常会被剔除

    ◆消费者就可以拉取到最新的信息

使用流程

1、搭建EurekaServer

搭建EurekaServer服务步骤如下：
1.创建项目，引入spring-cloud-starter-netflix-eureka-server的依赖

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

2.编写启动类，添加@EnableEurekaServer注解
3.添加application.yml文件，编写下面的配置：

server:
  	port: 8082
spring:
	application:
		name: eureka-server
#eureka自己也会被注册
eureka:
	client:
		service-url:
			defaultZone:http://localhost:8082/eureka/

在这里插入图片描述

2、注册user-service

将user-service服务注册到EurekaServer:步骤如下：
l.在user-service:项目引入spring-cloud-starter–netflix-eureka-client的依赖

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

2.在application.yml文件，编写下面的配置：

spring:
	application:
		name: userservice
eureka:
	client:
		service-url:
			#指的是注册中心服务的地址
			defaultZone: http://localhost:8082/eureka/

拓展：在idea启动单个项目的多个实例：

  1. 在服务界面右键服务，复制配置

在这里插入图片描述

  1. 2023版本的idea需要添加虚拟机选项以及打开允许多个实例

在这里插入图片描述

image-20240210133301341
  1. 在虚拟机配置**-Dserver.port=8083**（端口选择一个未用的），同时修改服务名称

在这里插入图片描述

  1. 在服务页面中启动项目

在这里插入图片描述

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();
}

负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。

这种环境下，当我们的order-server向user-server发送http请求时，会平衡地向不同实例的user-server发送请求。

Ribbon负载均衡

负载均衡流程

image-20240208161941436

在这里插入图片描述

负载均衡策略

Ribbon的负载均衡规则是一个叫做IRule的接口来定义的，每一个子接口都是一种规则：

在这里插入图片描述

内置负载均衡规则类 规则描述
RoundRobinRule 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
AvailabilityFilteringRule 对以下两种服务器进行忽略：(1)在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。(2)并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的:.:.ActiveConnectionsLimit属性进行配置。
WeightedResponseTimeRule 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择
ZoneAvoidanceRule 服务器，这个权重值会影响服务器的选择。
以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
BestAvailableRule 忽略哪些短路的服务器，并选择并发数较低的服务器。
RandomRule 随机选择一个可用的服务器。
RetryRule 重试机制的选择逻辑

IRule默认为轮询规则，通过定义Rule实现可以修改负载均衡规则，有两种方式：

  1. 代码方式：在order-service中的OrderApplication类中，定义一个新的IRule:

    @Bean
public IRule randomRule(){
return new RandomRule();
}

  2. 配置文件方式：在order-.servicef的application,ym段件中，
    添加新的配置也，可以修改规侧：

    user-service:
	ribbon:
		NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RandomRule #负载均规则

饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient,请求时间会很长。
而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

ribbon:
	eager-load:
		enabled: true #开启饥饿加载
			clients: user-server #指定劢user-server这个服务饥饿加载

相关文章