01-35-springcloud-zk-eureka-consul-cap-父工程

01-springcloud-入门理论等：

微服务

1、什么是微服务

• 微服务是一种架构风格
• 一个应用拆分为一组小型服务
• 每个服务运行在自己的进程内，也就是可独立部署和升级
• 服务之间使用轻量级HTTP交互
• 服务围绕业务功能拆分
• 可以由全自动部署机制独立部署
• 去中心化，服务自治。服务可以使用不同的语言、不同的存储技术

2、分布式微服务架构-落地维度

服务调用，服务降级，服务注册与发现，服务熔断，负载均衡，服务消息队列，服务网关，配置中心管理，自动化构建部署，服务监控，全链路追踪，服务定时任务，调度操作

SpringCloud=分布式微服务架构的站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶

Spring Cloud技术栈

3、springboot和springcloud选型

• Spring Boot 2.X 版

  源码地址：https://github.com/spring-projects/spring-boot/releases/

  Spring Boot 2 的新特性：https://github.com/spring-projects/spring-boot/wiki/spring-Boot-2.0-Release-Notes

  通过上面官网发现，Boot官方强烈建议你升级到2.X以上版本

• Spring Cloud H版

  源码地址：https://github.com/spring-projects/spring-cloud

  官网：https://spring.io/projects/spring-cloud

• Spring Boot 与 Spring Cloud 兼容性查看

  文档：https://spring.io/projects/spring-cloud#adding-spring-cloud-to-an-existing-spring-boot-application

  JSON接口：https://start.spring.io/actuator/info

后续使用到的技术版本，参考尚硅谷教程

maven地址:为了确保后期不出问题，暂和尚硅谷教程版本一致。

https://blog.csdn.net/swadian2008/article/details/113530102

https://archive.apache.org/dist/maven/maven-3/3.5.2/binaries/

• Cloud - Hoxton.SR1
• Boot - 2.2.2.RELEASE
• Cloud Alibaba - 2.1.0.RELEASE
• Java - Java 8
• Maven - 3.5及以上
• MySQL - 5.7及以上

父工程的创建

约定 > 配置 > 编码

1、创建聚合父工程8步

1、New Project - maven工程 - create from archetype: maven-archetype-site
2、聚合总父工程名字
3、Maven选版本
4、工程名字
5、字符编码 - Settings - File encoding
6、注解生效激活 - Settings - Annotation Processors
7、Java编译版本选8
8、File Type过滤 - Settings - File Type

git地址：XXXXXXXXXXXX或者参考https://blog.csdn.net/u011863024/article/details/114298270

2、DependencyManagement和Dependencies

dependencyManagement：管理依赖版本号，只是声明依赖，并不实现引入

Dependencies：子项目声明找父类版本号，父类没有，使用子项目具体版本。只有在子项目中写了该依赖项,并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom。

3、初步模块创建

简写创建，详情参考git或者尚硅谷视频教程

1）、支付模块构建：

建Module，改POM，写YML，主启动，业务类（cloud-provider-payment8001）

构建表，实体对象，mapper等

工程重构（cloud-api-commons）

Eureka基础知识

1、什么是服务治理

一句话：对多个服务的管理。管理包含调用，负载，容错，注册发现。

Spring Cloud封装了Netflix 公司开发的Eureka模块来实现服务治理，在传统的RPC远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务于服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册。

2、什么是服务注册与发现

Eureka采用了CS的设计架构，Eureka Sever作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用Eureka的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行。

在服务注册与发现中，有一个注册中心。当服务器启动的时候，会把当前自己服务器的信息比如服务地址通讯地址等以别名方式注册到注册中心上。另一方(消费者服务提供者)，以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地RPC调用RPC远程调用框架核心设计思想:在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系(服务治理概念)。在任何RPC远程框架中，都会有一个注册中心存放服务地址相关信息(接口地址)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uD8K9am8-1670856750201)(png/image-20220411220714456.png)]

3、Eureka两个组件

Eureka Server提供服务注册服务

各个微服务节点通过配置启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观看到。

EurekaClient通过注册中心进行访问

它是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒)

4、EurekaServer服务端安装

git（cloud-eureka-server7001） cloud-provider-payment8001 cloud-consumer-order80

5、EureKa集群

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YLqGB33Z-1670856750202)(png/image-20220411221110020.png)]

服务注册：将服务信息注册进注册中心

