一、Eureka注册中心架构图原理
Register（服务注册）：把自己的IP和端口注册给Eureka
Renew（服务续约）：发送心跳包，每30秒发送一次，告诉Eureka自己还活着
Cancel（服务下线）：当provider关闭时会向Eureka发送消息，把自己从服务列表中删除。防止consumer调用到不存在的服务
Get Registry（获取服务注册列表）：获取其他服务列表
Replicate（集群中数据同步）：eureka集群中的数据复制与同步
Make Remote Call（远程调用）：完成服务的远程调用
二、CAP原则与两大主流服务框架ZK、Eureka的对比
1.CAP原则：CAP原则又称CAP定理，指的是在一个分布式系统中，
Consistency（一致性）、
Availability（可用性）、
Partition tolerance（分区容错性），三者不可兼得
CAP由Eric Brewer在2000年PODC会议上提出。该猜想在提出两年后被证明成立，成为我们熟知的CAP定理
2.分别表示的含义
C：数据一致性（Consistency）,也叫做数据原子性，系统在执行某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。等同于所有节点访问同一份最新的数据副本
A：服务可用性（Availablity），每一个操作总是能够在一定的时间内返回结果，这里需要注意的是“一定时间内”和“返回结果”。一定时间内指的是，在可以容忍的范围内返回结果，结果可以是成功或者是失败
P：分区容错性（Partition-torlerance），在网络分区的情况下，被分割的节点仍能对外提供服务（分布式集群，数据被分布存储在不同的服务器上，无论什么情况，服务器都能正常被访问）
3.不同组合的含义
CA，放弃P：如果想避免分区容错性问题的发生，一种做法是将所有的数据（与事务关的）都放在一台机器上。虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果，当然这个选择会严重影响系统的扩展性
CP，放弃A：相对于放弃“分区容错性”来说，其反面就是放弃可用性。一旦遇到分区容错故障，那么受影响的服务需要等待一定时间，因此在等待时间内系统无法对外提供服务
AP，放弃C：这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。以网络购物为例，对只剩下一件库存的商品，如果同时接受了两个订单，那么较晚的订单将被告知商品告罄
重要定律：任何分布式系统只可同时满足其中两点，无法三者兼顾
4.Zookeeper与Eureka的区别
三、Eureka的服务自我保护
1.自我保护的条件：一般情况下，微服务在Eureka上注册后，每30秒会发送心跳包，Eureka通过心跳来判断服务是否健康，同时会定期删除超过90秒没有发送心跳的服务
2.有两种情况会导致Eureka Server收不到微服务的心跳
a．是微服务自身的原因
b．是微服务于Eureka之间的网络故障
通常（微服务的自身的故障关闭）只会导致个别服务出现故障，一般不会出现大面积故障，而（网络故障）通常会导致Eureka Server在短时间内无法收到大批心跳
考虑到这个区别，Eureka设置了一个阈（yu）值，当判断挂掉的服务的数量超过阈（yu）值时，Eureka Server认为很大程度上出现了网络故障，将不再删除心跳过期的服务
3.那么这个阈（yu）值是多少呢？
15分钟之内是否低于85%；
Eureka Server在运行期间，会统计心跳失败的比例在15分钟内是否低于85%，这种算法叫Eureka Server的自我保护模式
4.为什么要启动自我保护？
a.因为同时保留“好数据”与“坏数据”总比丢掉任何数据要更好，当网络故障恢复后，这个Eureka节点会退出“自我保护模式”。
b.Eureka还有客户端缓存功能（也就是微服务的缓存功能）。即便Eureka集群中所有节点都宕机失效，微服务的Provider和Consumer都能正常通信
c.微服务的负载均衡策略会自动剔除死亡的微服务节点
5.关闭自我保护的方式
修改application.properties/yml全局配置文件
四、Eureka服务的优雅停服
1.修改pom.xml配置文件，添加Eureka-Server的依赖
2.修改application.properties/yml全局配置文件
添加：
3.测试
http://Eureka服务所在的IP+端口/shutdown，而且URL必须要使用dopost方式发送
我们可以借助HttpClient工具类来实现
五、开启Eureka安全中心的安全认证
旧版本配置方式
1.在Eureka Server中添加security依赖
2.修改application.properties/yml全局配置文件
开启htpp basic的安全认证
3.修改访问集群节点的url，添加配置的用户名和密码（必然彼此之间会访问失败，集群注册失败）
新版本（高版本）配置方式
1.添加依赖，groupId有所差异
2.修改eureka服务全局配置文件（有几个服务配置几个）
3.新建类添加@Configuration变成SpringBoot配置类，继承WebSecurityConfigurationAdapter类，重写configure方法，禁用csrf
注意，一旦开启安全认证，需要配置传递用户名和密码
修改微服务的配置文件添加访问注册中心的用户名与密码（每个注册节点都要配置）
六、负载均衡Ribbon
负载均衡在微服务中的作用
1.Ribbon的概念
a.Ribbon是一个基于Http和TCP的客户端负载均衡工具，他是语句Netflix Ribbon实现的
b.它不像spring cloud服务注册中心、配置中心、API网关那样独立部署，但是它几乎存在于每个spring cloud微服务中。包括feign提供的声明式服务调用也是基于该Ribbon实现的
c.ribbon默认提供很多种负载均衡算法，例如轮询、随机等等，甚至包括自定义的负载均衡算法
Ribbon解决并提供了微服务的负载均衡的问题
2.负载均衡方案的分类
目前业界主流的负载均衡方案可分成两类：
第一类：集中式负载均衡，即在consumer和provider之间使用独立的负载均衡设施（可以是硬件，如F5，也可以是软件，如nginx），由该设置负责把访问请求通过某种策略转发至provider；
第二类：进程内负载均衡，将负载均衡逻辑集成到consumer，consuerm从服务注册中心获知由哪些地址可用，然后自己再从这些地址中选择出一个合适的provider；
Ribbon就属于后者，它只是一个类库，集成于consumer进程，consumer通过它来获取到provider的地址。
3.Ribbon的负载均衡策略
A.策略名称：轮询策略（默认）
对应的类名： RoundRobinRule
实现原理：轮询策略表示每次都顺序取下一个 provider，比如一共有 5 个provider，第 1 次取第 1 个，第 2
次取第 2 个，第 3 次取第 3 个，以此类推
B.策略名称：权重轮询策略
对应的类名：WeightedResponseTimeRule
实现原理：
1.根据每个 provider 的响应时间分配一个权重，响应时间越长，权重越小，被选中的可能性越低。
2.原理：一开始为轮询策略，并开启一个计时器，每 30 秒收集一次每个 provider 的平均响应时间，当信息
足够时，给每个 provider附上一个权重，并按权重随机选择provider，高权越重的 provider会被高概率选中。
C.策略名称：随机策略
对应的类名：RandomRule
实现原理：从 provider 列表中随机选择一个 provider
D.策略名称：最少并发数策略
对应的类名：BestAvailableRule
实现原理：选择正在请求中的并发数最小的 provider，除非这个provider 在熔断中
E.策略名称：在“选定的负载均 衡策略”基础上进行重 试机制
对应的类名：RetryRule
实现原理：
1.“选定的负载均衡策略”这个策略是轮询策略RoundRobinRule
2.该重试策略先设定一个阈值时间段，如果在这个阈值时间段内当选择 provider 不成功，则一直尝试采用“选定
的负载均衡策略：轮询策略”最后选择一个可用的provider
F策略名称：可用性敏感策略
对应的类名：AvailabilityFilteringRule
实现原理：过滤性能差的 provider,有 2种：
第一种：过滤掉在 eureka 中处于一直连接失败 provider
第二种：过滤掉高并发的 provider
G.策略名称：区域敏感性策略
对应的类名：ZoneAvoidanceRule
实现原理：
1.以一个区域为单位考察可用性，对于不可用的区域整个丢弃，从剩下区域中选可用的provider
2.如果这个 ip 区域内有一个或多个实例不可达或响应变慢，都会降低该 ip 区域内其他 ip 被选中的权重。
七、Ribbon更换轮询策略
1.创建Maven项目，添加依赖
2.修改启动类，在启动类中添加开启eureka客户端的注解，并编写方法创建要获取的轮询对象
3.修改配置文件更换负载均衡策略
八、Ribbon设置点对点连接（教学演示，不推荐使用该方式）
1.创建项目，添加依赖，去掉Eureka相关的配置，单独添加ribbon的依赖
2.修改application.properties/yml全局配置文件，禁用eureka，并指定具体的服务实例清单
3.启动测试
