Skip to content

Commit aa5dbcd

Browse files
ipipmanipipman
committed
fix readme style
1 parent 8ee2d72 commit aa5dbcd

File tree

2 files changed

+30
-11
lines changed

2 files changed

+30
-11
lines changed

‎dubbo-consul-sample/README.md‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,10 +9,12 @@ CAP理论是分布式场景绕不开的重要理论
99
<img src="https://ipman-blog-1304583208.cos.ap-nanjing.myqcloud.com/dubbo/1081608882430_.pic_hd.jpg" width = "400" height = "280" alt="图片名称" align=center />
1010

1111
关于分区容忍性P的理解，大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition），分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
12+
1213
关于提高分区容忍性的办法，就是把同一份数据复制到多个节点上，分布到各个区里，容忍度就提高了。一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。
1314

1415
剩下CAP的C和A无法同时做到，原因是
1516
如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果就会有差异，但数据同步会消耗时间，期间可用性就会降低。
17+
1618
如果A是第一需求的话，那么只要有一个服务在，就能正常接受请求，但是对于返回结果变化不能保证一致性，原因是在分布式部署的时候，不能保障每个环境下处理速度。
1719

1820
### 主流注册中心或配置中心产品一致性对比
@@ -27,10 +29,13 @@ CAP理论是分布式场景绕不开的重要理论
2729
从Zookeeper的实际应用情况来看，在使用Zookeeper获取服务列表时，如果此时Zookeeper集群中的Leader节点宕了，该集群要进行Leader的重新选举，又或者Zookeeper集群中半数节点不可用，都将无法处理请求，所以说Zookeeper不能保证服务可用性。
2830

2931
在大部分分布式环境中，尤其是设计数据存储的场景，数据一致性是首先要保证的，这也是Zookeeper设计CP原则的另一个原因。
32+
3033
但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不同，也并不会造成灾难性后果。
34+
3135
因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到了可能不正确的服务提供者信息，也要胜过因无法获取实例而不去消费，导致系统异常要好。（消费者消费不正确的提供者信息可以进行补偿重试机制）
3236

3337
当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，问题在于，选举Leader的时间太长，30～120s，而且选举期间整个zk集群是不可用的，这就导致整个选举期间注册服务瘫痪。
38+
3439
尤其在云部署环境下，因为网络问题使得ZK集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是无法容忍的。
3540

3641
#### Spring Cloud Eureka -> AP
@@ -54,6 +59,7 @@ Eureka Server 也可以运行多个实例来构建集群，解决单点问题，
5459
#### Alibaba Nacos -> AP/CP
5560

5661
Nacos是阿里开源的一个产品，主要针对微服务架构中的服务发现、配置管理、服务治理的综合性解决方案；
62+
5763
Nacos支持两种方式的注册中心，持久化和非持久化存储服务信息。
5864
> - 非持久化直接存储Nacos服务节点的内存中，并且服务节点采用去中心话的思想，服务节点采用Hash分片存储注册信息；
5965
> - 持久化使用Raft协议选举Master节点，同样采用半同步机制将数据存储在Leader节点上；
@@ -63,12 +69,14 @@ Nacos同时支持持久化和非持久化存储，也就是支持CAP原则中的
6369
#### HashiCorp Consul -> CP
6470

6571
Consul是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul使用Go编写，因此具有天然的移植性。
72+
6673
Consul内置了服务注册与发现框架、分布式一致性协议实现、健康检查、Key/Value存储、多数据中心方案。
6774

6875
Consul遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比Zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就下降了，例如服务注册的时间会稍微长一些，因为Consul的Raft协议要求必须过半数的节点都写入成功才算成功，在Leader挂掉了之后，重新选出Leader之前会导致Consul不可用。
6976

7077
Consul Template
7178
Consul 默认服务调用者需要依赖Consul SDK来发现服务，这就无法保证对应用的零入侵性。
79+
7280
通过Consul Template，可以定时从Consul集群获取最新的服务提供者列表并刷新Load Balance配置，这样对于服务调用者来说，只需要配置一个统一的服务调用地址即可。
7381

7482
Consul强一致性（C）带来的是：
@@ -85,7 +93,9 @@ Eureka保证高可用（A）和最终一致性：
8593
<img src="https://ipman-blog-1304583208.cos.ap-nanjing.myqcloud.com/dubbo/1101608976609_.pic_hd.jpg" width = "700" height = "590" alt="图片名称" align=center />
8694

8795
首先Consul支持多数据中心，如图上面有两个DataCenter，他们通过Intenet进行通信，为了提高通信效率，只有Server节点参与到了跨数据中心通信。
96+
8897
在Consul单数据中心中，节点分为Master和Client两种（它们也称为Agent节点），Master节点用于存储数据，Client节点负责健康状态检查和转发数据请求给Master节点。
98+
8999
Master节点采用Raft算法保证多个Master节点数据一致性，Master节点们分为一个Leader和多个Follower，Leader节点会将数据同步给所有的Follower节点，当Leader节点宕掉时会采用选举机制重新选举Leader节点，但是选举期间是不能提供服务的（也就是不能保证可用性）。
90100

91101
集群内的Consul节点通过gossip协议维护成员关系，也就是说任一节点都能知道整个Consul集群中还有其他哪些节点，还包括这些节点的信息，如这个节点是Master节点还是Client节点。

‎springcloud-consul-config-sample/README.md‎

Lines changed: 20 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -9,10 +9,12 @@ CAP理论是分布式场景绕不开的重要理论
99
<img src="https://ipman-blog-1304583208.cos.ap-nanjing.myqcloud.com/dubbo/1081608882430_.pic_hd.jpg" width = "400" height = "280" alt="图片名称" align=center />
1010

