高可用
不出所料的话，面试官可能追问：“服务注册与发现怎么保证高可用呢？”。那么你可以回答三个点，高可用的服务注册与发现要围绕注册服务端崩溃检测、客户端容错和注册中心选型三个方面进行。
服务端崩溃检测
我在基本模型里面说到在正常情况下，服务端下线都需要通知注册中心。那么万一服务都安宕机了呢？这种情况下，服务都安是没法通知注册中心的，注册中心自然也就不会通知客户端。那么客户端就会继续把请求发送给服务都安，这些请求显然都会失败。
因此为了提高可用性，需要让注册中心尽快发现服务端已经崩溃了，然后通知客户端。所以问题的关键在于注册中心怎么判断服务已经崩溃了。
服务端之后注册中心和服务端之间的心跳就无法继续保持了。所以可以得出一个简单的结论：如果注册中心和服务端之间的心跳断了，就认为服务端已经崩溃了。
但是，如果注册中心和服务端之间的网络出现偶发性的抖动，那么心跳也会失败。此时服务端并没有真的崩溃，还活得好好的。
显然，心跳断了则服务端崩溃的判断并不能成立。这时候你可能想到能不能多发几次心跳呢？答案是可以，但是次数越多，心跳间隔越长，注册中心断定服务已经崩溃的时间就越长。而时间越长，就有越多请求发送给服务端。万一这个时候服务端真的崩溃了，这些请求都会失败。所以这就陷入两难境地了。要么是误以为服务端崩溃，要么误以为服务端还活着。
那么怎么走出这个窘境呢？
一方面，注册中心和服务端进行心跳的时候失败了，就要立刻通知客户端该服务端已经不可用了，那么客户端就不会再发请求过来。
另外一方面，注册中心还要继续往服务端发心跳。如果只是偶发性的心跳失败，那么注册中心后面心跳是肯定能够连上的，这时候注册中心再通知客户端这个服务端是可用的。
不过注册中心并不是无限发心跳直到连接上，而且发了一段时间之后发现心跳还是失败就不发了，这意味着注册中心认定服务端彻底崩溃了。在彻底崩溃的场景下，注册中心不需要再次通知客户端，因为在之前注册中心就已经通知过了。
所以关键词就是心跳，你可以这样回答。
