搭建微服务笔记
##1.创建maven-quickstart
eureka自我保护与AP原则
eureka的自我保护
某时刻一个微服务不可用了，eureka不会立刻清理，依旧会对微服务的信息进行保存
或者当微服务的心跳失去连接，也不会立刻清理
可以将自我保护机制禁用（server端）
eureka集群配置
在单机版的基础上，服务器的路径要更多
client的指定的服务器的地址为集群所有的服务器的地址
eureka与zookeeper的优势比较
Netflix在设计eureka时遵循的就是AP原则
C:Consistency（强一致）
A:Availability（可用性）
P:Partition tolerance（分区容错性）
zookeeper保证cp{要通过选出leader}
eureka的各个结点平等
eureka的自我保护机制
如果在15分钟内超过85%的结点都没有正常的心跳，那么eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1.eureka不再从注册中心列表中一处因为长时间没收到心跳而应该国企的服务
2.eureka依然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（保证当前节点依然可用）
3.当网络稳定时，当前实例新的注册信息会被同步到其他节点中
Ribbon负载均衡
客户端的软件负载均衡算法
ribbon的配置
1.添加pom依赖
2.修改application.yml 追加eureka的服务注册地址
3.对restTemplate上添加@loadbalance注解
4.主启动类添加@EnableEurekaClient
NOTES:
1.微服务可以允许有自己的数据库；
2.同时微服务的服务名不允许有下划线，否则无法通过微服务名调用服务。
3.服务注册完消费端微服务需要重启去获取新的服务注册信息
ribbon自定义
1.消费者主启动类添加注解@RibbonClient(name=”微服务名”，cnfiguration=自定义负载均衡规则类.class)
Feign负载均衡
feign是声明式的Web服务客户端，使得编写web服务客户端变得非常容易
只需要创建一个接口，然后再上面添加注解
参考官网:https://github.com/OpenFeign/feign
hystrix断路器
分布式系统中可能面临的问题：
复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系再某些时候将不可避免地失败。（服务雪崩）
若每一层的链式依赖的响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的雪崩。
对于高流量的单体应用而言，单一的后端依赖可能会导致所有服务器上的所有资源再几秒内饱和。比失败更糟糕的式，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表名需要对故障和延迟进行隔离和管理，以便于单个依赖关系的失败，不能取消整个应用程序或其他。
hytrix是什么？
Hytrix是一个处理分布式系统的延迟和容错的开源库，他能保证再分布系统 中在一个依赖调用失败下，不会导致整体服务失败；而是会向调用方返回一个符合预期的可处理的备选响应（fallback），而不是长时间的等待或者抛出调用方无法处理的异常。
hytrix能干什么？
服务熔断
一般是某个服务故障或者异常引起，类似于现实当中的“保险丝”，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时。
restController接口上添加注解，并且添加到接口调用出现错误后要调用fallback的方法。
书写fallbackfang方法，供接口发生错误后的调用
在主启动类上启动hytris，添加开启注解
服务降级
所谓降级，一般是整体负荷的考虑。就是当某个服务熔断之后，服务器将不会在被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省。这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。
整体资源快不够了，忍痛将某些服务先关掉，待度过难关，在开启回来。
服务降级处理是在客户端实现完成的，与服务端没有关系
服务限流
接近实时的监控
