微服务，Spring Cloud 和 Eureka：服务发现工具 - 教程

目录

零、分布式架构

0.1 优点

0.2 缺点

0.3 使用场景

一、分布式架构——微服务架构

1.1 微服务的特点

1.2 微服务架构图

1.3 分布式和集群的区别

二、微服务架构常见实现框架

2.1 微服务架构主流实现框架

三、Spring Cloud

3.1 SpringCloud简介

四、Spring Cloud 版本号说明

4.1 常见版本

4.2 Spring Cloud版本

五、Eureka介绍

5.1 什么是Eureka

5.2 包含注册中心的软件架构图

5.3 Eureka角色

5.3.1 Eureka Server

5.3.2 Eureka Client

        5.3.2-1 Application Service

        5.3.2-2 Application Client

六、搭建单机版 Eureka 服务器

6.1 创建 Maven 项目( eurekaServer02 ) -- 不选模板或者选 java 项目，添加依赖

6.2 编写应用配置文件 application.yml

6.3 编写启动类，添加 Eureka 服务器端的注解

6.4 访问 Eureka 的平台页面：

七、 搭建 Eureka 客户端

7.1 创建新 Maven 项目( EurekaClient02 )，添加依赖

7.2 编写 application.yml

7.3 在 com.jr 包下创建启动类( SpringBootMain )，添加 Eureka 客户端注解

7.4 启动项目

八、 Eureka Server 集群原理

8.1 Eureka Client 与 Eureka Server 的交互

8.2 多区域与高可用

8.3 服务间调用

九、Eureka Server 自我保护机制

十、Spring Boot 应用优雅关闭

10.1 添加 pom 依赖，刷新 Maven

10.2 编写应用配置文件 application.yml

10.3 编写启动类

10.4 测试

十一、CAP定理

---

零、分布式架构

0.1 优点

• 增大了系统可用性。减少单点故障，导致整个应用不可用。
• 增加重用性。因为模块化，所以重用性更高。
• 增加可扩展性。有新的模块增加新的项目即可。
• 增加每个模块的负载能力。因为每个模块都是一个项目，所以每个模块的负载能力更强。

0.2 缺点

• 开发成本更高。
• 架构更加复杂。
• 整体响应时间变长，一些业务需要多项目通信后给出结果。

0.3 使用场景

        中大型企业管理类项目、互联网项目等。

一、分布式架构——微服务架构

  微服务架构是分布式架构中的一种。

        微服务（MicroService）的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计（微服务一个业务一个项目），以全自动方式部署，与其他服务使用特性的通讯协议（如：HTTP或RPC等）（每个项目都是一个标准的web项目）。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。

        微服务的核心在于：

1. 微服务是分布式架构的一种。发展到现在微服务已经可以说是综合平台（架构以外还包含服务治理、注册中心、服务容灾等相关特性）。
2. 微服务架构中每个Web项目都称为服务。
3. 微服务拆分颗粒度为业务。
4. 微服务中服务和服务之间使用特定协议通信（如：HTTP、PRC）。
5. 微服务和Docker结合使用更方便。

1.1 微服务的特点

        微服务的特点：针对特定服务发布，影响小，风险小，成本低；频繁发布版本，快速交付需求；低成本扩容，弹性伸缩，适应云环境等特点。微服务架构与现在企业中敏捷开发思想是匹配的，核心都是强调希望项目快速更新迭代。

        在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了如下问题：分布式系统的复杂性；部署，测试和监控的成本问题；分布式事务和CAP的相关问题等。微服务架构相对于单体架构还需要处理很多事情。例如：分布式事务、团队合作等问题都需要明确的提前设计好。

1.2 微服务架构图

1.3 分布式和集群的区别

1. 分布式：一种软件架构。把一个项目拆分成多个项目，每个拆分后的项目部署到不同的服务器上。
2. 集群：把同一个软件部署多次，每个软件部署到不同的服务器上，让这些软件共同完成相同的事情。  
3. 如果把集群中所有软件都安装到一台服务器上，此时称为伪集群。

