文章目录
- 前言
- 一、Eureka server的集群配置
- 1. 原理说明
- 2. 新建microservicecloud-eureka-7002/microservicecloud-eureka-7003 module 工程
- 1）以microservicecloud-eureka-7002为例
- 2）创建microservicecloud-eureka-7003
- 3. 按照7001为模板粘贴POM
- 1）7002的pom文件
- 2）7003的pom文件
- 4. 修改7002和7003的主启动类
- 5. 修改映射配置
- 1) 找到C:\Windows\System32\drivers\etc路径下的hosts文件
- 2) 修改映射配置添加进hosts文件
- 6. 3台eureka服务器的yml配置
- 1) 7001
- 2) 7002
- 3) 7003
- 7. microservicecloud-provider-dept-8001微服务发布到上面3台eureka集群配置中
- 8. 测试
- 二、 作为服务注册中心，Eureka比Zookeeper好在哪里
- 1. 作为服务注册中心，Eureka比Zookeeper好在哪里
- 2. Zookeeper保证CP
- 3. Eureka保证AP
前言
想学习本博客案例，需要先看下上一篇的博客：
因为案例的都是循序渐进的。案例的顺序：
- 微服务讲诉->
- 父工程maven的module建立和rest风格的请求->
- eureka的学习、三大组件，服务注册与消费->
- eureka的集群操作 ->
- ribbon的负载均衡。
- feign的负载均衡
- Hystrix断路器
- Zuul路由网关
- SpringCloud Config分布式配置中心
一、Eureka server的集群配置
1. 原理说明
上图是来自eureka的官方架构图，这是基于集群配置的eureka；
- 处于不同节点的eureka通过Replicate进行数据同步
- Application Service为服务提供者
- Application Client为服务消费者
- Make Remote Call完成一次服务调用
服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步。当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。
当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。
服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。
2. 新建microservicecloud-eureka-7002/microservicecloud-eureka-7003 module 工程
1）以microservicecloud-eureka-7002为例
输入 artifactId为 microservicecloud-eureka-7002 即可，知道finish为止。
2）创建microservicecloud-eureka-7003
以microservicecloud-eureka-7003 仿照 7002即可
3. 按照7001为模板粘贴POM
1）7002的pom文件
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>microservicecloud</artifactId>
<groupId>com.atguigu.springcloud</groupId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>microservicecloud-eureka-7002</artifactId>
<dependencies>
<!--eureka-server服务端 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka-server</artifactId>
<version>1.2.6.RELEASE</version>
</dependency>
<!-- 修改后立即生效，热部署 -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>springloaded</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
</dependency>
</dependencies>
</project>
2）7003的pom文件
与7002 依赖一样。
4. 修改7002和7003的主启动类
以7002 为例：
package com.atguigu.springcloud.springcloud;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
@SpringBootApplication
@EnableEurekaServer //开启 eureka的客户端
public class EurekaServer7002_App {
public static void main(String[] args) {
SpringApplication.run(EurekaServer7002_App.class, args);
}
}
5. 修改映射配置
1) 找到C:\Windows\System32\drivers\etc路径下的hosts文件
2) 修改映射配置添加进hosts文件
6. 3台eureka服务器的yml配置
1) 7001
server:
port: 7001
eureka:
instance:
hostname: eureka7001.com #eureka服务端的实例名称
client:
register-with-eureka: false #false表示不向注册中心注册自己。
fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
service-url:
#单机 defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址（单机）。
defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
2) 7002
server:
port: 7002
eureka:
instance:
hostname: eureka7002.com #eureka服务端的实例名称
client:
register-with-eureka: false #false表示不向注册中心注册自己。
fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
service-url:
#defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址。
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/
3) 7003
server:
port: 7003
eureka:
instance:
hostname: eureka7003.com #eureka服务端的实例名称
client:
register-with-eureka: false #false表示不向注册中心注册自己。
fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
service-url:
#defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址。
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/
7. microservicecloud-provider-dept-8001微服务发布到上面3台eureka集群配置中
主要的注册配置是：
eureka.client.service-url.defaultZone = 三个值
server:
port: 8001
mybatis:
config-location: classpath:mybatis/mybatis.cfg.xml #mybatis所在路径
type-aliases-package: com.atguigu.springcloud.entities #entity别名类
mapper-locations:
- classpath:mybatis/mapper/**/*.xml #mapper映射文件
spring:
application:
name: microservicecloud-dept
datasource:
type: com.alibaba.druid.pool.DruidDataSource
driver-class-name: org.gjt.mm.mysql.Driver
url: jdbc:mysql://localhost:3306/cloudDB01
username: root
password: 123456
dbcp2:
min-idle: 5
initial-size: 5
max-total: 5
max-wait-millis: 200
eureka:
client: #客户端注册进eureka服务列表内
service-url:
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
instance:
instance-id: microservicecloud-dept8001 #自定义服务名称信息
prefer-ip-address: true #访问路径可以显示IP地址
info:
app.name: atguigu-microservicecloud
company.name: www.atguigu.com
build.artifactId: $project.artifactId$
build.version: $project.version$
8. 测试
进入eureka 的 服务器页面：
http://eureka7001.com:7001 http://eureka7001.com:7002 http://eureka7001.com:7003 还可以点击查看 各自 集群中的同一个微服务信息 进行查看。
http://eureka7001.com:7001
http://eureka7001.com:7002
http://eureka7001.com:7003
二、 作为服务注册中心，Eureka比Zookeeper好在哪里
1. 作为服务注册中心，Eureka比Zookeeper好在哪里
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
因此
Zookeeper保证的是CP,
Eureka则是AP。
2. Zookeeper保证CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。
但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
3. Eureka保证AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
- Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
- Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
- 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
