SpringCloud微服务架构 --- 基础篇

一、认识微服务

1.1、服务架构演变

1.1.1、单体架构

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

单体架构的优缺点如下：

优点：

• 架构简单
• 部署成本低

缺点：

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

1.1.2、分布式架构

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

分布式架构的优缺点：

优点：

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

缺点：

• 服务调用关系错综复杂

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

• 服务拆分的粒度如何界定？
• 服务集群地址如何维护？
• 服务之间如何实现远程调用？
• 服务健康状态如何感知？

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

1.1.3、微服务

微服务的架构特征：

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

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

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

但方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试自己的微服务落地方案。

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

1.1.4、总结

单体架构特点？

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

分布式架构特点？

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

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

• 优点：拆分粒度更小、服务更独立、耦合度更低
• 缺点：架构非常复杂，运维、监控、部署难度提高
• SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件

1.2、微服务技术对比

1.2.1、微服务结构

微服务这种方案需要技术框架来落地，全球的互联网公司都在积极尝试自己的微服务落地技术。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。

1.2.2、微服务对比

1.3、SpringCloud

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

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

二、微服务拆分和远程调用

2.1、服务拆分原则

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

2.2、服务拆分示例

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

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

要求：

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

2.2.1、导入Sql语句

2.2.2、导入demo工程

三、Eureka注册中心

3.1、Eureka原理

消费者该如何获取服务提供者具体信息？

• 服务提供者启动时向eureka注册自己的信息
• eureka保存这些信息
• 消费者根据服务名称向eureka拉取提供者信息

如果有多个服务提供者，消费者该如何选择？

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

消费者如何感知服务提供者健康状态？

• 服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
• eureka会更新记录服务列表信息，心跳不正常会被剔除
• 消费者就可以拉取到最新的信息

在Eureka架构中，微服务角色有两类：

• EurekaServer：服务端，注册中心

  • 记录服务信息
  • 心跳监控

• EurekaClient：客户端

  • Provider：服务提供者，例如案例中的 user-service

    • 注册自己的信息到EurekaServer
    • 每隔30秒向EurekaServer发送心跳

  • consumer：服务消费者，例如案例中的 order-service

    • 根据服务名称从EurekaServer拉取服务列表

    • 基于服务列表做负载均衡，选中一个微服务后发起远程调用

Eureka是Netflix开源的一款服务注册与发现框架，用于构建可高可用、可伸缩的微服务架构。它的原理如下：

1. Eureka Server：Eureka的核心组件，负责服务注册和发现。每个微服务都会将自己的信息注册到Eureka Server上，包括服务名称、IP地址、端口号等。

2. Eureka Client：每个微服务都作为Eureka Client运行，负责将自己的信息注册到Eureka Server上，并定时向Server发送心跳来维持注册信息的有效性。

3. 服务注册：当一个微服务启动时，它会向Eureka Server发送注册请求，将自己的信息注册到Eureka Server上。Eureka Server会将这些信息存储在内存中，并提供REST接口供其他微服务查询。

4. 服务发现：当一个微服务需要调用其他微服务时，它可以向Eureka Server发送查询请求，获取需要调用的微服务的信息，包括IP地址和端口号。然后，它可以使用这些信息来进行服务调用。

5. 心跳机制：Eureka Client会定时向Eureka Server发送心跳请求，以保持注册信息的有效性。如果Eureka Server在一定时间内没有收到某个微服务的心跳请求，它会将该微服务从注册列表中移除。

6. 高可用性：Eureka Server可以通过集群部署来实现高可用性。多个Eureka Server之间会相互注册，形成一个互相备份的集群。当其中一个Eureka Server宕机时，其他Eureka Server可以接管其职责，保证服务的可用性。

Eureka服务注册与发现的原理基于C-S架构，通过心跳机制和服务列表的维护，实现了服务的自动注册、续约和发现。这种机制保证了服务的高可用性和可扩展性，是微服务架构中常用的服务注册与发现解决方案之一。

通过 Eureka 服务注册与发现，微服务之间可以更加灵活、动态地相互通信，降低了服务之间的耦合性，提高了系统的可伸缩性和弹性。

3.2、搭建EurekaServer

3.2.1、创建eureka-server服务

3.2.2、引入eureka依赖

引入SpringCloud为eureka提供的starter依赖：

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

3.2.3、编写启动类

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

package cn.test.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);
    }
}

3.2.4、编写配置文件

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

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

3.2.5、启动服务

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

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

3.3、服务注册