二、微服务架构常见实现框架

2.1 微服务架构主流实现框架

当前市场主流的微服务实现框架就是：Spring Cloud。目前包含三大体系，分别是：

1. Spring Cloud Netflix ： 目前市场上使用最多的。也是本阶段学习的主体内容。

   Netflix(Nasdaq NFLX) 成立于1997年，是一家在线影片租赁提供商，主要提供Netflix超大数量的DVD并免费递送，总部位于美国加利福尼亚州洛斯盖图

2. Spring Cloud Alibaba：基于Dubbo的微服务架构体系实现。

3. Spring 其他：为了摆脱受Netflix公司限制，逐渐推出一套组件

三、Spring Cloud

3.1 SpringCloud简介

        Spring Cloud 是一系列框架的有序集合。它是基于 Spring Boot 框架提供的分布式技术实现。其有效的简化了分布式系统中各组件的开发复杂度，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud 并没有重复制造轮子，它只是将各家公司（如Netflix、Alibaba）开发的比较成熟、经得起实际考验的服务框架组合起来，通过 Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。Spring Cloud 可以在任何分布式环境中很好的提供服务，诸如开发者的工作电脑、服务器、云平台等。

四、Spring Cloud 版本号说明

4.1 常见版本

常见版本号格式为： x.y.z.stage

x - 数字格式主版本号，当功能模块有较大更新或者整体架构发生变化时，主版本号会更新。

y - 数字格式次版本号，次版本表示只是局部的一些变动。

z - 数字格式修正版本号，一般是bug的修复或者是小的变动。

stage - 希腊字母版本号，也称为阶段版本号。用于标注当前版本的软件处于哪个开发阶段。常用的阶段版本包括：BASE、ALPHA、BATE、RELEASE/FINAL。

1. BASE - 设计阶段。只有相应的设计没有具体的功能实现。
2. ALPHA - 软件的初级版本。存在较多的bug。
3. BATE - 表示相对 ALPHA 有了很大的进步，消除了严重的 bug，还存在一些潜在的 bug。
4. RELEASE/FINAL - 该版本表示最终版，即正式发布版本。

        开发中，使用的框架版本，最好是RELEASE版本或FINAL版本。

4.2 Spring Cloud版本

        Spring Cloud是一个包含若干子框架的框架集合体，是一个完整的微服务框架体系，如果使用常见版本号来进行标记，容易混淆主框架版本和子框架版本标记。所以Spring Cloud使用一种全新的版本号来对主框架进行版本标记，而子框架的版本标记大多还是使用常用版本号标记的。

        Spring Cloud版本格式如： 版本号命名.stage

        版本号命名：早期 --（英国伦敦地铁站名称）首字母的英文自然升序排列来识别版本的递增：Angle、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich 、Hoxton等。至Hoxton版本发行之后，Spring Cloud开始采用年份命名方式，如2020、2021等

        stage：阶段版本号。常用的阶段版本包括：BUILD-XXX[SNAPSHOT]、GA、PRE(M1、M2等)、RC、SR。

1. BUILD-XXX[SNAPSHOT] - 开发版本、一般是开发团队内部使用。
2. GA - 稳定版，内部开发到一定阶段了，各个模块集成后，经过全面测试发现没有问题，可对外发行了。这个时候叫GA(General Availability)。基本上可以使用了。没有严重的BUG问题，但是有未测出的BUG隐患。不推荐商业使用。
3. PRE - 里程碑版，由于GA还不属于公开发行版，里面还有些功能不完善或者bug，于是就有了milestone（里程碑版）。milestone版主要修复了一些bug。一个GA后，一般会有多个里程本版。例如 M1 M2 M3......。不推荐商业使用。
4. RC - 候选发布版，从BUILD后到GA在到M基本上系统就算定型了，这个时候系统就进入Release Candidate（候选发布版）。该阶段的软件类似于最终发行前的一个观察期，该期间只对一些发现的等级高的bug进行修复。发布RC1 RC2等版本。可以考虑RC版本。
5. SR - 正式发布版，公开正式发布。正式发布版一般也有多个发布，例如 SR1 SR2 SR3等等，一般是用来修复大bug或者优化。最好使用SR版本。至年份版本发布之后，正式发布版一般不做任何后缀标记。

