notebook
yubin
2022-03-05
目录

Spring Cloud 快速入门 1：概述与注册中心

# 1. 认识微服务

# 1.1 单体架构与分布式架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。

  • 优点：架构简单，部署成本低
  • 缺点：耦合度高（维护困难、升级困难）

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

  • 优点：降低服务耦合，有利于服务升级和拓展
  • 缺点：服务调用关系错综复杂

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

  • 服务拆分的粒度如何界定？
  • 服务之间如何调用？
  • 服务的调用关系如何管理？

# 1.2 微服务

微服务的架构特征：

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

image-20220305200314698

可以认为微服务是一种经过良好架构设计的分布式架构方案 。

# 1.3 Spring Cloud

Spring Cloud 集成了各种微服务功能组件，并基于 Spring Boot 实现了这些组件的自动装配，从而提供了良好的开箱即用体验。常见的组件如下：

image-20210713204155887

我们所学的版本是 Spring Cloud Hoxton.SR10，对应的 Spring Boot 版本是2.3.x版本。

微服务技术对比：

Dubbo Spring Cloud Spring Cloud Alibaba
注册中心 zookeeper、Redis Eureka、Consul Nacos、Eureka
服务远程调用 Dubbo协议 Feign（http协议） Dubbo、Feign
配置中心 无 Spring Cloud Config Spring Cloud Config、Nacos
服务网关 无 Spring Cloud Gateway、Zuul Spring Cloud Gateway、Zuul
服务监控和保护 dubbo-admin，功能弱 Hystix Sentinel

企业常见应用情况：

image-20220305201206613

# 2. 服务拆分和远程调用

# 2.1 服务拆分原则

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

# 2.2 服务拆分示例

有一个 cloud-demo 工程，里面有两个微服务：

  • order-service：订单微服务，负责订单相关业务
  • user-service：用户微服务，负责用户相关业务

要求：

  • 订单微服务和用户微服务都必须有各自的数据库，相互独立
  • 订单服务和用户服务都对外暴露 Restful 的接口
  • 订单服务如果需要查询用户信息，只能调用用户服务的 Restful 接口，不能查询用户数据库

项目结构：

image-20220305202451471

用 IDEA 打开后，可以在 Services 一栏中看到所有的微服务：

image-20220305203644409

# 2.3 远程调用案例

在 order-service 服务中，有一个根据 id 查询订单的接口，在 user-service 中有一个根据 id 查询用户的接口。现在我们想修改 order-service 中的根据 id 查询订单业务，要求在查询订单的同时，根据订单中包含的 userId 查询出用户信息，一起返回：

image-20210713213312278

因此，我们需要在 order-service 中，向 user-service 发起一个 http 的请求，调用http://localhost:8081/user/{userId}这个接口。大致步骤：

  • 注册一个 RestTemplate 的实例到 Spring 容器
  • 修改 order-service 服务中的 OrderService 类中的 queryOrderById 方法，根据Order对象中的 userId 查询 User
  • 将查询的 User 填充到 Order 对象，一起返回

# 1）注册 RestTemplate

注入一个 RestTemplate 的 Bean：

import org.springframework.web.client.RestTemplate;

@Bean
public RestTemplate restTemplate() {
    return new RestTemplate();
}
1
2
3
4
5
6

# 2）实现远程调用

修改 order-service 服务中的 OrderService 类中的 queryOrderById 方法：








 








 







@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.利用RestTemplate发起http请求，查询用户
        // 2.1.url路径
        String url = "http://localhost:8081/user/" + order.getUserId();
        // 2.2.发送http请求，实现远程调用
        User user = restTemplate.getForObject(url, User.class);
        // 3.封装user到Order
        order.setUser(user);
        // 4.返回
        return order;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 2.4 提供者与消费者

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

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

服务提供者与服务消费者的角色并不是绝对的，而是相对于业务而言。一个服务既可以是提供者，也可以是消费者。

# 3. Eureka 注册中心

# 3.1 Eureka 的结构和作用

image-20210713220104956

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

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

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

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

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

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

# 3.2 搭建 Eureka Server

首先大家注册中心服务端：eureka-server，这必须是一个独立的微服务。

# 1）创建 eureka-server 服务

在 cloud-demo 父工程下，创建一个子模块并填写相关信息：

image-20210713220605881

该服务可以命名为 eureka-server。

# 2）引入 Eureka 依赖

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

# 3）编写启动类

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








 






package cn.itcast.eureka;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class EurekaApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaApplication.class, args);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

# 4）编写配置文件

编写一个 application.yml 文件，内容如下：

