微服务的简介和springcloud的入门(Eureka和Nacos注册中心、Ribbon负载均衡)

最新推荐文章于 2024-05-28 15:27:23 发布

张晗的库

最新推荐文章于 2024-05-28 15:27:23 发布

阅读量89

点赞数

分类专栏：微服务入门文章标签： eureka spring cloud 微服务

本文链接：https://blog.csdn.net/z1659079591/article/details/131291886

版权

微服务入门专栏收录该内容

5 篇文章 0 订阅

订阅专栏

1. 微服务的简介

1.1 单体架构的优缺点

优点：

架构简单
部署成本低

缺点：

耦合度高（维护困难、升级困难）

1.2 分布式架构的优缺点

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

优点：

降低服务耦合
有利于服务升级和拓展

缺点：

服务调用关系错综复杂

1.3 微服务

微服务的架构特征：

单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
自治：团队独立、技术独立、数据独立，独立部署和交付
面向服务：服务提供统一标准的接口，与语言和技术无关
隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

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

1.4 springcloud

SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。

分类	组件
服务注册发现	Eureka、Nacos、Consul
统一配置管理	Springcloudconfig、Nacos
服务远程调用	OpenFeign、Dubbo
统一网关路由	SpringCloudGateway、Zuul
服务链路监控	zipkin、Sleuth
流控、降级、保护	Hystix、Sentienl

2. Eureka注册中心

2.1 Eureka结构和作用

在这里插入图片描述
一个微服务，既可以是服务提供者，又可以是服务消费者，因此eureka将服务注册、服务发现等功能统一封装到了eureka-client端。

2.2 搭建Eureka-server

创建Eurreka-server服务
引入Eureka依赖

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

编写启动类（添加@EnableEurekaServer注解，开启Eureka的注册中心功能）
编写配置文件

server:
  port: 10086   #端口号
spring:
  application:
    name: eureka-server  # Eureka服务的名称，也要将自己注册
eureka:
  client:
    service-url: 
      defaultZone: http://127.0.0.1:10086/eureka  # 默认的注册地址

启动服务访问地址http://127.0.0.1:10086

2.3 服务注册

引入依赖
在需要注册的服务中引入依赖：

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

配置文件（添加eureka的地址以及服务的名字）
启动多个实例

2.4 服务发现

引入依赖
在服务消费者中引入依赖：

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

配置文件（配置eureka地址及服务名称）
服务拉取和负载均衡
在消费者的启动类中定义RestTemplate这个Bean，并添加一个@LoadBalanced注解；
修改服务中需要访问的服务的IP地址为服务提供者的名称，实现访问。

3. ribbon负载均衡

3.1 负载均衡原理

在这里插入图片描述

3.2 源码追踪

LoadBalancerIntercepor类
在类里的intercept方法，拦截了用户的HttpRequest请求，然后做了几件事：

request.getURI()：获取请求uri，本例中就是 http://user-service/user/8
originalUri.getHost()：获取uri路径的主机名，其实就是服务id，user-service
this.loadBalancer.execute()：处理服务id，和用户请求。

LoadBalancerClient类
跟入execute方法：

getLoadBalancer(serviceId)：根据服务id获取ILoadBalancer，而ILoadBalancer会拿着服务id去eureka中获取服务列表并保存起来。
getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。

负载均衡策略IRule
继续跟踪源码chooseServer方法，通过一个rule进行策略的选择；
这里的rule默认值是一个RoundRobinRule（轮询）。

启动类中定义了规则，则会自动替换rule中的规则。
流程图

3.3 负载均衡策略

3.3.1 负载均衡策略

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

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

3.3.2 自定义负载均衡策略

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

代码方式：在order-service中的OrderApplication类中，定义一个新的IRule。
配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则

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

3.4 饥饿加载

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

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

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

4. Nacos注册中心

4.1 服务注册

引入依赖
在父工程引入alibaba的全部管理依赖

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

在服务中引入依赖

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

配置nacos地址
重启服务

4.2 服务分级存储模型

一个服务可以有多个实例，Nacos将同一机房内的实例划分为一个集群。
在这里插入图片描述
微服务互相访问时，应该尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。

4.2.1 给服务分配集群

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

再复制一个服务，添加配置，转换为其他集群

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH

4.2.2 同集群的负载均衡策略

修改负载均衡规则，将之前的启动类的规则注掉，在配置文件中添加：

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则

4.3 环境隔离

Nacos提供了namespace来实现环境隔离功能。

nacos中可以有多个namespace
namespace下可以有group、service等
不同namespace之间相互隔离，例如不同namespace的服务互相不可见

4.4 Nacos和Eureka注册中心的区别

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

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

配置一个服务实例为永久实例：

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

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

张晗的库

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
微服务的简介和springcloud的入门(Eureka和Nacos注册中心、Ribbon负载均衡)

架构简单部署成本低耦合度高（维护困难、升级困难）代码方式：在order-service中的OrderApplication类中，定义一个新的IRule。配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则。
复制链接

扫一扫