spring-cloud day2

Eureka 服务注册与发现
Netflix在设计Eureka时，遵循的就是ap原则(C:强一致性、P:分区容错性、A:可用性)
Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于rest的服务用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对微服务来说非常重要，有了服务发现与注册，只需要使用服务的标识符，就可以访问服务，而不需要修改服务调用的配置文件，功能类似于Dubbo的之策中心：zookeeper

原理讲解：
	Eureka的基本架构:
		springcloud封装了Netflix公司开发的Eureka模块来实现服务注册与发现
		Eureka采用了c/s的架构设计，EurekaServer作为服务注册功能的服务器，他是服务注册中心
		而系统中的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心跳链接，这样系统的为湖人就可以通过EurekaServer来监控系统中各个微服务是否正常运行，spring cloud的一些其他模块(如zuul)就可以通过EurekaServer来发现系统中的其他微服务。
	和Dubbo架构比较：
		Eureka包含两个组件：EurekaServer和EurekaClient
		EurekaServer提供服务注册服务，各个节点启动后，会在EurekaServer中注册，这样EurekaServer的服务注册表会储存所有可用服务节点的信息可以在界面中直观的看到
		EurekaClient是一个java客户端，内置一个轮询负载算法的负载均衡器。在应用启动后，会向EruekaServer发送心跳(默认周期为30S)，如果EurekaServer在多个心跳周期内没有接收到某个节点的心跳，EurekaServer会把这个服务移除(默认周期为90s)
		主要角色：
			EurekaServer 注册中心
			ServiceProvide 服务提供者
			ServiceConsumer 服务消费者
	自我保护机制：
		默认情况下，如果Eureka在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例(默认90s)，但是当网络分区故障发生时，微服务与Eureka之间无法正常通信，以上行为可能变得非常危险。因为微服务本身其实是健康的，此时不应该注销这个服务，所以Eureka通过自我保护机制来解决这个问题。当EurekaServer节点在短时间内丢失过多客户端时，那么这个节点就会进入自我保护模式，一旦进入改模式，EurekaServer就会保护服务注册表中的信息，不会删除服务注册表中的数据，当服务正常后，EurekaServer就会自动退出自我保护机制。
		在自我保护模式中，EurekaServer会保护服务注册表中的信息，不在注销任何服务实列，当他收到心跳数重新恢复到阈值以上时，改EurekaServer节点就会自动退出自我保护模式。俗称好死不如赖活着。
		自我保护模式是一种应对网络异常的安全保护措施，他的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务，使用自我保护模式，可以让Eureka集群更加健壮
		在spring cloud中，可以使用eureka.server.enbale-self-preservation = false禁用自我保护模式(不推荐关闭自我保护)
		
服务发现Discovery：
		对于注册进eureka里面的微服务，可以通过服务发现来获得该服务信息
回顾CAP原则：
		RDBMS(mysql\orcle\sqlserver)===>ACID
		Nosql(redis\mongdb)===>CAP
		ACID是什么？
			A：原子性
			C：一致性
			I：隔离性
			D：持久性
		CAP是什么？
			C：强一致性
			A：可用性
			P：分区容错性
		CAP的三进二：CA\AP\CP
		CAP理论的核心
			一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性三个需求
			根据CAP原理，将Nosql数据库分成了满足CA原则，满足CP原则和满足AP原则三大类
			CA：单点集群，满足一致性、可用性的系统，通常可扩展性较差
			CP：满足一致性，分区容错性的系统，通常性能不是特别高
			AP：满足可用性，分区容错性的系统，通常对一致性要求较低
作为服务注册中心，eureka比zookeeper好在哪儿
			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就会认为客户端与注册中心出现了网络故障，此时会出现一下几种情况：
				1、eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务
				2、eureka仍然能够接受新服务的注册和查询请求，但不会被同步到其他节点上
				3、当网络稳定时，当前实列新的注册信息会被同步到其他节点中
			因此：eureka可以很好的应该因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