【注意】：Spring Cloud是基于Spring Boot，不同的Spring Cloud要使用不同的Spring Boot版本。

五、Eureka介绍

5.1 什么是Eureka

        Eureka 是由 Netflix 公司推出的服务注册和发现工具（Service Discovery，平时说的注册中心）。现已被 Spring Cloud 集成，提供了开箱即用的支持。

5.2 包含注册中心的软件架构图

5.3 Eureka角色

        Eureka中分为两个角色：Eureka Server（Eureka服务）和 Eureka Client（Eureka客户端）。无论是服务端还是客户端其本质都是一个 Java 项目，在 Spring Cloud 中主要通过启动类上添加  @EnableEurekaServe r 和 @EnableEurekaClient（可以省略）来区分当前应用程序是服务端还是客户端。

5.3.1 Eureka Server

        可以理解成之前我们讲解的 Zookeeper 注册中心，只是现在使用的是 Java 项目实现的（Spring Cloud 内嵌 Eureka）。

5.3.2 Eureka Client

        可以理解成所有需要注册到 Eureka Server 中的应用。为什么需要向注册中心中注册呢？因为注册后别人才能通过注册中心获取到项目信息和项目所在服务器信息，通过这些信息调用这个项目。Spring Cloud 中每个项目调用的信息都存储在了注册中心中（Eureka）。

        5.3.2-1 Application Service

        应用服务端。是 Eureka Client 中的一个相对角色。（没有打错字，就是 Client）

        5.3.2-2 Application Client

        应用客户端。是 Eureka Client 中的一个相对角色。

    在这里，Spring Cloud 中没有绝对的 Application Service 和 Application Client 说法。 

    如果 A 项目访问 B 项目，称A项目为 Application Client，称B项目为 Application Service。

    同时可能存在 C 访问 A 的情况，这时 C 项目是 Application Client，A 项目是 Application Service。

    发现 A 项目又是 Application Service 又是 Application Client，主要看针对哪个业务场景。 

    无论是 Applicatin Service 还是 Application Client 都是 Eureka Client

六、搭建单机版 Eureka 服务器

6.1 创建 Maven 项目( eurekaServer02 ) -- 不选模板或者选 java 项目，添加依赖

        在 pom.xml 添加完刷新 Maven，clean，install

org.springframework.bootspring-boot-starter-parent2.3.12.RELEASE

    org.springframework.cloudspring-cloud-dependenciesHoxton.SR12pomimport

org.springframework.cloudspring-cloud-starter-netflix-eureka-server

6.2 编写应用配置文件 application.yml

在 main 下创建 resources 目录，在该目录下创建 application.yml文件

正确的：

如果长这样 ↓ 

刷新 Maven 项目：方法1：右键项目，下滑到底部点击 Maven，点击 Sync Project 

                               方法2：点击项目右侧的“m”，点击刷新符号，点击 Reload All Maven Projects                               

        编写配置文件：

server:port: 8761
eureka:client:# 因为当前项目为服务，不需要向服务注册自己，默认为trueregister-with-eureka: false# 因为当前为非集群版eureka，所以不需要同步其他节点数据fetch-registry: false
# 当server.port配置不是8761时需要配置内容
#    service-url:
#      defaultZone: http://localhost:${server.port}/eureka/

6.3 编写启动类，添加 Eureka 服务器端的注解

        在 com.jr 包下，创建 SpringBootMain 启动类    

@EnableEurekaServer 注解，表示当前应用开启 Eureka Server 服务注册与发现功能。

@SpringBootApplication
@EnableEurekaServer // 添加 Eureka 服务端 的注解
public class SpringBootMain {public static void main(String[] args) {SpringApplication.run(SpringBootMain.class, args);}
}

