SpringCloud学习笔记

day 01 spring cloud

认识微服务

• 服务架构的演变

  • 单体架构：所有的模块集成在一个包里面部署
    • 架构简单
    • 部署成本低
    • 耦合度高
  • 分布式架构：对系统进行拆分、业务模块独立开发、一个模块就是一个服务
    • 降低耦合度
    • 有利于服务升级拓展
    • 服务调用关系错综复杂

• 微服务是一种经过良好架构设计的分布式架构方案，微服务架构特征：

  • 单一职责：拆分粒度小
    • 面向服务：多外暴露业务接口
    • 自治：团队独立、技术独立、数据独立、部署独立
      - 隔离性强：隔离、容错、降级，避免出现级联问题

• 微服务的技术对比

  ​

  	Dubbo	SpringCloud	SpringCloudAlibaba
  注册中心	zookeeper、Redis	Eureka、consul	Nacos、Eureka
  服务远程调用	Dubbo协议	Feign（http）	Dubbo、Feign
  配置中心	无	SpringCloudConfig	SpringCloudConfig、Nacos
  服务网关	无	SpringCloudGateway、Zuul	SpringCloudGateway、Zuul
  服务监控和保护	dubbo-admin，功能弱	Hystrix	Sentinel

服务拆分与调用

注意事项

1. 不要重复开发相同的业务
2. 数据独立不要访问其他微服务的数据库

微服务远程调用

提供者和消费者

• 服务提供者：一次业务中，被其他微服务调用的服务。（提供接口给其他服务）
• 服务消费者：一次业务中，调用其他微服务的服务。（调用其他微服务提供的接口）
• 角色都是相对的

Eureka注册中心（尤里卡！）

远程调用的问题

​ 服务调度

eureka原理

​ eureka帮助记录服务器信息，服务提供者会每30秒向注册中心发送心跳续约

问题1：order-service如何得知user-service实例地址？

获取地址信息的流程如下：

• user-service服务实例启动后，将自己的信息注册到eureka-server（Eureka服务端）。这个叫服务注册
• eureka-server保存服务名称到服务实例地址列表的映射关系
• order-service根据服务名称，拉取实例地址列表。这个叫服务发现或服务拉取

问题2：order-service如何从多个user-service实例中选择具体的实例？

• order-service从实例列表中利用负载均衡算法选中一个实例地址
• 向该实例地址发起远程调用

问题3：order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

• user-service会每隔一段时间（默认30秒）向eureka-server发起请求，报告自己状态，称为心跳
• 当超过一定时间没有发送心跳时，eureka-server会认为微服务实例故障，将该实例从服务列表中剔除
• order-service拉取服务时，就能将故障实例排除了

• EurekaServer注册中心
  - 记录服务信息
  - 心跳检测
• EurekaClient
  • Provider：服务提供者
    • 注册自己的信息到EurekaServer
    • 每隔30秒向注册中心发送心跳（防挂）
  • Consumer：服务消费者
    • 根据服务的名称从注册中心拉取服务列表
    • 基于服务列表做负载均衡，选中一个微服务后发起远程调用

搭建EurekaServer

• 引入eureka-server依赖
• 添加@EnableEurekaServer注解
• 在application.yml中配饰Eureka地址

服务注册

• 引入eureka-client依赖
• 在application.yml中配置eureka地址

服务发现

• 引入eureka-client依赖
• 在application.yml中配置eureka地址
• 给RestTemplate添加@LoadBalance注解
• 用服务提供者的服务名远程调用

Ribbon负载均衡

负载均衡的流程

​ 底层是Ribbon组件完成的负载均衡

1. 规则接口是IRule
2. 默认实现是ZoneAvoidanceRule，根据Zone选择服务列表，然后轮询

4.3.1.负载均衡策略

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

自定义负载均衡策略

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

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

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

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

1. 代码方式：配置灵活，但修改是要重新打包发布
2. 配置方式：直观，方便，无需重新打包发布，但无法做全局配置

饥饿加载

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

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

ribbon:
  eager-load:
    enabled: true # 开启饥饿加载
    clients: userservice # 指定对userService这个服务饥饿加载

1. 开启饥饿加载
2. 指定饥饿加载的微服务名称

Nacos注册中心

1. Nacos服务搭建

1. 下载安装包
2. 解压
3. 在bin目录下运行：startup.cmd -m standalone单机启动

2.Nacos服务注册发现

1. 引入nacos.discovery依赖
2. 配置nacos地址spring.cloud.nacos.server-addr

Nacos读物分级存储模型

 > 服务跨集群调度问题
 >
 > ​	服务调用尽可能选择本地集群的服务，跨集群调用它延迟较高
 >
 > 本地集群不可访问时，再去访问其他集群

1. 一级时服务，例如userservice
2. 二级是集群，例如杭州和上海
3. 三级是实例，例如杭州机房的某台部署了userservice的服务器

如何设置实例的集群属性

1. 修改application.yml文件，添加spring.cloud.nacos.discovert.cluster-name属性 #集群名称

加权负载均衡：

1. Nacos控制台可以设置实例的权重值0~1之间
2. 统计群内的多个实例，权重越高被访问的频率越高
3. 权重设置为0则完全不会被访问
   

命名空间

Nacos环境隔离：

1. namespace用来做环境隔离
2. 每个namespace都有唯一的id
3. 不同namespace下的服务不可见

Nacos注册中心细节分析

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

Nacos的服务实例分为两种l类型：

• 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
• 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

Nacos与eureka对比

• Nacos与eureka的共同点
  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测
• Nacos与Eureka的区别
  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
    列表剔除，也可以叫永久实例。

Nacos与eureka对比

• Nacos与eureka的共同点
  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测
• Nacos与Eureka的区别
  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
  • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式