server:
  port: 10086
spring:
  application:
    name: eureka-server
eureka:
  client:
    service-url: 
      defaultZone: http://127.0.0.1:10086/eureka
1
2
3
4
5
6
7
8
9
  • Eureka 由于自己本身也是一个微服务，所有自己也会将自己注册进去。

# 5）启动服务

启动微服务，然后在浏览器访问：http://127.0.0.1:10086

看到下面结果应该是成功了：

image-20210713222157190

# 3.3 服务注册

下面，我们将 user-service 注册到 eureka-server 中去。

# 1）引入依赖

在 user-service 的pom文件中，引入下面的 eureka-client 依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
1
2
3
4
  • 注意刚刚的是 Eureka server 端，现在的是 client 端。

# 2）配置文件

spring:
  application:
    name: userservice  # 该服务的名称
eureka:
  client:
    service-url:  # Eureka 的地址信息
      defaultZone: http://127.0.0.1:10086/eureka
1
2
3
4
5
6
7

到此，该服务就被注册进 Eureka 中了。其他服务的配置也类似。

# 3）启动多个 user-service 实例

为了演示一个服务有多个实例的场景，我们添加一个 Spring Boot 的启动配置，再启动一个 user-service。

首先，复制原来的 user-service 启动配置：

image-20210713222656562

然后，在弹出的窗口中，填写信息：

image-20210713222757702

现在，Spring Boot 窗口会出现两个 user-service 启动配置：

image-20210713222841951

不过，第一个是 8081 端口，第二个是 8082 端口。

启动两个 user-service 实例：

image-20210713223041491

查看 eureka-server 管理页面：

image-20210713223150650

# 3.4 服务发现

最后，我们要去 eureka-server 中拉取 user-service 服务的实例列表，并且实现负载均衡。不过这些动作不用我们去做，只需要添加一些注解即可。

在 order-service 的 OrderApplication 中，给 RestTemplate 这个 Bean 添加一个 @LoadBalanced 注解：













 





@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    /**
     * 创建RestTemplate并注入Spring容器
     */
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

修改 order-service 服务中的 cn.itcast.order.service 包下的 OrderService 类中的 queryOrderById 方法。修改访问的 url 路径，用服务名代替 ip 和端口：

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.利用RestTemplate发起http请求，查询用户
        // 2.1.url 路径
-        String url = "http://localhost:8081/user/" + order.getUserId();
+        String url = "http://userservice/user/" + order.getUserId();
        // 2.2.发送http请求，实现远程调用
        User user = restTemplate.getForObject(url, User.class);
        // 3.封装user到Order
        order.setUser(user);
        // 4.返回
        return order;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
  • 注意请求的 URL 的变化，用服务名代替 ip 和端口，这个服务名就是注册入 Eureka 中的。

Spring 会自动帮助我们从 eureka-server 端，根据 userservice 这个服务名称，获取实例列表，而后完成负载均衡。

# 4. Ribbon 负载均衡

Spring Cloud 底层其实是利用了一个名为 Ribbon 的组件，来实现负载均衡功能的。负载均衡的流程：

image-20210713224517686

# 4.1 原理分析

分析源码后，可以看到 Ribbon 的底层采用了一个拦截器，拦截了 RestTemplate 发出的请求，对地址做了修改。用一幅图来总结一下：

image-20210713224724673

基本流程如下：

  • 拦截我们的 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，发起真实请求

# 4.2 负载均衡策略

# 4.2.1 自带的负载均衡策略

负载均衡的规则都定义在 IRule 接口中，而 IRule 有很多不同的实现类，代表了不同的规则。不同规则的含义如下：

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

# 4.2.2 自定义负载均衡策略

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

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

@Bean
public IRule randomRule(){
    return new RandomRule();
}
1
2
3
4

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

userservice: # 给某个微服务配置负载均衡规则
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
1
2
3

# 4.3 饥饿加载

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

这可以在浏览器开发者工具的“网络”中看到请求时间。

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

ribbon:
  eager-load:
    enabled: true  # 开启饥饿加载
    clients: userservice  # 指定对哪个服务做饥饿加载
1
2
3
4

饥饿加载，顾名思义就是饥不择食，在创建之初就加载起来了。

# 5. Nacos 注册中心

Nacos 是 Spring Cloud Alibaba 的组件，而 Spring Cloud Alibaba 也遵循 Spring Cloud 中定义的服务注册、服务发现规范。因此使用 Nacos 和使用 Eureka 对于微服务来说，并没有太大区别。

先安装单机版 Nacos

