Spring Cloud Eureka 集群测试报告一：

Spring Cloud Eureka 集群测试报告一：

前言：

由于小弟水平有限，所做的测试可能不够完善，欢迎各路大神批评指正。

测试1.分别占用7001,7002,7003三个端口，来启动搭建注册中心集群，每个集群的都有如下配置：

在eureka项目的application.properties文件中默认注册当前服务并且获取注册的服务列表：

#------------是否将当前eureka server注册到自身的注册中心中
#eureka.client.register-with-eureka=true
#------------师傅获取注册中心中注册的服务列表
#eureka.client.fetch-registry=true

★注册步骤一：

s1) 一个服务提供者注册到端口为7001的eureka server中；
s2) 一个服务消费者注册到端口为7002的eureka server中；

测试目的：

当【服务消费者】与【服务提供者】注册的节点不一样的时候，测试服务消费者是【否能够获取到】服务提供者提供的服务？

预测结论：

由于在eureka server集群中，节点之间能够完成注册列表拷贝，会将所有注册到注册服务中心的列表进行复制共享，
所以理论上按照测试步骤1进行注册配置的consumer能够获取到provider提供的服务（服务发现可行）。

实际运行结论：

consumer能够获取到provider提供的服务，表明预测正确，测试通过：
通过注册机群中不同节点注册进去的服务，相互之间能够正常通信，服务发现和服务获取没有问题。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

★注册步骤二：

s1) 一个服务提供者注册到端口为7001的eureka server中；
s2) 一个服务消费者注册到端口为7002的eureka server中；
s3) 当完成所有服务注册后，关闭所有注册中心的集群节点；

标题测试目的：

当eureka集群【全部宕机】，测试服务消费者是否能够获取到服务提供者提供的服务？

预测结论：

当eureka client 完成在eureka server中的注册后，eureka会将服务的注册列表复制到客户端，
所以所有的client都能够获取到其他服务的地址；
既然每个client都拥有的注册列表，那么今后的访问不需要再经过eureka server（假定所有client的ip不变动的前提下），
所以结论是服务可达

实际运行结论：

运行结果与预测结论一致。
当eureka client完成注册以后，会从注册中复制注册列表到client端，
则今后各个微服务之间的调用（假定所有client的ip不变动的前提下）不受注册中心宕机影响

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

★注册步骤三：

s1) 一个eureka client（服务消费者）注册到端口为7002的eureka server中；
s2) 完成第一个服务注册后，关闭端口为7002的eureka server；
s3) 把另一个eureka clien（服务提供者）注册到端口为7001的eureka server中；

测试目的：

注册节点不同（每个服务都只注册在集群中某一个节点上），当某个节点宕机后，之前注册在它上面的服务，
能否发现后新注册进来（通过不同注册节点）的服务。

预测结论：

当第一个eureka client（服务消费者） 完成在7002 eureka server中的注册后，
eureka server会将服务的注册列表在集群中复制， 
7002 eureka server会将服务的注册列表复制到第一个client（服务消费者）

所以当第二个client（服务提供者）注册到7001的eureka server节点后，
第二个client（服务提供者）是能够通过7001的eureka server节点获取到第一个节点的服务的；

同理，虽然7002的eureka server节点已结宕机，但是由于7001的eureka server节点能够发现第一个client，
也能够将第二个节点注册后的列表复制给第一个节点
所以，服务依旧可达

实际运行结论：

测试不通过，原因，预测结论错误，服务不可达！
猜想原因：
当第一个eureka client（服务消费者） 完成在7002 eureka server中的注册后，
eureka server会将服务的注册列表在集群中复制，7002 eureka server会将服务的注册列表复制到第一个client（服务消费者）

所以当第二个client（服务提供者）注册到7001的eureka server节点后，
第二个client（服务提供者）是能够通过7001的eureka server节点获取到第一个节点的服务的；

从这里开始，与预测结果不一致：
虽然，此时【第二个client（服务提供者）能够发现第一个client（服务消费者）】；
但是，由于7002 eureka server已经宕机，第一个client（服务消费者）不能够通过7002 eureka server获取到注册列表，
所以没法发现第二个client（服务提供者）；
所以，服务最终不可达。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

★注册步骤四（为了验证步骤三的结论，设计注册步骤四）：

s1) 一个eureka client（服务提供者）注册到端口为7001的eureka server中；
s2) 完成第一个服务注册后，关闭端口为7001的eureka server；
s2) 把另一个eureka clien（服务消费者）注册到端口为7002的eureka server中；

预测结论：

当第一个eureka client（服务提供者） 完成在7001 eureka server中的注册后，
7001 eureka server会将服务的注册列表在集群中复制，7001 eureka server会将服务的注册列表复制到第一个client（服务提供者）

虽然，由于7001 eureka server已经宕机，第一个client（服务提供者）不能够通过7001 eureka server获取到注册列表，
所以没法发现第二个client（服务消费者）；
但是，当第二个client（服务消费者）注册到7002的eureka server节点后，
第二个client（服务消费者）是能够通过7002的eureka server节点获取到第一个节点的服务的；
所以，服务可达。

实际运行结论：

测试通过，与预测结论完全一致，当之前的服务与对应的注册节点断掉之后，则无法再通过之前的注册节点更新注册列表，
所以它将没法发现新加进来的服务（从别的注册节点进来的）

★★★★★以上四个步骤测试后的总结论：

1.【注册节点集群】中的节点间是能够相互通信，并且【通过注册表复制】会【共享注册表】的	；
2.【每个注册节点】也会【通过注册表复制】将【注册表共享】到所有的服务；
3.【服务之间】的通信只依赖【注册表】，不依赖其注册的节点/注册节点集群；
但是，想获得注册表还是需要依赖节点/节点集群；
4.为了解决服务之间由于【注册节点宕机】造成服务不可达的问题，我们可以让【服务直接注册到所有的节点上】，防止节点不可达。