3.3.1、引入依赖

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

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

3.3.2、配置文件

在user-service中，修改application.yml文件，添加服务名称、eureka地址：

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

3.3.3、启动多个user-service实例

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

3.4、服务发现

3.4.1、引入依赖

之前说过，服务发现、服务注册统一都封装在eureka-client依赖，因此这一步与服务注册时一致。

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

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

3.4.2、配置文件

服务发现也需要知道eureka地址，因此第二步与服务注册一致，都是配置eureka信息：

在order-service中，修改application.yml文件，添加服务名称、eureka地址：

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

3.4.3、服务拉取和负载均衡

最后，我们要去eureka-server中拉取user-service服务的实例列表，并且实现负载均衡。

不过这些动作不用我们去做，只需要添加一些注解即可。

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

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

3.5、总结

搭建EurekaServer

• 引入eureka-server依赖

• 添加@EnableEurekaServer注解

• 在application.yml中配置eureka地址

服务注册

• 引入eureka-client依赖

• 在application.yml中配置eureka地址

服务发现

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

四、Ribbon负载均衡原理

4.1、负载均衡原理

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

Ribbon是Netflix开源的客户端负载均衡器，可以将客户端请求分发到多个服务实例中。它的工作原理如下：

• 服务实例获取：Ribbon通过配置文件或自定义规则获取所有可用的服务实例列表。这些服务实例可能是通过服务注册中心（如Eureka）发现的，也可能是通过静态配置指定的。
• 请求处理：当客户端发起请求时，Ribbon会根据负载均衡算法从服务实例列表中选择一个目标服务实例。Ribbon支持多种负载均衡算法，包括轮询、随机、加权轮询、加权随机等。这些算法可以根据实际需求来选择，以实现负载均衡和服务实例的可用性。
• 请求发送：Ribbon将客户端请求发送给所选的服务实例，并在请求完成后获取响应。如果请求失败（例如，由于网络问题或服务实例故障），Ribbon会自动尝试选择另一个可用的服务实例进行重试。这个过程可以通过配置重试策略来控制，例如设置重试次数和重试间隔等。
• 服务发现与路由：Ribbon还提供了服务发现和路由功能。它可以与服务注册中心集成，动态获取服务实例列表，并根据路由规则将请求路由到特定的服务实例。这使得Ribbon能够灵活地处理服务实例的增删改查，并保证请求的正确路由。

综上所述，Ribbon的负载均衡原理是通过获取服务实例列表、选择目标服务实例、发送请求并处理响应等步骤来实现的。它提供了多种负载均衡算法和服务发现与路由功能，以确保客户端请求能够均衡地分发到多个服务实例中，从而提高系统的可用性和性能。

4.2、源码跟踪

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。

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

我们进行源码跟踪：

4.2.1、LoadBalancerIntercepor

可以看到这里的intercept方法，拦截了用户的HttpRequest请求，然后做了几件事：

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

这里的this.loadBalancer是LoadBalancerClient类型，我们继续跟入。

4.2.2、LoadBalancerClient

继续跟入execute方法：

代码是这样的：

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

放行后，再次访问并跟踪，发现获取的是8081：

果然实现了负载均衡。

4.2.3、负载均衡策略IRule

在刚才的代码中，可以看到获取服务使通过一个getServer方法来做负载均衡:

我们继续跟入：

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

我们看看这个rule是谁：

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

这不就是轮询的意思嘛。

到这里，整个负载均衡的流程我们就清楚了。

4.2.4、总结

SpringCloudRibbon的底层采用了一个拦截器，拦截了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，发起真实请求

Ribbon是Netflix发布的一个开源项目，主要用于提供客户端的软件负载均衡算法和服务调用。Ribbon的核心组件包括ILoadBalancer、IRule和IPing，其中ILoadBalancer是负载均衡器的主要接口，它提供了选择服务器（Server）的功能，而IRule则根据不同的负载均衡策略选择合适的Server返回给使用者。

Ribbon的执行原理可以简单概括为以下几个步骤：

• 在配置文件中列出Load Balancer（简称LB）后面所有的机器。
• Ribbon会基于某种规则（如简单轮询、随机连接等）自动地帮助客户端去连接这些机器。
• 客户端通过Ribbon提供的RestTemplate来调用服务，Ribbon会给RestTemplate添加一个@LoadBalanced标注，以实现负载均衡。
• Ribbon通过ILoadBalancer接口对外提供统一的选择服务器(Server)的功能，此接口会根据不同的负载均衡策略(IRule)选择合适的Server返回给使用者。