1111
关于分区容忍性P的理解，大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition），分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
12+
1213
关于提高分区容忍性的办法，就是把同一份数据复制到多个节点上，分布到各个区里，容忍度就提高了。一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。
1314

1415
剩下CAP的C和A无法同时做到，原因是
1516
如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果就会有差异，但数据同步会消耗时间，期间可用性就会降低。
17+
1618
如果A是第一需求的话，那么只要有一个服务在，就能正常接受请求，但是对于返回结果变化不能保证一致性，原因是在分布式部署的时候，不能保障每个环境下处理速度。
1719

1820
### 主流注册中心或配置中心产品一致性对比
@@ -27,10 +29,13 @@ CAP理论是分布式场景绕不开的重要理论
2729
从Zookeeper的实际应用情况来看，在使用Zookeeper获取服务列表时，如果此时Zookeeper集群中的Leader节点宕了，该集群要进行Leader的重新选举，又或者Zookeeper集群中半数节点不可用，都将无法处理请求，所以说Zookeeper不能保证服务可用性。
2830

2931
在大部分分布式环境中，尤其是设计数据存储的场景，数据一致性是首先要保证的，这也是Zookeeper设计CP原则的另一个原因。
32+
3033
但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不同，也并不会造成灾难性后果。
34+
3135
因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到了可能不正确的服务提供者信息，也要胜过因无法获取实例而不去消费，导致系统异常要好。（消费者消费不正确的提供者信息可以进行补偿重试机制）
3236

3337
当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，问题在于，选举Leader的时间太长，30～120s，而且选举期间整个zk集群是不可用的，这就导致整个选举期间注册服务瘫痪。
38+
3439
尤其在云部署环境下，因为网络问题使得ZK集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是无法容忍的。
3540

3641
#### Spring Cloud Eureka -> AP
@@ -63,12 +68,14 @@ Nacos同时支持持久化和非持久化存储，也就是支持CAP原则中的
6368
#### HashiCorp Consul -> CP
6469

6570
Consul是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul使用Go编写，因此具有天然的移植性。
71+
6672
Consul内置了服务注册与发现框架、分布式一致性协议实现、健康检查、Key/Value存储、多数据中心方案。
6773

6874
Consul遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比Zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就下降了，例如服务注册的时间会稍微长一些，因为Consul的Raft协议要求必须过半数的节点都写入成功才算成功，在Leader挂掉了之后，重新选出Leader之前会导致Consul不可用。
6975

7076
Consul Template
7177
Consul 默认服务调用者需要依赖Consul SDK来发现服务，这就无法保证对应用的零入侵性。
78+
7279
通过Consul Template，可以定时从Consul集群获取最新的服务提供者列表并刷新Load Balance配置，这样对于服务调用者来说，只需要配置一个统一的服务调用地址即可。
7380

7481
Consul强一致性（C）带来的是：
@@ -85,7 +92,9 @@ Eureka保证高可用（A）和最终一致性：
8592
<img src="https://ipman-blog-1304583208.cos.ap-nanjing.myqcloud.com/dubbo/1101608976609_.pic_hd.jpg" width = "700" height = "590" alt="图片名称" align=center />
8693

8794
首先Consul支持多数据中心，如图上面有两个DataCenter，他们通过Intenet进行通信，为了提高通信效率，只有Server节点参与到了跨数据中心通信。
95+
8896
在Consul单数据中心中，节点分为Master和Client两种（它们也称为Agent节点），Master节点用于存储数据，Client节点负责健康状态检查和转发数据请求给Master节点。
97+
8998
Master节点采用Raft算法保证多个Master节点数据一致性，Master节点们分为一个Leader和多个Follower，Leader节点会将数据同步给所有的Follower节点，当Leader节点宕掉时会采用选举机制重新选举Leader节点，但是选举期间是不能提供服务的（也就是不能保证可用性）。
9099

91100
集群内的Consul节点通过gossip协议维护成员关系，也就是说任一节点都能知道整个Consul集群中还有其他哪些节点，还包括这些节点的信息，如这个节点是Master节点还是Client节点。
@@ -165,17 +174,17 @@ Conusl提供了一个Key/Value Store可以用于动态配置；
165174

166175
#### 1.添加Consul依赖，Springboot使用2.1.7版本（不同版本可能存在兼容问题，这个需要注意！）
167176
```java
168-
<dependency>
169-
<groupId>org.springframework.cloud</groupId>
170-
<artifactId>spring-cloud-starter-consul-discovery</artifactId>
171-
<version>2.1.4.RELEASE</version>
172-
</dependency>
173-
174-
<dependency>
175-
<groupId>org.springframework.cloud</groupId>
176-
<artifactId>spring-cloud-starter-consul-config</artifactId>
177-
<version>2.1.4.RELEASE</version>
178-
</dependency>
177+
<dependency>
178+
<groupId>org.springframework.cloud</groupId>
179+
<artifactId>spring-cloud-starter-consul-discovery</artifactId>
180+
<version>2.1.4.RELEASE</version>
181+
</dependency>
182+
183+
<dependency>
184+
<groupId>org.springframework.cloud</groupId>
185+
<artifactId>spring-cloud-starter-consul-config</artifactId>
186+
<version>2.1.4.RELEASE</version>
187+
</dependency>
179188
```
180189

181190
#### 2.添加Spring环境配置（application.properties）、Consul配置（bootstrap.properties）

0 commit comments

Comments
 (0)