6.4 访问 Eureka 的平台页面：

应用启动后，访问 http://IP:8761/ ，进入Eureka管理平台:  127.0.0.1:8761    或者   localhost:8761

        之后主要要看的是这块儿 ↓

        这里给的ip地址是：

看完先不要关闭服务器，后面还要用

七、 搭建 Eureka 客户端

7.1 创建新 Maven 项目( EurekaClient02 )，添加依赖

org.springframework.bootspring-boot-starter-parent2.3.12.RELEASE

org.springframework.cloudspring-cloud-dependenciesHoxton.SR12pomimport

        ↓ 如果有 <dependencies> 标签，就只需要把里面的 <dependency> 标签粘进去就好了

org.springframework.bootspring-boot-starter-weborg.springframework.cloudspring-cloud-starter-netflix-eureka-client

        然后刷新 Maven 

7.2 编写 application.yml

        在 main下创建 resources 目录，在该目录下新建文件 application.yml

# 此处应该定义名称，否则注册到Server后的名字为UNKNOWN
spring:application:name: client1
# 注册中心地址，默认值是http://localhost:8761/eureka/，可省略
#eureka:
#  client:
#    service-url:
#      defaultZone: http://localhost:8761/eureka/

7.3 在 com.jr 包下创建启动类( SpringBootMain )，添加 Eureka 客户端注解

        启动类上的注解 @EnableEurekaClient 代表当前应用是一个 Eureka 客户端，启动后会根据配置信息，把当前应用服务信息注册到 Eureka Server 注册中心。此注解默认生效，是可以省略的。

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

7.4 启动项目

访问 Eureka Server 的可视化界面观察 Client1 是否注册成功。如果注册成功会在页面中显示注册的 client 信息。输入网址：127.0.0.1:8761

启动客户端（ Client ）前前确认服务器（ Server ）在运行中！先运行服务器，再运行客户端

        这里多了一个 CLIENT1 ，就是我们在 application.yml 里设的客户端的名字

        Application： 配置文件中定义的应用程序名称，即服务名字。

        Status：状态。UP - 表示正在执行，smallming - Eureka Client 微服务所在服务器的主机名，eureka-client 定义应用程序名称

八、 Eureka Server 集群原理

官方原理图 —— 核心：服务注册中心（Eureka Server）和服务实例（Eureka Client）

8.1 Eureka Client 与 Eureka Server 的交互

Register（注册）：Application Service 启动时，会通过内置的 Eureka Client 向 Eureka Server 注册，将自身服务信息（如服务名、IP、端口等）上报到注册中心。
Renew（续约）：服务注册后，Eureka Client 会定期（默认 30 秒）向 Eureka Server 发送心跳（续约请求），表明服务 “存活”。若 Eureka Server 长时间未收到续约（默认 90 秒），会将该服务实例标记为 “失效” 并剔除。
Cancel（取消）：Application Service 正常关闭时，Eureka Client 会向 Eureka Server 发送取消请求，主动从注册表中移除自身，避免无效服务被调用。
Get registry（获取注册表）：Application Client 会定期从 Eureka Server 获取最新的服务注册表，缓存到本地，以便在发起远程调用时，能找到可用的服务提供者。

8.2 多区域与高可用

图中 Eureka Server 分布在 us-east-1c、us-east-1d、us-east-1e 不同区域，且相互复制数据，这样做的目的是：

• 实现 高可用：单个 Eureka Server 故障时，其他节点仍能提供服务注册与发现功能。
• 支持 跨区域服务调用：不同区域的 Application Client 和 Application Service，可通过本区域或其他区域的 Eureka Server 进行服务注册与发现，提升系统的容灾能力和扩展性。

8.3 服务间调用

        Application Client 从 Eureka Server 获取服务注册表后，基于注册表中的服务提供者信息（如 IP、端口），发起 Make Remote Call（远程调用），与 Application Service 进行通信，实现服务间的交互。

九、Eureka Server 自我保护机制

