springcloud

package命令完成了项目编译、单元测试、打包功能，但没有把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库
install命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库，但没有布署到远程maven私服仓库
deploy命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库

对于消费端可以使用springBoot 提供的RestTemplate 模仿发送rest风格的http请求

1.Eureka使用
使用c-s架构 Eureka Server 是服务注册功能的服务器 是服务的注册中心
其他微服务使用Eureka客户端链接到Eureka的服务器端 这样可以通过Eureka server监控
各个微服务的正常运行，Eureka server可以在界面看到所有可用的微服务信息
Euraka client 内置一个（round-robin）轮询算法的负载均衡器
在应用启动客户端会向Eureka server 发送心跳（默认为30秒） 服务端如果再多个心跳周期没有接收到某个节点的服务 则服务端将会把这个服务节点从服务注册表移除（默认90秒）

使用：
1.服务端配置 +导入jar包依赖

2.服务端注解

3.客户端注解+jar包依赖

4.客户端注解

5.自我保护机制

某时刻某个微服务不可以了，eureka不会立即清理 还是会对改微服务的信息进行保存

6.关于eureka遵守的原则
RDBMS(mysql/oracle/sqlserver) ====> ACID 原则
A(Atomicity) 原子性
C(Consistenctcy) 一致性
I(Isolation) 独立性
D(Dureblility) 持久性

NOSQL(redis/mongdb) ===>CAP 原则
C(Consistenctcy) 强一致性
A(Availablity)可用性
P Partition tolerance分区容错性

任何分布式系统只能其中的两个原则 即为三进二原则，分布式系统必须要有P 分区容错性

7.Eureka比Zookeeper好在哪里
作为服务注册中心，Eureka比Zookeeper好在哪里
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
因此
Zookeeper保证的是CP,
Eureka则是AP。

4.1 Zookeeper保证CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

4.2 Eureka保证AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

Ribbon负载均衡


负载均衡分为两种
1.集中式 LB 偏硬件的 放于提供方 及服务注册注册中心
2.进程内LB 偏软件 放于消费方

Ribbon的配置方式
1.导入jar包
2.消费端添加负载均衡的注解 @LoadBalancer
3.默认为轮询算法
4.自定义负载均衡算法 方法为 IRULE为负载均衡的顶层接口 AbstractLoadBalanceRule抽象类实现了IRULE接口，所以要自定义算法的话需要继承AbstractLoadBalanceRule这个抽象类 然后config文件里面返回一个bean
5.使用已经提供的算法的话 只需要在config文件中返回提供一个已经给的方法的对象

Feign配置以及使用方式
是一个webservice的客户端

@EnableFeignClients(basePackages= {“com.atguigu.springcloud”})
这里的基础包即为编写的feign的controller 的位置
@ComponentScan(“com.atguigu.springcloud”)
还不清楚作用
@EnableFeignClients主启动类上面

feign和ribbon的区别
相同点：都是在客户端进行负载均衡 而feign集成了ribbon
不同点：
ribbon负载均衡的实现是通过RestTemplate的rest风格的模板方法仿发送http请求的方式进行负载均衡 自定负载均衡方法可以通过继承AbstractLoadBalanceRule实现里面的方法来实现
Feign 相当于面向接口的方式编程 可以在maven通用的api工程来进行接口编写再次位置进行负载均衡 且通过rest方式跳到实际的地址，在消费端通过实现接口调用接口的方法 来进行条装

常见术语
1.服务雪崩
服务雪崩
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

备注：一般情况对于服务依赖的
保护主要有3中解决方案：

（1）熔断模式：这种模式主要是参考电路熔断，如果一条线路电压过高，保险丝会熔断，防止火灾。放到我们的系统中，如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

（2）隔离模式：这种模式就像对系统请求按类型划分成一个个小岛的一样，当某个小岛被火少光了，不会影响到其他的小岛。例如可以对不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源。这种模式使用场景非常多，例如将一个服务拆开，对于重要的服务使用单独服务器来部署，再或者公司最近推广的多中心。

（3）限流模式：上述的熔断模式和隔离模式都属于出错后的容错处理机制，而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。

Hystrix
服务熔断
为防止在扇出服务链路上面因为某一个服务长时间的未反应结果 而导致整个扇出链路上面出现雪崩效应，所以当某一个服务请求超时 或者出现错误的时候 可以自定义错误信息从而快速返回信息

方式1.再服务的提供方添加
通过对controller层加上hystrix的注解可实现自定义返回信息
@HystrixCommand(fallbackMethod=“processHystrix_Get”)
processHystrix_Get为自定义方法 需要自己写方法

方式2.再api模块定义个实现FallbackFactory的类DeptClientService是请求的接口，在接口上需要返回方法的名字

FallbackFactory会让其实现一个接口 在其内部可以返回一个匿名内部类，此类数与api模块 所以要让其实例化 则需要添加注解@Component
例如

这样在服务出现降级的时候就会返回这个信息，以及错误的时候也会返回这个信息

服务降级
在其他的服务的服务器资源出现压力大的时候 可以关闭那些压力小的服务 提供给压力大的服务 待压力大的服务压力减小后再重新启动服务 从而达到服务资源的合理分配

在服务的客户端实现服务的降级，如果模拟关闭服务的提供发

Hystrix的dashboard
表示服务请求的控制面板 可以查看服务的压力等情况
有七色 一圈 一线
实心圆：共有两种含义。它通过颜色的变化代表了实例的健康程度，它的健康度从绿色<黄色<橙色<红色递减。
该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆就越大。所以通过该实心圆的展示，就可以在大量的实例中快速的发现故障实例和高压力实例。