SpringCloud:服务注册与发现之Eureka(2)
Eureka集群原理
问题：微服务RPC远程服务调用最核心的是什么？
高可用，试想你的注册中心只有一个only one， 它出故障了那就呵呵(￣▽￣)"了，会导致整个为服务环境不可用。
解决办法：搭建Eureka注册中心集群 ，实现负载均衡+故障容错
EurekaServer集群环境构建
准备工作: 修改host文件 : C:\Windows\System32\drivers\etc
127.0.0.1 eureka7001.com
127.0.0.1 eureka7002.com
1.新建7002
参考cloud-eureka-server7001 新建 cloud-eureka-server7002
2.pom
7002 的 pom 和7001的相同
3.yml
server:
port: 7001
eureka:
instance:
hostname: eureka7001.com #eureka服务端的实例名称
client:
#false表示不向注册中心注册自己。
register-with-eureka: false
#false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
fetch-registry: false
service-url:
#设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址。
# 单机就是自己
# defaultZone: http://eureka7001.com:7001/eureka/
# 集群指向其他eureka
#defaultZone: http://eureka7002.com:7002/eureka/
#写成这样可以直接通过可视化页面跳转到7002
defaultZone: http://eureka7002.com:7002/eureka/server:
port: 7002
eureka:
instance:
hostname: eureka7002.com #eureka服务端的实例名称
client:
#false表示不向注册中心注册自己。
register-with-eureka: false
#false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
fetch-registry: false
service-url:
#设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址。
# 单机就是自己
# defaultZone: http://eureka7001.com:7001/eureka/
# 集群指向其他eureka
#defaultZone: http://eureka7002.com:7002/eureka/
#写成这样可以直接通过可视化页面跳转到7002
defaultZone: http://eureka7001.com:7001/eureka/测试
两个服务器的相互注册成功。
注册提供者这微服务和消费者微服务
将提供者服务8001微服务和消费者服务80微服务发布到上面的2台Eureka集群配置中
修改8001和80的yaml
defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka 测试
生产者(provider)微服务集群构建
一个提供者微服务不可能应对所有的消费者微服务，所有要建一个生产者微服务集群
新建cloud-provider-payment8002 微服务模块
1.pom
2.写yml
与8001一致，将port改为8002
3.其他
其他和8001相同，注意主启动类修改
4.修改 80 客户端
在配置类上使用@LoadBlanced注解赋予RestTemplate负载均衡的能力
@Configuration
public class ApplicationContextConfig {
@Bean
@LoadBalanced
public RestTemplate getRestTemplate(){
return new RestTemplate();
}
}
controller层的URL修改为服务的名字 CLOUD-PAYMENT-SERVICE（以前写死，因为只有一个微服务，现在有多个）
public static final String PAYMENT_URL = "http://CLOUD-PAYMENT-SERVICE";测试
提供者为8001和8002轮训，根据端口号看出
actuator微服务信息完善
在8001和8002的配置文件中加入
eureka:
instance:
instance-id: payment8001
prefer-ip-address: true
服务发现Discovery
服务发现：对于注册进eureka里面的微服务，可以通过服务发现来获得该服务的信息
@EnableDiscoveryClient注解
需要拿到在eureka上注册了的微服务的信息，例如：主机名称、端口号
在8001中进行测试
@Resource //发现自己的服务信息
private DiscoveryClient discoveryClient;
//服务发现
@GetMapping(value = "/payment/discovery")
public Object discovery() {
//得到全部服务清单
List<String> services = discoveryClient.getServices();
for (String service : services) {
log.info("*********element:" + service);
}
//获取微服务实例
List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");
for (ServiceInstance instance : instances) {
log.info(instance.getServiceId() + "\t" + instance.getHost() + "\t"
+ instance.getPort() + "\t" + instance.getUri());
}
return discoveryClient;
}2 在8001的主启动类中开启注解：@EnableDiscoveryClient
测试，访问http://localhost:8001/payment/discovery
eureka自我保护
CAP
- Consistency（一致性）：即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致。对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
- Avaliability（可用性）：即服务一直可用，而且是正常响应时间。系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。
- Partition Tolerance（分区容错性）：即分布式系统在遇到某节点或网络故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求应用虽然是一个分布式系统，但看上去切好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统要求，对于用户而言并没有什么体验上的影响
- CP和AP：分区容错是必须保证的，当发生网络分区的时候，如果要继续服务，那么强一致性和可用性只能2选1
自我保护
如果一定时间内丢失大量该微服务的实例，这时Eureka就会开启自我保护机制，不会剔除该服务。 因为这个现象可能是因为网络暂时不通，而不是服务不健康了，出现了Eureka的假死，拥堵，卡顿。 稍等会客户端还能正常发送心跳。 这就是CAP里面的AP分支思想
怎么禁止自我保护
如果在EurekaServer的首页看到以下这段提示，则说明Eureka进入了保护模式
修改7001的yml配置文件
修改eurekaClient端8001