Ribbon的负载均衡策略可以通过配置文件进行配置，也可以通过代码实现自定义的负载均衡策略。常见的负载均衡策略包括简单轮询、随机连接、最少活跃调用数等。

Ribbon作为负载均衡器在分布式网络中扮演着非常重要的角色，它通过将网络流量（负载）分摊到不同的网络服务器，实现了服务的水平横向扩展，提高了系统的可用性和可扩展性。同时，Ribbon还提供了完善的配置项，如连接超时、重试等，方便用户进行定制和优化。

4.3、负载均衡策略

4.3.1、负载均衡策略

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

不同规则的含义如下：

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

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

4.3.2、自定义负载均衡策略

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

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 # 负载均衡规则 

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

4.4、懒加载

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

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

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

4.5、总结

Ribbon负载均衡规则

• 规则接口是IRule

• 默认实现是ZoneAvoidanceRule，根据zone选择服务列表，然后轮询

负载均衡自定义方式

• 代码方式：配置灵活，但修改时需要重新打包发布

• 配置方式：直观，方便，无需重新打包发布，但是无法做全局配置

饥饿加载

• 开启饥饿加载

• 指定饥饿加载的微服务名称

五、Nacose注册中心

5.1、认识和安装Nacos

5.1.1、Windows安装

5.1.1.1、下载安装包

在Nacos的GitHub页面，提供有下载链接，可以下载编译好的Nacos服务端或者源代码：

GitHub主页：https://github.com/alibaba/nacos

GitHub的Release下载页：https://github.com/alibaba/nacos/releases

如图：

5.1.1.2、解压

将这个包解压到任意非中文目录下，如图：

目录说明：

• bin：启动脚本
• conf：配置文件

5.1.1.3、端口配置

Nacos的默认端口是8848，如果你电脑上的其它进程占用了8848端口，请先尝试关闭该进程。

如果无法关闭占用8848端口的进程，也可以进入nacos的conf目录，修改配置文件中的端口：

5.1.1.4、启动

启动非常简单，进入bin目录，结构如下：

然后执行命令即可：

• windows命令：

  startup.cmd -m standalone
  

执行后的效果如图：

5.1.1.5、访问

在浏览器输入地址：http://127.0.0.1:8848/nacos即可：

默认的账号和密码都是nacos，进入后：

5.1.2、Linux安装

5.1.2.1、安装JDK

Nacos依赖于JDK运行，索引Linux上也需要安装JDK才行。

上传jdk安装包：

上传到某个目录，例如：/usr/local/

然后解压缩：

tar -xvf jdk-8u144-linux-x64.tar.gz

然后重命名为java

配置环境变量：

export JAVA_HOME=/usr/local/java
export PATH=$PATH:$JAVA_HOME/bin

设置环境变量：

source /etc/profile

5.1.2.2、上传安装包

如图：

上传到Linux服务器的某个目录，例如/usr/local/src目录下：

5.1.2.3、解压

命令解压缩安装包：

tar -xvf nacos-server-1.4.1.tar.gz

然后删除安装包：

rm -rf nacos-server-1.4.1.tar.gz

目录中最终样式：

目录内部：

5.1.2.4、端口配置

与windows中类似

5.1.2.5、启动

在nacos/bin目录中，输入命令启动Nacos：

sh startup.sh -m standalone

5.2、Nacos快速入门

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

主要差异在于：

• 依赖不同
• 服务地址不同

5.2.1、引入依赖

在cloud-demo父工程的pom文件中的<dependencyManagement>中引入SpringCloudAlibaba的依赖：

<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>

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

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

注意：不要忘了注释掉eureka的依赖。

5.2.2、配置nacos地址

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

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

注意：不要忘了注释掉eureka的地址

5.2.3、重启

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

总结：

Nacos服务搭建

• 下载安装包
• 解压
• 在bin目录下运行指令：startup.cmd -m standalone

Nacos服务注册或发现

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

5.3、Nacos服务分级存储模型

一个服务可以有多个实例，例如我们的user-service，可以有:

• 127.0.0.1:8081
• 127.0.0.1:8082
• 127.0.0.1:8083

假如这些实例分布于全国各地的不同机房，例如：

• 127.0.0.1:8081，在上海机房
• 127.0.0.1:8082，在上海机房
• 127.0.0.1:8083，在杭州机房

Nacos就将同一机房内的实例 划分为一个集群。

也就是说，user-service是服务，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型，如图：

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