由 dawei 老实说，这个问题并不难。
如果你做过微服务开发，这个面试题应该能够立马答出来，如果你没做过微服务开发，但是学过一些 Spring Cloud 组件的用法，这个问题可能要稍微想一下，但是也应该能够答出来。
今天就来和大家说说这个问题。
1.实践一下
这种问题，听别人讲 N 遍，不如自己手动实践一遍记得清楚。
大家可以快速搭建一个 Eureka 服务注册中心，然后搭建一个服务消费者和服务提供者，将两个服务注册到 Eureka 上去，最后在服务消费者上面简单的调用一下服务提供者。这个过程很简单，相信大家稍微学过 Spring Cloud 的小伙伴都能搞定，如果搞不定，可以参考松哥的视频(Spring Boot + Vue + Spring Cloud 系列视频教程))。
服务调通之后，接下来关闭 Eureka，注意不要关闭服务提供者和服务消费者，关闭之后，继续用服务消费者调用服务提供者，「这个时候你会惊奇的发现，服务竟然还能调通!」
我来说一下这个流程：
Eureka 作为一个服务注册中心启动。
Provider 和 Consumer 分别作为服务启动，并且注册到 Eureka 上面去，以 provider 为例，provider 注册时会告诉 eureka，我叫 provider，我的地址是 xx.xx.xx.xx，我的端口是 xx，我的 xx 是 xx，就是说，provider 会将自己的一些元数据信息告诉 eureka;同理，consumer 也是如此。
接下来，consumer 要调用 provider 的接口，但是它不知道 provider 的地址是什么，他只知道要调用的服务叫 provider，于是 consumer 找到 eureka，从 eureka 上查询出来 provider 的具体地址和端口，这个具体的地址和端口，可能是一个，也可能是多个(集群化部署)。
consumer 获取到 provider 的地址和端口之后，接下来就直接去调用 provider 了。
从上面一个流程图中，大家可以看出来，一旦 consumer 获取到 provider 的具体地址，接下来的调用其实就没有 eureka 什么事了。
所以，我们说一旦 Eureka 挂了，微服务是可以调通的，「但是是有前提的」。
什么前提?就是 provider 的地址没变!如果 provider 换了一个 IP 地址或者端口，这个时候，consumer 就无法及时感知到这种变化，就会调不通。当 Eureka 没有挂掉的时候，provider 的 IP 变化这种事情，可以通过 Eureka 让 consumer 感知到，进而对调用地址作出调整，现在 Eureka 挂了，consumer 就无法感知了。
文章既然都写到这儿了，我们就来顺便说下 Spring Cloud 在这里涉及到的一些原理。