负载均衡：ribbon
ribbon是什么：
spring cloud Ribbon是基于Netflix ribbon实现的一套客户端负载均衡工具
简单的说，ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务链接在一起。ribbon的客户端组件提供一系列完整的配置项如：连接超时、重试等等。简单的说，就是在配置文件中列出loadbalancer(简称LB：负载均衡)后面所有的机器，ribbon会自动的帮助你基于某种规则如：简单轮询、随机连接等等去链接这些机器。我们也很容易使用ribbon实现自定义的负载均衡算法
ribbon能干什么？
LB：负载均衡，在微服务或分布式集群中常用的一种应用
负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA(高可用)
常见的负载均衡软件有nginx、Lvs等等
dubbo、spring cloud中均给我们提供了负载均衡，spring cloud的负载均衡算法可自定义
负载均衡简单分类：
集中式LB：
即在服务的消费方和提供方之间使用独立的LB设施，如nginx由该设施负载把访问请求通过某种策略转发至服务的提供方
进程式LB：
将LB集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器
ribbon属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到提供方的地址
ribbon和eureka整合后，客户端可以直接调用，不用关系IP地址和端口号
Feign:负载均衡
fegin是声明式的web service 客户端，他让微服务之间的调用变得更简单。类似controller调用service，spring cloud集成了ribbon和eureka，可在使用feign时提供负载均衡
调用微服务两种方式：
ribbon 微服务名称
feign 接口和注解
feign能干什么
feign旨在使编写Java HTTP客户端变得更容易
前面在使用ribbon+rest Template时，利用rest template对HTTP请求的封装处理，形成了一套模板化的调用方法。但在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖的调用。所以feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义，在feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它(类似于以前DAO接口上标注MAPPER注解，现在是一个微服务接口上面标注一个feign注解即可)即可完成对服务提供方的接口绑定，简化了使用spring cloudribbon时，自动封装服务调用客户端的开发量。
feign集成了ribbon
利用ribbon维护了服务列表信息，并且通过轮询实现了客户端的负载均衡，而与ribbon不同的是，通过feign只需要定义服务绑定接口且以声明式的方法，优雅而且简单的实现了服务调用。
Hystrix
服务雪崩：
多个微服务调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他微服务，这就是所谓的扇出。如果扇出的链路上某个微服务的调用响应时间过长或着不可用，对微服务A的调用就会占用越来越多的系统资源，从而引起系统崩溃，进而引起所谓的雪崩效应。对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒之内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列、线程和其他系统资源紧张，导致整个系统发生更多的联级故障，这些都表示需要对故障和延迟进行隔离和管理，以单个依赖关系的失败，不能取消整个应用程序或系统
什么是Hystrix？
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统中，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免联级故障，以提高分布式系统的弹性。
断路器本省是一种开关 装置，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个服务预期的，可处理的备选响应，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
能干吗？
服务降级、服务熔断、服务限流、接近实时的监控
官网资料：https://github.com/Netfilx/Hystrix/wiki
服务熔断是什么：
熔断机制是对应雪崩效应的一种微服务链路保护机制
当扇出链路的某个微服务不可用或者响应时间太长，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的信息。当检测到该节点微服务调用响应正常后恢复调用链路。在spring cloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的情况，当失败的调用到一定的阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand

zuul:路由网关
zuul包含了对请求的路由和过滤两个最重要的功能：
其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。zuul和eureka进行整合，将zuul自身注册为eureka服务治理下的应用，同时从eureka中获得其他微服务的消息，也即以后的访问微服务都是通过zuul跳转后获得
注意：zuul最终还是胡注册进eureka
提供：代理+路由+过滤三大功能
官方文档：https://guthub.com/Netflix/zuul

config:分布式配置
spring cloud config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同的微服务应用的所有环节提供了一个中心化的外部配置。spring cloud config为服务端和和客户端两部分；服务端也称为分布式配置中心，他是一个独立的微服务应用用来链接配置服务器并为客户端提供获取配置信息、加密、解密信息等访问接口。客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。