Spring Cloud 五大组件
服务注册与发现——Netflix Eureka
负载均衡：
客户端负载均衡——Netflix Ribbon
服务端负载均衡：——Feign(其也是依赖于Ribbon，只是将调用方式RestTemplete 更改成Service 接口)
断路器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config
概念：SpringCloud 不是一门技术而是一门生态
微服务架构4个核心问题？
- 服务很多，客户端怎么访问
- 这么多服务，服务之间如何通信
- 这么多服务，如何治理
- 服务挂了怎么办
万变不离其宗
- 访问方式：API网关
- 通信方式：HTTP,RPC
- 治理方式：注册和发现
- 熔断机制
总而为了解决网络不可靠的问题！
常见面试题1.1 什么是微服务？
1.2 微服务之间是如何独立通讯的？
1.3 SpringCloud 和 Dubbo有那些区别？
1.4 SpringBoot 和 SpringCloud，请谈谈你对他们的理解
1.5 什么是服务熔断？什么是服务降级？
1.6 微服务的优缺点分别是什么？说下你在项目开发中遇到的坑
1.7 你所知道的微服务技术栈有哪些？列举一二
1.8 Eureka和Zookeeper都可以提供服务注册与发现的功能，请说说两者的区别
…
1.1什么是微服务？微服务
微服务就是将一个服务化为多个功能单一的微服务
微服务架构
微服务架构是一种架构模式，是把一个单一应用程序划分成一组小的服务，服务之间相互协调、相互配合，为用户提供最终价值
1.2微服务之间是如何独立通讯的每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制(如HTTP)互相协作，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中
1.3 SpringCloud 和 Dubbo有那些区别？SpringCloud就像一个品牌机，Dubbo就像一个组装机
Dubbo是一个RPC框架，而SpringCloud的目标是微服务架构下的一站式解决方案。
| Dubbo | SpringCloud | |
|---|---|---|
| 服务注册中心 | Zookeeper | Spring Cloud Netfilx Eureka |
| 服务调用方式 | RPC | REST API |
| 服务监控 | Dubbo-monitor | Spring Boot Admin |
| 断路器 | 不完善 | Spring Cloud Netfilx Hystrix |
| 服务网关 | 无 | Spring Cloud Netfilx Zuul |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无 | Spring Cloud Sleuth |
| 消息总栈 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量任务 | 无 | Spring Cloud Task |
| 最大区别：Spring Cloud 抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式 |
SpringBoot可以独立使用，SpringCloud依赖于SpringBoot使用
SpringBoot用来开发构建各个微服务，SpringCloud用来维护各个微服务的使用，关注全局的微服务协调整理治理框架
| 微服务技术条目 | 落地技术 |
|---|---|
| 服务开发 | SpringBoot、Spring、SpringMVC等 |
| 服务配置与管理 | Netfix公司的Archaius、阿里的Diamond等 |
| 服务注册与发现 | Eureka、Consul、Zookeeper等 |
| 服务调用 | Rest、PRC、gRPC |
| 服务熔断器 | Hystrix、Envoy等 |
| 负载均衡 | Ribbon、Nginx等 |
| 服务接口调用(客户端调用服务的简化工具) | Fegin等 |
| 消息队列 | Kafka、RabbitMQ、ActiveMQ等 |
| 服务配置中心管理 | SpringCloudConfig、Chef等 |
| 服务路由(API网关) | Zuul等 |
| 服务监控 | Zabbix、Nagios、Metrics、Specatator等 |
| 全链路追踪 | Zipkin、Brave、Dapper等 |
| 数据流操作开发包 | SpringCloud Stream(封装与Redis，Rabbit，Kafka等发送接收消息) |
| 时间消息总栈 | SpringCloud Bus |
| 服务部署 | Docker、OpenStack、Kubernetes等 |
创建两个模块分别为服务提供者和服务消费者，根据mvc模式进行设置，
自行设计数据库，实现消费者可以利用restTemplate来调用提供者的服务而只要写控制器层，不需要写service层
服务提供者安装依赖
springboot-test
spring-web
spring-devtools
mysql+druid
mybatis
日志框架
junit测试
拿到实体类
服务消费者依赖
实体类
热部署
spring-web
实体类依赖
lombok
Eureka是基于REST的服务，用于定位服务，以实现云端中间件层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务注册与发现，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于Dubbo的注册中心，比如Zookeeper.
- 导入Eureka-Server依赖
- 写配置文件 写eureka配置[写端口号，写服务器实例名称，将自己设置为注册中心以免被注册进去，设置注册地址]
server:
port: 7001
#Eureka配置
eureka:
instance:
hostname: localhost #Eureka服务端的实例名称
client:
register-with-eureka: false #表示是否向eureka注册中心注册自己
fetch-registry: false # fetch-registry 如果为false,则表示自己为注册中心
service-url: # 注册地址，把东西注入进去的地址
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
- 写启动类，@EnableEurekaServer，使其可以使用
EureKa自我保护机制：好死不如赖活着
一句话总结就是：某时刻某一个微服务不可用，eureka不会立即清理，依旧会对该微服务的信息进行保存！
默认情况下，当eureka server在一定时间内没有收到实例的心跳，便会把该实例从注册表中删除（默认是90秒），但是，如果短时间内丢失大量的实例心跳，便会触发eureka server的自我保护机制，比如在开发测试时，需要频繁地重启微服务实例，但是我们很少会把eureka server一起重启（因为在开发过程中不会修改eureka注册中心）
但是我们在开发测试阶段，需要频繁地重启发布，如果触发了保护机制，则旧的服务实例没有被删除，这时请求有可能跑到旧的实例中，而该实例已经关闭了，这就导致请求错误，影响开发测试。所以，在开发测试阶段，我们可以把自我保护模式关闭，只需在eureka server配置文件中加上如下配置即可：eureka.server.enable-self-preservation=false【不推荐关闭自我保护机制】
详细内容可以参考下这篇博客内容：https://blog.csdn.net/wudiyong22/article/details/80827594
注册进来的微服务，获取一些消息（团队开发会用到）
在提供服务模块进行操作- 导入依赖Eureka,actuator完善监控信息
- 编写配置在已经配置了mybatis和spring的情况下，加入Eureka配置【需要注册到的地址】
server:
port: 8001
#mybatis配置
mybatis:
type-aliases-package: com.lqc.springcloud.pojo
config-location: classpath:mybatis/mybatis-config.xml
mapper-locations: classpath:mybatis/mapper/*.xml
#spring的配置
spring:
application:
name: springcloud-provider-dept
datasource:
type: com.alibaba.druid.pool.DruidDataSource
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/db01?useUnicode=true&characterEncoding=utf-8
username: root
password: 123456
#Eureka的配置，服务注册到哪里
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka/
instance:
instance-id: springcloud-provider-dept8001 # 修改eureka上的默认描述信息
info:
app.name: springcloud-service-news
company.name: www.mark.com
#使info可以进入
management:
endpoints:
web:
exposure:
include: "*"
- 在启动类上@EnableEurekaClient使其配置生效
- 该微服务进入注册中心后，还进行了三个操作
4.1. 修改eureka上的默认描述信息
在上面的配置文件中已经实现了该项功能
4.2. 当点击默认描述信息进入localhost：8001/actuator/info路径后显示信息
该方法虽然没有什么用，但是自己在这出现了一些错误，根据下面的文章进行了解决
https://blog.csdn.net/weixin_45429941/article/details/123809342?spm=1001.2101.3001.6650.3&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-3-123809342-blog-120977943.pc_relevant_antiscanv2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-3-123809342-blog-120977943.pc_relevant_antiscanv2&utm_relevant_index=6
4.3.当进入自己设置的路径后可以显示当前全部微服务信息和指定微服务信息
自行设置一个控制器，进行信息的输出@Autowired DiscoveryClient client; //注册进来的微服务~获取一些信息~ @GetMapping("/dept/discovery") public Object discovery(){ //获取微服务列表的清单 Listservices = client.getServices(); System.out.println("discovery=>services:"+services); //得到一个具体的微服务信息，通过具体的微服务id,applicatiobName List instances = client.getInstances("SPRINGCLOUD-PROVIDER-DEPT"); for (ServiceInstance instance : instances) { System.out.println( instance.getHost()+"t"+ instance.getPort()+"t"+ instance.getUri()+"t"+ instance.getServiceId() ); } return this.client; }
注意如果没有信息跳出就刷新一下页面，可能是因为没有注册进去
DiscoveryClient类型很多这里选择使用spring类型的
之前配置的是单机版Eureka，这个时候Eureka服务挂了的话，那么我们的服务提供者跟服务消费者岂不是都废了？那这个程序还有存在的意义么？
那么今天咱们就讲一讲如何解决这个问题。相信大家都知道，这个问题是我们提供高可用服务必须经历的问题。解决方案就是加集群，那么我们来看一下Eureka怎么实现集群吧。
Eureka对比和Zookeeper区别- 回顾CAP原则
RDBMS (MySQLOraclesqlServer) ===> ACID
NoSQL (RedisMongoDB) ===> CAP
-
ACID是什么？
A (Atomicity) 原子性
C (Consistency) 一致性
I (Isolation) 隔离性
D (Durability) 持久性 -
CAP是什么?
C (Consistency) 强一致性
A (Availability) 可用性
P (Partition tolerance) 分区容错性
CAP的三进二：CA、AP、CP -
CAP理论的核心
一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求
根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类
CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
CP：满足一致性，分区容错的系统，通常性能不是特别高
AP：满足可用性，分区容错的系统，通常可能对一致性要求低一些
5. 作为分布式服务注册中心，Eureka比Zookeeper好在哪里？
著名的CAP理论指出，一个分布式系统不可能同时满足C (一致性) 、A (可用性) 、P (容错性)，由于分区容错性P再分布式系统中是必须要保证的，因此我们只能再A和C之间进行权衡。
Zookeeper 保证的是 CP —> 满足一致性，分区容错的系统，通常性能不是特别高
Eureka 保证的是 AP —> 满足可用性，分区容错的系统，通常可能对一致性要求低一些
Zookeeper保证的是CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接收服务直接down掉不可用。也就是说，服务注册功能对一致性的要求要高于可用性。但zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30-120s，且选举期间整个zookeeper集群是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zookeeper集群失去master节点是较大概率发生的事件，虽然服务最终能够恢复，但是，漫长的选举时间导致注册长期不可用，是不可容忍的。
Eureka保证的是AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有之中自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)
当网络稳定时，当前实例新的注册信息会被同步到其他节点中
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪
作用：负载均衡
操作步骤：
加依赖
写配置写方法 注意要放在文件外面
在启动类写注解，使其可以使用
// 在微服务启动的时候就能去加载我们自定义的Ribbon类 @RibbonClient(name = "SPRINGCLOUD-PROVIDER-DEPT",configuration = LRule.class)Feign：负载均衡(基于服务端)
Feign是声明式Web Service客户端，它让微服务之间的调用变得更简单，类似controller调用service。SpringCloud集成了Ribbon和Eureka，可以使用Feigin提供负载均衡的http客户端
只需要创建一个接口，然后添加注解即可~
Feign，主要是社区版，大家都习惯面向接口编程。这个是很多开发人员的规范。
Hystrix：服务熔断Hystrix是一个应用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix 能够保证在一个依赖出问题的情况下，不会导致整个体系服务失败，避免级联故障，以提高分布式系统的弹性。
“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控 (类似熔断保险丝) ，向调用方返回一个服务预期的，可处理的备选响应 (FallBack) ，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
Hystrix：服务降级 Hystrix：Dashboard流监控 Zuul：路由网关Zull包含了对请求的路由(用来跳转的)和过滤两个最主要功能：
其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。
Config：集中配置spring cloud config 分为服务端和客户端两部分。
服务端也称为 分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密，解密信息等访问接口。
客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理。并且可用通过git客户端工具来方便的管理和访问配置内容。
–学习内容来自狂神说JAVA
参考笔记：https://www.kuangstudy.com/bbs/1374942542566551554
