决战圣地玛丽乔亚Day01

SpringCloud的服务注册与发现：

单机的服务注册与发现需要配置一个服务注册中心，一个生产者微服务，一个消费者微服务。

注册中心：

 

 

 服务的生产者：

服务的消费者：

 

配置的方式大致类似。调用都是通过RestTemplate进行远程调用。

但是实际的生产过程中不可能只有一台主机，需要考虑使用集群来解决大流量的问题。

这时候，注册中心和各个微服务都是以集群的形式出现。

注册中心的配置文件的方式也需要进行改造，defaultZone的地址从自己改为集群的其他注册中心地址，如果有三台注册中心，两两注册。

 defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/

对于生产者的defaultZone，需要写所有注册中心的地址，代表可以向其中的任意一个进行注册

service-url:
defaultZone:

http://eureka7001.com:7001/eureka,

http://eureka7002.com:7002/eureka,

http://eureka7002:com:7002/eureka

 

我们同样可以把服务的生产者变成集群的形式，创建多个提供者。

为了方便我们一眼看出请求是哪台机器发出的，可以对instance进行改造，之后即可在eureka网站上通过id进行分辨。

instance:
prefer-ip-address: true # 使用ip地址注册
instance-id: ${spring.cloud.client.ip-address}:${server.port}

 

 

Eureka剔除服务：

默认心跳间隔30s，等待时间90s，超出等待时间则会剔除服务。

instance:
prefer-ip-address: true # 使用ip地址注册
instance-id: ${spring.cloud.client.ip-address}:${server.port}
# 该实例给服务中心发送心跳的间隔时间，用于表明该服务实例可用
lease-renewal-interval-in-seconds: 2
# 服务中心删除此服务实例的等待时间(秒为单位),时间间隔为最后一次服务中心接受到的心跳时间
lease-expiration-duration-in-seconds: 10

 

Eureka的自我保护机制:

如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制。

某时刻某一个微服务不可用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存，其实是属于CAP理论中的AP

enable-self-preservation: false
eviction-interval-timer-in-ms: 3000

 

Ribbon负载均衡：

Ribbon负责客户端的负载均衡，进程式。在调用微服务接口的时候，会在注册中心获取注册信息服务列表之后缓存到JVM本地，从而实现RPC远程调用

Nginx负责服务器端的负载均衡。　所有的请求都会交给Nginx然后Nginx进行转发操作。

实现方法很简单：

1.在创建RestTemplate对象的时候，标注LoadBalance注解。

2.在使用RestTemplate调用远程微服务的时候，用服务名去请求服务地址。

 

restTemplate：

getForObject（返回响应结果）、getForEntity（返回相应结果+状态码+响应头信息）

 

IRule自定义轮询规则：

自带的特定算法：

• RoundRobinRule

  轮询【默认】

• RandomRule

  随机

• RetryRule

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

• WeightedResponseTimeRule

  对RoundRobinRule的扩展，响应速度越快的实例选择权重越大，越容易被选择

• BestAvailableRule

  会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务

• AvailabilityFilteringRule

  先过滤掉故障实例，再选择并发较小的实例

• AvailabilityFilteringRule

  默认规则，复合判断server所在区域的性能和server的可用性选择服务器。

重要细节：

官方文档明确给出了警告：这个自定义配置类不能放在@ComponentScan所扫描的当前包下以及子包下，否则我们自定义的这个配置类就会被所有的Ribbon客户端所共享，达不到特殊化定制的目的了。

 

 

 

通过@RibbonEurekaClient配置轮询策略过滤的服务名和需要实现的自定义的负责均衡算法。

 

轮询策略的底层逻辑：
rest接口第几次请求数 % 服务器集群总数量 = 实际调用服务器位置下标

 每次服务重启动后rest接口计数从1开始

 

轮询策略的源代码：

 

今天就到此为止了，希望我可以带着这份热情冲到六月份，顺利拿到offer。加油！