springCloud学习笔记(一)--服务注册与发现

一、Eureka服务注册与发现

eureka[已经停更]   zookeeper   consul   nacos

1.1 Eureka基础知识

1.1.1 什么是服务治理?

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

1.1.2 什么是服务注册

Eureka采用了CS的设计架构，Eureka Sever作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用Eureka的客户端连接到Eureka Sever并维持跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行.
在服务注册与发现中，有一个注册中心。当服务器启动的时候，会把当前自己服务嚣的信息比如服务地址通讯地址等以别名方式注册到注册中心上。另一方(消费者|服务提供者)，以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地RPC调用RPC远程调用框架核心设计思想:在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系(服务治理概念)。在任何rpc远程框架中，都会有一个注册中心(存放服务地址相关信息(接口地址)

1.1.3 Eureka两组件

Eureka包含两个组件:Eureka Server和Eureka Client
Eureka Server提供服务注册服务[物业公司]
各个微服务节点通过配置启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观看到。
EurekaClient通过注册中心进行访问[入驻进去的客户企业以及消费者]
是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒)

1.2 单机eureka构建步骤 [EnableEurekaServer,EnableEurekaClient]

1.2.1IDEA生成EurekaServer端服务注册中心   类似物业公司 [物业公司不会自己注册自己]

1.2.2EurekaClient端cloud-provider-payment8001 将注册进EurekaServer成为服务提供者provider

1.2.3EurekaClient端cloud-consumer-order80 将注册进EurekaServer成为服务消费者consumer

1.3集群eureka构建步骤 [EnableEurekaServer,EnableEurekaClient]

服务注册:将服务信息注册进注册中心
服务发现从注册中心上获取服务信息
实质:存key服务命联value冷用地址
1先启动eureka注册中心
2启动服务提供者payment支付服务
3支付服务启动后会把自身信息(比如服务地址以别名方式注册进eureka)
4消费者order服务在需要调用接口时，使用服务名去注册中心去获取实际的RPC远程调用地址
5消费者获得调用地址后,底层实际是利用HttpClient技术实现远程调用
6消费者获得服务地址后会缓存在本地jvm内存中,默认没间隔30s更新一次服务调用地址

问题:微服务RPC远程服务调用最核心的是什么

高可用，试想你的注册中心只有一个only one，它出故障了那就呵呵(一v)"了，会导致整个为服务环境不可用，所以解决办法:搭建eureka注册中心集群,实现负载均衡+故障容错

1.3.1集群原理:互相注册,相互守望
 

1.4服务发现Discovery [DiscoveryClient  EnableDiscoveryClient]

对于注册eureka里面的微服务,可以通过服务发现来获得该服务的信息

1.5eureka自我保护

1.5.1故障

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

1.5.2什么是自我保护模式?
默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒)。但是当网络分区故障发生(延时、卡顿、拥挤)时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时(可能发生了网络分区故障)，那么这个节点就会进入自我保护模式。
在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。
它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲解:好死不如赖活着
综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留）也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。
 

1.5.3导致原因 [欠了物业费,可以缓几天,慢慢恢复,保证高可用]

一句话:某时刻 一个微服务不可用了,Eureka不会立刻清理,依旧会对该服务的信息进行保存

属于CAP里面的AP分支

1.5.4怎么禁止自我保护

出产默认,自我保护机制是开启的  eureka.server.enable-self-preservation=true

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

#Eureka客户端向服务端发送心跳的时间间隔，单位为秒(默认是30秒)
#lease-renewal-interval-in-seconds: 1
#Eureka服务端在收到最后一次心跳后等待时间上限，单位为秒(默认是90秒)，超时将剔除服务
#lease-expiration-duration-in-seconds: 2

1.6eureka停更说明

---

二、Zookeeper服务注册与发现

2.1Eureka停止更新了,你怎么办 https://github.com/Netflix/eureka/wiki

2.2SpringCloud整合Zookeeper替代Eureka

2.2.1注册中心Zookeeper

Zookeeper是一个分布式协调工具,可以实现注册中心功能

关闭Linux服务器防火墙后启动Zookeeper服务器

Zookeeper服务器取代Eureka服务器,zk作为服务注册中心

2.2.2服务提供者

服务节点是临时性的,不是持久的

把8004停了,这个节点没有马上消失,zookeeper还给你发心跳包,但是你一会不到,就把你干掉了

重新启动8004,服务名还是同一个,流水号变了,一定时间内有,就给你留下,不然就清除了

2.2.3服务消费者

 

---

三、Consul服务注册与发现

3.1是什么 https://www.consul.io/intro/index.html

Consul是一套开源的分布式服务发现和配置管理系统，由HashiCorp公司用Go语言开发。
提供了微服务系统中的服务治理、配置中心、控制总线等功能。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网格，总之Consul提供了—种完整的服务网格解决方案。它具有很多优点。包括:基于raft协议，比较简洁;支持健康检查，同时支持HTTP和DNS协议支持跨数据中心的WAN集群提供图形界面跨平台，支持Linux、Mac Windows

3.2能干嘛

3.2.1服务发现 提供HTTP/DNS两种发现方式

3.2.2健康检测 支持多种方式,HTTP、TCP、Docker、shell脚本定制化

3.2.3KV存储 Key、Value的存储方式

3.2.4多数据中心 Consul支持多数据中心

3.2.5可视化界面

3.3在哪下 https://www.consul.io/downloads.html

3.4怎么玩 https://www.springcloud.cc/spring-cloud-consul.html

3.5安装并运行consul

3.5.1官网安装说明 https://learn.hashicorp.com/consul/getting-started/install.html

下载完成后只有一个consul.exe文件 硬盘路径下双击运行,查看版本信息

3.5.2使用开发模式启动

consul agent -dev

通过以下地址可以访问Consul的首页: http://localhost:8500

---

四、三个注册中心的异同点

4.1CAP  [分区容错性要保证,所以要么是CP,要么是AP]

C: Consistency(强一致性)

A: Availability(可用性)

P: Parttition tolerance(分区容错性)

CAP理论关注粒度是否是数据,而不是整体系统设计的策略

4.2经典CAP图

AP(eureka)[关注高可用]

CP(Zookeeper/Consul)  [关注数据一致性]

CP架构
当网络分区出现后,为了保证一致性,就必须拒绝请求,否则无法保证一致性
结论:违背了可用性A的要求,只满足一致性和分区容错,即CP
 

最多只能同时较好的满足两个。
CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CР原则和满足AP原则三大类:
CA-单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP-满足一致性，分区容忍必的系统，通常性能不是特别高。

AP-满足可用性，分区容忍性的系统，通常可能对—致性要求低一些。