在8.1的 renew 里有说：Eureka Client启动后，每隔 30 秒向 Eureka Server 发送一次心跳，证明自己的可用。当 Eureka Server 超过 90 秒没有收到提供者的心跳后，会认为这个提供者已经宕机，销毁实例。

        Eureka 中有一种自我保护机制。当 15 分钟内超过 85% 的 Eureka Client 都没有正常的心跳包时，Eureka 认为 Server 和 Client 之间出现了网络问题。这个时候将不在因为没有收到心跳而销毁实例。Eureka Client 依然可以访问 Server，但是 Server 不会把内容同步到其他 Server 中。当网络稳定后，Server 会把注册的信息同步到其他Server中。

        在Eureka中自我保护机制默认为开启的，关闭方式是，修改配置文件application.yml，增加下述配置：

eureka:server:# 关闭自我保护enable-self-preservation: false# 扫描失效服务的时间间隔eviction-interval-timer-in-ms: 10000

#不建议更改这个两个配置  使用默认的即可
#配置发送心跳时间 默认是30s
eureka.instance.lease-renewal-interval-in-seconds=5
#最长超过多久 删除注册列表 默认是90s
eureka.instance.lease-expiration-duration-in-seconds=5

之后的操作：
重启Eureka服务端项目；
重启Eureka客户端项目；
刷新Eureka平台页面；
关闭Eureka客户端项目；
再次刷新Eureka平台页面；

十、Spring Boot 应用优雅关闭

        Spring Boo t提供的 Actuator（监视器，监控中心）可以实现应用的优雅关闭。Spring Cloud 是基于 Spring Boot 的框架，一样可以依赖 Actuator 来实现微服务应用的优雅关闭。

        （ 直接在 Client 上加

10.1 添加 pom 依赖，刷新 Maven

    org.springframework.bootspring-boot-starter-actuator

10.2 编写应用配置文件 application.yml

        直接在下面添加（顶格，冒号后必须有个空格）

management:endpoints:# 所有功能默认开启enabled-by-default: true# 显示所有已启用功能web:exposure:include: shutdown  # '*' 代表所有

10.3 编写启动类

        上面写过了就不用写了

10.4 测试

        Actuator提供的优雅关闭服务地址是： http://IP:Port/actuator/shutdown （ IP 和 Port 根据自己的进行修改：http://127.0.0.1:8080/actuator/shutdown） 。 必须使用POST请求访问此路径地址！但是我们还没写页面，不能指定 POST 请求，浏览器默认的是 GET 请求。

       ==> 可以使用 Postman 或者 Apipost 进行测试访问！关闭远程服务器的时候，优雅关机非常有必要！

        先启动服务器和客户端

        有 CLIENT1 客户端

        然后在 Postman 或者 Apipost 选择 POST 请求，输入上面的网址

        刷新页面：CLIENT1 客户端没有了

        客户端项目：（不是手动关的）

十一、CAP定理

        CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。 由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。

1. C（ 一致性Consistency ）：在分布式系统中，是否立即达到数据同步的效果（平时多说的强一致性）。在分布式系统一定最终会一致的。如果请求时，整个分布式系统同步后才返回结果，叫做强一致性（满足一致性）。如果先返回结果，在一定时间后才实现一致性就叫做弱一致性。

2. A（ 可用性Availability ）：在分布式系统中，保证每个请求不管成功或者失败都有响应。

3. P（ 分区容错性 ）：在分布式系统中， 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务，是否可以在有限的时间内达到数据一致的效果，如果因为网络等问题最终没有达到一致性，这时称为出现分区错误。

        Eureka 是符合 AP 原则的。

        在 Eureka 集群中所有的节点都是保存完整的信息的，当 Eureka Client 向 Eureka 中注册信息时，如果发现节点不可用，会自动切换到另一台 Eureka Server，也就是说整个集群中即使只有一个 Eureka 可用，那么整个集群也是可用的。同时Eureka的自我保护机制也是可用性非常重要的体现。