526互联

springCloud学习笔记整理

发布时间 2023-09-05 17:33:46作者: 玛尼玛尼哄~

springCloud学习笔记整理

1.分布式

分布式的概念：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。

分布式架构的优缺点：

优点：

  • 降低服务耦合

  • 有利于服务升级和拓展

缺点：

  • 服务调用关系错综复杂

2.微服务

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。

其中常见的组件包括：

image-20210713204155887

 

3.总结

  • 单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统

  • 分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝

  • 微服务：一种良好的分布式架构方案

    ①优点：拆分粒度更小、服务更独立、耦合度更低

    ②缺点：架构非常复杂，运维、监控、部署难度提高

  • SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件

 

4.Eureka注册中心

服务注册中心：用于管理微服务提供者的注册与发现的组件。在分布式微服务架构中，服务注册中⼼用于存储服务提供者地址信息、服务发布相关的属性信息，消费者通过主动查询和被动通知的方式获取服务提供者的地址信息，不再需要通过硬编码⽅式得到提供者的地址信息。

Eureka注册中心

①Eureka 包含两个组件：Eureka Server 和 Eureka Client

②每⼀个Eureka Server都是⼀个集群可以相互注册

③Eureka Client作为服务提供者向Eureka Server中注册服务，Eureka Server接受到注册事件会在集群和分区中进⾏数据同步，

Eureka Client作为消费端（服务消费者）可以从Eureka Server中获取到服务注册信息，进⾏服务调⽤。

④微服务启动后，会周期性地向Eureka Server发送⼼跳（默认周期为30秒）以续约⾃⼰的信息

⑤Eureka Server在⼀定时间内没有接收到某个微服务节点的⼼跳，Eureka Server将会注销该微服务节点（默认90秒）

⑥Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消费者依然可以使⽤缓存中的信息找到服务提供者

5.Eureka注册

Eureka server依赖

<dependencies>
        <!--Eureka server依赖-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>
 </dependencies>
    

Eureka server客户端配置

#euraka客户端配置（和Server交互）
eureka:
  instance:
    hostname: localhost #当前Eureka实例的主机名
  client:
    service-url: #配置客户端所交互的Eureka
      defaultZone: http://${eureka.instance.hostname}}:8761/eureka
    register-with-eureka: false #当前自己就是server,不需要注册自己
    fetch-registry: false #查询获取注册中心的服务信息，自己就是Server，所以不需要获取

eureka-server服务编写一个启动类时一定要添加一个@EnableEurekaServer注解，开启eureka的注册中心功能：

Eureka-Clien依赖和配置

#Eureka-Clien依赖
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
​
#Eureka-Clien配置
ureka:
  client:
    service-url:
      defaultZone: http://localhost:端口/eureka
6.服务拉取和负载均衡

给RestTemplate这个Bean添加一个@LoadBalanced注解可实现服务列表拉取实现负载均衡

// 写在启动类或者通过@Configuration实现自动配置
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
    return new RestTemplate();
}
7.Ribbon负载均衡

Ribbon 底层采用了一个拦截器，拦截了请求服务发出的http请求，对地址做了修改

基本流程如下：

  • 拦截我们的RestTemplate请求http://userservice/user/1

  • RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service

  • DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表

  • eureka返回列表，localhost:8081、localhost:8082

  • IRule利用内置负载均衡规则，从列表中选择一个，例如localhost:8081

  • RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实请求

负载均衡策略

负载均衡的规则都定义在IRule接口中，而IRule有很多不同的实现类：

image-20210713225653000

不同规则的含义如下：

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

 

默认的实现就是ZoneAvoidanceRule，是一种轮询方案

自定义负载均衡策略

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

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

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

 

  1. 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

注意，一般用默认的负载均衡规则，不做修改。

饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    enabled: true
    clients: userservice