# 5.1 服务注册到 nacos

与 Eureka 主要差异在于：依赖不同，服务地址不同。

# 1）引入依赖

在cloud-demo父工程的 pom 文件中的 <dependencyManagement> 中引入 Spring Cloud 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>
1
2
3
4
5
6
7

然后在 user-service 和 order-service 中的 pom 文件中引入 nacos-discovery 依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
1
2
3
4
  • 注意不要忘了注释掉 eureka 的依赖。

# 2）配置 nacos 地址

在 user-service 和 order-service 的 application.yml 中添加 nacos 地址：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
1
2
3
4
  • 不要忘了注释掉eureka的地址

# 3）启动微服务

启动微服务后，登录 nacos 管理页面，可以看到微服务信息：

image-20210713231439607

# 5.2 服务分级存储模型

一个服务可以有多个实例，Nacos 就将同一机房内的实例划分为一个集群。也就是说，user-service 是服务，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型，如图：

image-20210713232522531

微服务互相访问时，应该尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。

# 5.2.1 给 user-service 配置集群

修改 user-service 的 application.yml 文件，添加集群配置：






 

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称
1
2
3
4
5
6

不同的实例，只需要修改 cluster-name 属性即可。

启动多个实例后，在 nacos 控制台可以看到：

image-20210713233727923

# 5.2.2 同集群优先的负载均衡

默认的 ZoneAvoidanceRule 并不能实现根据同集群优先来实现负载均衡。因此 Nacos 中提供了一个 NacosRule 的实现，可以优先从同集群中挑选实例。

# 1）给 order-service 配置集群信息

修改 order-service 的 application.yml 文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称
1
2
3
4
5
6
# 2）修改负载均衡规则

修改 order-service 的 application.yml 文件，修改负载均衡规则：



 

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

NacosRule 负载均衡策略：

  1. 优先选择同集群服务实例列表
  2. 本地集群找不到提供者，才去其它集群寻找，并且会报警告
  3. 确定了可用实例列表后，再采用随机负载均衡挑选实例

# 5.3 权重配置

实际部署中会出现这样的场景：服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。但默认情况下 NacosRule 是同集群内随机挑选，不会考虑机器的性能问题。因此，Nacos 提供了权重配置来控制访问频率，权重越大则访问频率越高。

在 nacos 控制台，找到 user-service 的实例列表，点击编辑，即可修改权重：

image-20210713235133225

在弹出的编辑窗口，修改权重：

image-20210713235235219
  • 如果权重修改为 0，则该实例永远不会被访问。

# 5.4 环境隔离

Nacos 中服务存储和数据存储的最外层都是一个名为 namespace 的东西，用来做最外层的环境隔离。

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

# 5.4.1 创建 namespace

默认情况下，所有 service、data、group 都在同一个 namespace，名为 public：

image-20210714000414781

在该页面可以点击新增按钮，从而添加一个 namespace：

image-20220306142315482

  • dev 是新增加的 namespace

# 5.4.2 给微服务配置 namespace

给微服务配置 namespace 只能通过修改配置来实现。

例如，修改 order-service 的 application.yml 文件：







 

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID
1
2
3
4
5
6
7

重启 order-service 后，访问控制台，可以在 dev 的 namespace 下看到该服务实例。此时访问 order-service，因为 namespace 不同，会导致找不到处于其他命名空间的 user-service，控制台会报错：

image-20210714000941256

# 5.5 Nacos 与 Eureka 的区别

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

  • 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。

  • 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

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

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例
1
2
3
4
5

Nacos 和 Eureka 整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

image-20210714001728017

  • Nacos 与 Eureka 的共同点

    • 都支持服务注册和服务拉取
    • 都支持服务提供者心跳方式做健康检测

  • Nacos 与 Eureka 的区别

    • Nacos 支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
    • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除，只是显示为不健康了
    • Nacos 支持服务列表变更的消息推送模式，服务列表更新更及时
    • Nacos 集群默认采用 AP 方式，当集群中存在非临时实例时，采用 CP 模式；Eureka 采用 AP 方式
编辑 (opens new window)
上次更新: 2023/04/22, 08:56:42
Spring Boot 的优雅停机
Spring Cloud 快速入门 2：配置管理、远程调用和网关

← Spring Cloud 快速入门 2：配置管理、远程调用和网关→

最近更新
01
Deep Reinforcement Learning
10-03
02
误删数据后怎么办
04-06
03
MySQL 一主多从
03-22
更多文章>
Theme by Vdoing | Copyright © 2021-2024 yubincloud | MIT License
×