服务发现：从注册中心上获取服务信息

实质：存key服务命取value闭用地址

1、先启动eureka注主册中心

2、启动服务提供者payment支付服务

3、支付服务启动后会把自身信息(比服务地址L以别名方式注朋进eureka

4、消费者order服务在需要调用接口时，使用服务别名去注册中心获取实际的RPC远程调用地址

5、消去者导调用地址后，底屋实际是利用HttpClient技术实现远程调用

6、消费者实癸导服务地址后会缓存在本地jvm内存中，默认每间隔30秒更新—次服务调用地址

问题:微服务RPC远程服务调用最核心的是什么
高可用，试想你的注册中心只有一个only one，万一它出故障了，会导致整个为服务环境不可用。

解决办法：搭建Eureka注册中心集群，实现负载均衡+故障容错。互相注册，相互守望。

集群搭建测试

cloud-eureka-server7002 cloud-provicer-payment8001 cloud-provicer-payment8002

• 找到C:\Windows\System32\drivers\etc路径下的hosts文件，修改映射配置添加进hosts文件

127.0.0.1 eureka7001.com
127.0.0.1 eureka7002.com

• 修改cloud-eureka-server7001配置文件，互相配置

6、actuator微服务信息完善

主机名称：服务名称修改（也就是将IP地址，换成可读性高的名字）

修改cloud-provider-payment8001，cloud-provider-payment8002

修改部分 - YML - eureka.instance.instance-id

修改部分 - YML - eureka.instance.prefer-ip-address，访问信息有IP信息提示

7、服务发现Discovery

• 修改cloud-provider-payment8001的Controller

8、EureKa自我保护理论（重要）

一句话：CAP（AP），保证不会因为网络原因对微服务立刻清理。好死不如赖活着

保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据，也就是不会注销任何微服务。

如果在Eureka Server的首页看到以下这段提示，则说明Eureka进入了保护模式:

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THANTHRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUSTTO BE SAFE

导致原因

一句话：某时刻某一个微服务不可用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存。属于CAP里面的AP分支。
为什么会产生Eureka自我保护机制?

为了EurekaClient可以正常运行，防止与EurekaServer网络不通情况下，EurekaServer不会立刻将EurekaClient服务剔除

什么是自我保护模式?

默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例(默认90秒)。但是当网络分区故障发生(延时、卡顿、拥挤)时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时(可能发生了网络分区故障)，那么这个节点就会进入自我保护模式。

自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留）也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。

禁止自我保护：eureka.server.enable-self-preservation = false可以禁用自我保护模式

zookeeper

zookeeper是一个分布式协调工具，可以实现注册中心功能。关联zookeeper相关。

https://gitee.com/HaoZhouRS/study-notes/tree/master/notes/zookeeper

cloud-provider-payment8004，cloud-consumerzk-order80

consul

Consul官网：https://www.consul.io/

Consul下载地址：https://www.consul.io/downloads

Consul是一套开源的分布式服务发现和配置管理系统。提供了微服务系统中的服务治理、配置中心、控制总线等功能。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网格，总之Consul提供了一种完整的服务网格解决方案。

• 服务发现 - 提供HTTP和DNS两种发现方式。
• 健康监测 - 支持多种方式，HTTP、TCP、Docker、Shell脚本定制化
• KV存储 - Key、Value的存储方式
• 多数据中心 - Consul支持多数据中心
• 可视化Web界面

https://www.springcloud.cc/spring-cloud-consul.html

cloud-providerconsul-payment8006，cloud-consumerconsul-order80，

CAP

组件名	语言CAP	服务健康检查	对外暴露接口	Spring Cloud集成
Eureka	Java	AP	可配支持	HTTP
Consul	Go	CP	支持	HTTP/DNS
Zookeeper	Java	CP	支持客户端	已集成

CAP：

• C：Consistency (强一致性)
• A：Availability (可用性)
• P：Partition tolerance （分区容错性)

最多只能同时较好的满足两个。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求。

因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类:

CA - 单点集群，满足—致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

1、AP架构（Eureka）

当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。

结论：违背了一致性C的要求，只满足可用性和分区容错，即AP

2、CP架构（ZooKeeper/Consul）

当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性。

结论：违背了可用性A的要求，只满足一致性和分区容错，即CP

学习路径：https://space.bilibili.com/302417610/，如有侵权，请联系q进行删除：3623472230