SpringCloud入门

一.eureka微服务创建的流程

1.首先我们要了解一下eureka是什么

Spring Cloud Eureka 是对Netflix公司的Eureka的二次封装，它实现了服务治理的功能，Spring Cloud Eureka提
供服务端与客户端，服务端即是Eureka服务注册中心，客户端完成微服务向Eureka服务的注册与发现。服务端和客户端均采用Java语言编写。下图显示了Eureka Server与Eureka Client的关系：

①、Eureka Server是服务端，负责管理各各微服务结点的信息和状态。
②、在微服务上部署Eureka Client程序，远程访问Eureka Server将自己注册在Eureka Server。
③、微服务需要调用另一个微服务时从Eureka Server中获取服务调用地址，进行远程调用。

2.搭建流程

①.创建一个工程为eureka注册中心，并在启动类上加注解@EnableEurekaServe注解声明注册中心
②.创建一个客户工程，在启动类上加注解@EnableEurekaClient声明客户端
③.访问Eureka服务注册中心页面即可

二.如何搭建eureka集群

我们假设要运行两个EurekaServer的集群，端口分别为：7001和7002
模拟多个 Eureka Server 在不同机器上 ： 进入C:\Windows\System32\drivers\etc\hosts 添加如下：
127.0.0.1 eureka7001.com
127.0.0.1 eureka7002.com

搭建集群的话只需要在eureka工程的基础上修改配置文件application.yml
把hostname改为eureka服务器的实例名称
把defaultZone改为http://eureka7001.com:7001/eureka/即可
启动后两个服务互相注册即可

三.服务提供方集群如何搭建

创建多个提供方，区分端口号

四.RestTemplate如何使用?

因为根据服务名称不知道到底调用哪台服务提供方的机器，所以我们需要进一步的改造我们的代码
消费者里面对RestTemplate配置的config文件，需要更改成如下：（就是加一个注解 @LoadBalanced）

五.简述eureka的自我保护模式？ 如何配置其自我保护模式

Eureka的自我保护机制用最通俗的语言说就是：好死不如赖活着。
一句话：某时刻某一个微服不可用了，eureka不会立刻清理，依旧会对改微服的信息进行保存。
默认情况下，如果eureka server在一定时间内没有接收到每个微服务实例的心跳，eureka server将会注销该实例
当网络分区故障发生时，微服务与eureka server之间无法正常通信，以上行为可能变得非常危险了，因为微服务本身其实是健康的，此时本不应该注销这个微服务。eureka通过“自我保护模式来解决这个问题”。
在自我保护模式中，eureka server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阀值以上时，该eureka server节点就会自动退出自我保护模式。
此时只需要在配置文件中加上以下代码

六.什么是CAP理论? cp ap原则的含义

CAP理论作为分布式系统的基础理论,它描述的是一个分布式系统在以下三个特性中：

• 一致性(Consistency)
• 可用性（Availability）
• 分区容错性（Partition tolerance）

一致性（C）： 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（所有节点在同一时间的数据完全一致，越多节点，数据同步越耗时）

可用性（A）： 负载过大后，集群整体是否还能响应客户端的读写请求。（服务一直可用，而且是正常响应时间）

分区容错性（P）： 分区容忍性，就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，越多机器越好）

再进一步解释CAP理论： 就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡

C A 满足的情况下，P不能满足的原因：
数据同步©需要时间，也要正常的时间内响应(A)，那么机器数量就要少，所以P就不满足

CP 满足的情况下，A不能满足的原因：
数据同步©需要时间, 机器数量也多§，但是同步数据需要时间，所以不能再正常时间内响应，所以A就不满足

AP 满足的情况下，C不能满足的原因：
机器数量也多§，正常的时间内响应(A)，那么数据就不能及时同步到其他节点，所以C不满足

最多满足其中的两个特性。也就是下图所描述的。分布式系统要么满足CA,要么CP，要么AP。无法同时满足CAP。

AP架构：
明显AP结构选择了高可用和分区容错性，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。Eureka就是一个AP架构的例子，当Eureka客户端心跳消失的时候，那Eureka服务端就会启动自我保护机制，不会剔除该EurekaClient客户端的服务，依然可以提供需求；
CP架构：
CP架构选择的是一致性和分区容错性，如果选择一致性C(Consistency)，为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。最好的例子就是zookeeper，如果客户端心跳消失的时候，zookeeper会很快剔除该服务，之后就无法提供需求；

七.eureka 和zookeeper consul的区别?

Zookeeper和Consul ：CP设计，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则无法提供服务，因此可用性没法满足

Eureka：AP原则，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化

结论：分布式系统中P肯定要满足，所以只能在CA中二选一
没有最好的选择，最好的选择是根据业务场景来进行架构设计
如果要求一致性，则选择zookeeper、Consul，如金融行业
如果要去可用性，则Eureka，如电商系统

八.使用ribbon进行负载均衡的步骤

①.在服务消费方开启负载均衡

②.创建一个配置类

此时要注意：该类不能放在主应用程序上下文@ComponentScan所扫描的包中，否则配置将会被所有Ribbon Client共享。

③.然后在主启动类上添加如下注解 @RibbonClient：

九.ribbon负载均衡的策略有哪些

策略类	命名	描述
RandomRule	随机策略	随机选择server
RoundRobinRule	轮询策略	轮询选择， 轮询index，选择index对应位置的Server
RetryRule	重试策略	对选定的负载均衡策略机上重试机制，在一个配置时间段内当选择Server不成功，则一直尝试使用subRule的方式选择一个可用的server
BestAvailableRule	最低并发策略	逐个考察server，如果server断路器打开，则忽略，再选择其中并发链接最低的server
AvailabilityFilteringRule	随机策略	随机选择server
RandomRule	可用过滤策略	过滤掉一直失败并被标记为circuit tripped的server，过滤掉那些高并发链接的server（active connections超过配置的阈值）或者使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个Server的运行状态
ResponseTimeWeightedRule	响应时间加权重策略	根据server的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间越短，权重越高，被选中的概率越高，这个策略很贴切，综合了各种因素，比如：网络，磁盘，io等，都直接影响响应时间
ZoneAvoidanceRule	区域权重策略	综合判断server所在区域的性能，和server的可用性，轮询选择server并且判断一个AWS Zone的运行性能是否可用，剔除不可用的Zone中的所有server

十.如何自定义负载均衡

根据上面负载均衡的策略，在这个RibbonConfig类中定义负载均衡