5.1 Eureka集群环境配置

---

我们 尝试 搭建 三个 注册中心。然后 让它们 互相注册和依赖。如果一旦 有一个 注册中心 崩了，我们也不怕。可以从其它 注册中心里面 注册和引用服务。首先为了 Eureka 的识别和测试方便，我们先把 三个 端口 7001、7002、7003 在 host 文件中 添加 不同的映射 地址。

C:\Windows\System32\drivers\etc

其实对于 Eureka 来说 是很简单的！如果有多个注册中心，那么我们只需要 配置 eureka.client.service-url.defaultZone 就可以了。

1. 配置的格式：除自己本身 的 url.A,url.B,urlC ……

7001 注册中心的配置

server:
  port: 7001

# Eureka 配置

eureka:
  instance:
    hostname: eureka7001.com # Eureka 服务端的实例名
  client:
    register-with-eureka: false # 表示是否向 eureka 注册中心注册自己
    fetch-registry: false # fetch-registry 如果为 false 则 表示 自己为 注册中心
    service-url: # url 地址
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
1
2
3
4
5
6
7
8
9
10
11
12
13

7002 注册中心的配置

server:
  port: 7002

# Eureka 配置

eureka:
  instance:
    hostname: eureka7002.com # Eureka 服务端的实例名
  client:
    register-with-eureka: false # 表示是否向 eureka 注册中心注册自己
    fetch-registry: false # fetch-registry 如果为 false 则 表示 自己为 注册中心
    service-url: # url 地址
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/
1
2
3
4
5
6
7
8
9
10
11
12
13

7003 注册中心的配置

server:
  port: 7003

# Eureka 配置

eureka:
  instance:
    hostname: eureka7003.com # Eureka 服务端的实例名
  client:
    register-with-eureka: false # 表示是否向 eureka 注册中心注册自己
    fetch-registry: false # fetch-registry 如果为 false 则 表示 自己为 注册中心
    service-url: # url 地址
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/
1
2
3
4
5
6
7
8
9
10
11
12
13

为什么不注册 自己的 URL 呢？

因为 Eureka 会自动根据 其它的 注册中心，识别到 自己的 URL，进行同步注册。

2. 提供者 注册服务 需要 注册到 三个注册中心

#Eureka 的配置，只需要配置 服务 注册到 哪里就行了
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka,http://eureka7003.com:7003/eureka
1
2
3
4
5
6

现在 我们可以尝试 关闭掉 其中 一个 注册中心，来模拟 崩掉的情况。

你会发现其他 两个注册 中心 活的 好好的，而且 也 有注册 过来的服务。

无论 是否使用 Eureka 我们的消费者 其实 都是 不需要 改动的。因为 它 还是 通过 Rest url 去拿。所以 改动什么呢？不太清楚。

---

5.2 Eureka CAP

• C（Consistency）：强一致性
• A（Availability）：可用性
• P（Partition tolerance）：分区容错性

这三个 是无法同时满足的。所以 出现了 三进二！

CAP 的三进二：CA、AP、CP

CAP 理论的核心

• 一个分布式系统不可能同时很好的满足一致性、可用性和分区容错性这三个需求。
• 根据 CAP 原理，将 NoSQL 数据库 分成了 满足 CA、CP、AP 原则的三大类：
  • CA：单店集群，满足一致性，可用性的系统，通常可扩展性较差。
  • CP：满足一致性，分区容错性的系统，通常性能不是特别高。
  • AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些。

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

• Zookeeper 保证的是 CP！
• Eureka 保证的是 AP！