本次测试目的，主要针对应用负载集群 注册中心集群测试
如下图，启动了3个eureka服务中心，3个服务提供者，2个服务调用者
1. 应用负载集群测试
服务调用效果，可以看到默认是轮询负载机制，每次调用的服务是不一样的
测试代码下载：http://download.csdn.net/detail/stonexmx/9774537
停掉2203端口的provider，注册中心有一定的延迟，时间没注意计时，大概需要几分钟
然后访问出现连接不上的提示，后续就不会再出现了，后续访问就不会在出现了
后续的访问 就不会出现2203的请求了
把 2203再次启动后，就又可以参与负载提供服务了。这里就不在贴图了
2. eureka 集群
停掉其中的2103、2102端口的eureka server。同上面一样，注册中心有一定的延迟，时间没注意计时，大概需要几分钟。
再次访问服务，进行服务调用，服务均能正常调用，就不都贴图了
尝试停掉所有的 eureka server，惊讶的发下竟然还能访问，是的，就是把注册中心全部干掉，还是能访问。
此处感觉可能服务端已经缓存了注册中心绑定的服务地址列表，所有能够正常访问。
咱们在做一个尝试，再起一个2204的provider，应该是不能够参与负载的，因为没有注册中心
下图是提供服务的应用，可以看到已经起来，并能进行访问。
但是通过consumer 访问，发现 根本没有2204参与负载，这是很正常的，因为没有了注册中心，consumer不知道新的服务进来
咱们试着启动一个注册中心 2101，下图可以看到注册中心加入的服务，2204也在其中。
现在再来访问consumer，可以看到 2204参与到负载了，这就是咱们想要的结果
测试例子中的代码地址：http://download.csdn.net/detail/stonexmx/9774537
