SpringCloud学习笔记

目录

一、认识微服务

单体架构

分布式架构

微服务

SpringCloud

内容知识

技术栈对比

服务拆分

远程调用

二、Eureka注册中心

搭建注册中心

服务注册

服务拉取

三、Ribbon负载均衡

源码跟踪

流程总结

负载均衡策略

自定义策略

饥饿加载

四、Nacos注册中心

服务注册

分级存储模型

配置集群

NacosRule

权重配置

环境隔离

创建namespace

配置namespace

临时实例

五、Nacos配置中心

创建配置

拉取配置

配置热更新

@RefreshScope

@ConfigurationProperties

配置共享

配置优先级

六、Feign远程调用

Feign使用

自定义配置

性能优化

最佳实践

继承方式

抽取方式

七、Gateway网关

入门使用

流程图

断言工厂

过滤器工厂

全局过滤器

过滤器顺序

跨域问题

八、RabbitMQ

同步异步通讯

MQ消息队列

入门案例

publisher实现

consumer实现

SpringAMQP

BasicQueue（普通队列）

WorkQueue（工作队列）

发布/订阅

Fanout

Direct

Topic

消息转换器

---

一、认识微服务

单体架构

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

优点：架构简单，部署成本低

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

分布式架构

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

优点：降低服务耦合，有利于服务升级和拓展

缺点：服务调用关系错综复杂

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

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

人们需要制定一套行之有效的标准来约束分布式架构。

微服务

微服务的架构特征：

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

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。

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

其中在 Java 领域最引人注目的就是 SpringCloud 提供的方案了。

SpringCloud

SpringCloud 是目前国内使用最广泛的微服务框架。官网地址：Spring Cloud。

SpringCloud 集成了各种微服务功能组件，并基于 SpringBoot 实现了这些组件的自动装配，从而提供了良好的开箱即用体验。

其中常见的组件包括：

内容知识

需要学习的微服务知识内容

技术栈

技术栈对比

服务拆分

服务拆分注意事项

单一职责：不同微服务，不要重复开发相同业务

数据独立：不要访问其它微服务的数据库

面向服务：将自己的业务暴露为接口，供其它微服务调用

cloud-demo：父工程，管理依赖

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

要求：

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

微服务项目下，打开 idea 中的 Service，可以很方便的启动。

启动完成后，访问 http://localhost:8080/order/101

远程调用

正如上面的服务拆分要求中所提到，

订单服务如果需要查询用户信息， 只能调用用户服务的 Restful 接口，不能查询用户数据库

因此我们需要知道 Java 如何去发送 http 请求，Spring 提供了一个 RestTemplate 工具，只需要把它创建出来即可。（即注入 Bean）

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

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

    /**
     * 创建RestTemplate并注入spring容器
     * @return
     */
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

发送请求，自动序列化为 Java 对象。

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.查询用户
        String url = "http://localhost:8081/user/" + order.getUserId();
        User user = restTemplate.getForObject(url, User.class);
        order.setUser(user);
        // 4.返回
        return order;
    }
}

启动完成后，访问：

http://localhost:8080/order/101

在上面代码的 url 中，我们可以发现调用服务的地址采用硬编码，这在后续的开发中肯定是不理想的，这就需要服务注册中心（Eureka）来帮我们解决这个事情。

二、Eureka注册中心

最广为人知的注册中心就是 Eureka，其结构如下：

order-service 如何得知 user-service 实例地址？

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

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

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

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

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

接下来我们动手实践的步骤包括：

搭建注册中心

搭建 eureka-server

引入 SpringCloud 为 eureka 提供的 starter 依赖，注意这里是用 server

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

编写启动类

注意要添加一个 @EnableEurekaServer 注解，开启 eureka 的注册中心功能

@EnableEurekaServer
@SpringBootApplication
public class EurekaApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaApplication.class,args);
    }
}

编写配置文件

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

server:
  port: 10086
spring:
  application:
    name: eurekaserver
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

其中 default-zone 是因为前面配置类开启了注册中心所需要配置的 eureka 的地址信息，因为 eureka 本身也是一个微服务，这里也要将自己注册进来，当后面 eureka 集群时，这里就可以填写多个，使用 “,” 隔开。

启动完成后，访问 http://localhost:10086/

服务注册

将 user-service、order-service 都注册到 eureka

引入 SpringCloud 为 eureka 提供的 starter 依赖，注意这里是用 client

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

在启动类上添加注解：@EnableEurekaClient

在 application.yml 文件，添加下面的配置：

spring:
  application:
      #name：orderservice
    name: userservice
eureka:
  client:
    service-url: 
      defaultZone: http:127.0.0.1:10086/eureka

3个项目启动后，访问 http://localhost:10086/

这里另外再补充个小技巧，我们可以通过 idea 的多实例启动，来查看 Eureka 的集群效果。

4个项目启动后，访问 http://localhost:10086/

服务拉取

在 order-service 中完成服务拉取，然后通过负载均衡挑选一个服务，实现远程调用

下面我们让 order-service 向 eureka-server 拉取 user-service 的信息，实现服务发现。

首先给 RestTemplate 这个 Bean 添加一个 @LoadBalanced 注解，用于开启负载均衡。（后面会讲）

    /**
     * 创建RestTemplate并注入spring容器
     * @return
     */
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }

修改 OrderService 访问的url路径，用服务名代替ip、端口：

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

三、Ribbon负载均衡

我们添加了 @LoadBalanced 注解，即可实现负载均衡功能，这是什么原理呢？

SpringCloud 底层提供了一个名为 Ribbon 的组件，来实现负载均衡功能。

源码跟踪

为什么我们只输入了 service 名称就可以访问了呢？为什么不需要获取ip和端口，这显然有人帮我们根据 service 名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor，这个类会在对 RestTemplate 的请求进行拦截，然后从 Eureka 根据服务 id 获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务 id。

我们进行源码跟踪：

这里的 intercept() 方法，拦截了用户的 HttpRequest 请求，然后做了几件事：

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

这里的 this.loadBalancer 是 LoadBalancerClient 类型

继续跟入 execute() 方法：

• getLoadBalancer(serviceId)：根据服务id获取 ILoadBalancer，而 ILoadBalancer 会拿着服务 id 去 eureka 中获取服务列表。
• getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。在图中可以看到获取了8082端口的服务

可以看到获取服务时，通过一个 getServer() 方法来做负载均衡:

我们继续跟入：

继续跟踪源码 chooseServer() 方法，发现这么一段代码：

我们看看这个 rule 是谁：

这里的 rule 默认值是一个 RoundRobinRule ，看类的介绍：

负载均衡默认使用了轮训算法，当然我们也可以自定义。

流程总结

SpringCloud Ribbon 底层采用了一个拦截器，拦截了 RestTemplate 发出的请求，对地址做了修改。

基本流程如下：

• 拦截我们的 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 有很多不同的实现类：

不同规则的含义如下：

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

 

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

自定义策略

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

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

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

userservice: # 给需要调用的微服务配置负载均衡规则，orderservice服务去调用userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

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

饥饿加载

当我们启动 orderservice，第一次访问时，时间消耗会大很多，这是因为 Ribbon 懒加载的机制。

Ribbon 默认是采用懒加载，即第一次访问时才会去创建 LoadBalanceClient，拉取集群地址，所以请求时间会很长。

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

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