注备：其实这篇文章是我在2019年初整理的 （现在市面上用阿里巴巴版的，微服务 比较多）

Eureka 和 zookeeper 的区别

负载均衡

spring cloud Ribbon 是基于Netflix Ribbon 实现的一套客户端 负载均衡的工具
简单的说 Ribbon 是Netflix 发布的开源的项目 主要功能就是提供客户端的软件负载均衡算法 将Netflix的中间层服务连接在一起 Ribbon 客户组件提供一系列完善的配置项如 连接超时 重试等 简单的说就是在配置 文件中列出 Load Balancer (简称 LB) 后面所有的机器 Ribbon 会自动帮助你基于某种规则（ 如 简单轮询，随机连接）去连接这些机器。我们也很容易使用Ribbon 实现自定义负载均衡算法

LB即负载均衡（Load Balance）在未付或分布式集群中经常用一种应用、负载均衡简单的说就是将 用户的请求平摊的分配到多个服务上 从而达到系统的HA、常见的有 Nginx Lvs 硬件F5等 相应的中间件 比如 dubbo和springcloud中均 提供了负载均衡，springcloud 的负载均衡算法可以自定义

集中式 LB
即在服务的消费方和提供方之间 使用 独立的LB设施（可以是硬件 例如F5 也可以是软件 如nginx）由该设施负责访问请求通过某种策略转发至服务的提供方

进程内LB
将LB 逻辑集成到 消费方 消费方从服务注册中心 获知有哪些地址可用，然后自己再从这些地址选出一个合适的服务器 Ribbon就是属于进程内LB 它只是一个类库， 集成与消费方的进程 消费方通过他来获取到服务提供方的地址

Ribbion 核心组件
RoundRobinRule 轮询
RandomRule 随机
AvailabilityFilteringRule 会先过滤掉由于多次访问故障而处于熔断器跳闸状态的服务，还有并发的连接数量超过閥值的服务，然后对剩下的服务列表按照轮询的策略访问
WeightedResponseTimeRule 根据平均响应时间计算所有服务的权重，响应时间越快服务权重越大被选中的概率高。刚启动时如果统计信息不足，则使用 RoundRobinRule策略，等统计信息足够，会切回到WeightedResponseTimeRule

RetryRule 先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内进行重试，获取可用的服务

BestAvailableRule 会先过滤由于多次访问故障而处于熔断器跳闸状态的服务，然后选择一个并发量最小的服务
ZoneAvoidanceRule 默认规则 复合判断server 所在区域性能和 server的可用选择性服务器

feign
Feign 只在使编写java Http 客户端变得更容易
前面在使用 Ribbon +RsetTemplate时利用RsetTemplate对Http请求的封装处理，形成了一套模板化的调用方法，但是在实际 开发中，由于对服务依赖的调用可能不止一个，往往一个接口会被多处调用，所以通常会针对 每一为服务自行封装一些客户 端类来包装这些依赖服务的调用，所以Feign在此基础上做了进一步的封装， 由它来帮助我们定义和实现依赖服务接口的定义 在Feign的实现下 我们只需创建一个接口并使用注解的方式来配置它（以前是Dao接口上面标注Mapper注解 ，现在是一个微服务接口上面标注一个Feign注解即可），即可完成对服务提供方的 接口绑定 ，简化了使用 SpringCloud Rinnon时 自动封装服务调用客户端的开发量
Feign集成Ribbon
利用Ribbon维护了 微服务的服务列表信息，并且通过轮询实现了客户端的负载均衡，而与Ribbon不同的是 通过Feign只需要定义服务绑定接口且以声明的方式的方法，简单的实现了服务调用

服务雪崩
多个微服务之间调用的时候 假设微服务A调用用微服务B和微服务C， 微服务B和微服务C又调用其他微服务，这就是所谓的扇出 如果扇出的链路上某个微服务的调用响应时间过长或者不可用 对微服务A的调用就会占用越来越多的资源呢，进而引起系统崩溃，所谓的雪崩效应
对于高流量的应用来说，单一的 后端依赖可能导致所有微服务器上的所有资源都在几秒钟内饱和，比失败更糟糕的是这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张 导致整个系统发生更多的级联故障 ，这些故障和延迟进行隔离和管理 ，以便单个依赖关系的失败，不能取消整个应用程序或系统

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会条用失败，比如超时，异常等。Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障以 提高分布式的弹性
熔断器 本身是一种开关装置，当某个服务单元发生故障之后，通过熔断器的故障监控（类似与保险丝）向调用方返回一个符合预期的，可处理的备选响应（Fall Back）而不是长时间的等待或者抛出调用方无法处理的异常。这样就保证了服务调用方的线程不会被长时间 不必要地占用，从而避免了故障在分布式系统的蔓延，乃至雪崩

服务熔断
熔断机制是应对学雪崩效应的一种微服务 链路保护机制
当扇出链路的某个微服务不可用或者响应时间太长时 会进行服务降级 进而熔断该节点微服务的调用 快速返回错误的香影信息，当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控服务间调用状况，当失败的 调用到一定的阈值，缺省5秒20次调用失败就会启动熔断机制。熔断机制注解是 @HystrixCommand

zuul包含了对外请求的路由和过滤两个最要的功能
其中路由功能负责将外部的请求转发到具体的微服务实例上，是实现外部访问统一入口基础而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合功能的基础Zuul和eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获取到其他的微服务的消息，也即以后的访问微服务都是通过 Zuul跳后获得
Zuul还是会注册到Eureka里

微服务意味着将单体应用中的业务拆分成一个个子服务，没个服务的粒度相对较小，以此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的，动态的配置管理设施是必不可少的。springcloud提供ConfigServer来解决这个问题，我们每一个微服务自己带着一个 application.yml.
分布式配置中心

SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境 提供 一个中心的外部配置

SpringCloud分为服务端和客户端两部分
服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口
客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息，配置服务器默认采用git来存储配置信息，这样就有助于对环境配进行版本管理，并且可以通过git客户端工具来方便管理和访问配置内容

集中管理配文件 不同环境不同的配置，动态化的配置更新，分环境部署 运行期间动态 调整 不在需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息 当配置发生变动时 服务不需要 重启即可感知到 配置文件的变化并且应用新的配置 将配置信息以REST接口的形式暴露

applicaiton.yml是用户级的资源配置项
bootstrap.yml 是系统级别的，优先级更高
SpringCloud 会 创建一个Bootstrap Context,作为spring应用的Applicaiton Context,的父上下文，初始化的时候Bootstrap Context负责从外部源加载配置属性并解析配置 ，这两个上下文共享一个从外部获取 Environment,Bootstrap 属性有高优先级，默认情况下 他们不会本地配置覆盖，Bootstrap Context和Applicaiton Context有着 不同 的约定
所以新增一个 bootstrap文件 保证 Bootstrap Context 和Applicaiton Context 配置的分离