服务注册与发现在微服务架构中处于一个非常核心的地位，也是面试中的常见问题。不过因为微服务架构大行其道，现在我们多少都能回答出来一些服务注册与发现的内容，也因此不容易在面试中刷出亮点，拉开和其他面试者的差距。
本文将深入剖析服务注册与发现，学习服务注册与发现的基本模型，然后在服务端崩溃检测、客户端容错和注册中心选型三个角度找到高可用微服务架构的亮点。
前置知识
为什么会需要服务注册与发现呢？
设想这样一个场景，你的服务部署在不同的机房、不同的机器上，监听不同的端口。现在你的客户端收到了一个请求，要发送给服务端，那么你的客户端怎么知道哪些服务端能够处理这个请求呢？
基本的服务注册与发现模型如下所示：
图里的步骤如下：
服务端启动的时候，需要往注册中心里注册自身的信息，主要是定位信息。
注册成功之后，注册中心和服务端要保持心跳。
客户端第一个发起对某个服务的调用之前，要找注册中心获得所有可用服务节点列表，随后客户端会在本地缓存每个服务对应的可用节点列表。
客户端和注册中心要保持心跳和数据同步，后续服务端有任何变动，注册中心都会通知客户端，客户端会更新本地的可用节点列表
客户端发送请求
服务端返回响应
上面的步骤你都可以看作是一个正向的步骤，而对应的反向步骤则是指服务端下线的过程。
服务端下线的过程可以总结为四步：
服务端通知注册中心自己准备下线了
注册中心通知客户端某个服务端下线了
客户端收到通知之后，新来的请求就不会给服务端发过去
服务端等待一段时间之后，暂停服务并下线
需要注意的是，服务端必须等待一段时间才能下线。因为从它通知注册中心自己要下线，到客户端收到通知，是有一段时间延时的，这段延时就是服务端要等待的最小时间。
把整个模型看作是三角形，三个顶点分别是客户端、注册中心和服务端。三角形的三条边分别是客户端-注册中心，注册中心-服务端，客户端-服务端。而后面我们讨论的高可用方案，无论是思考三角形的任何一个顶点，或者任何一条边出问题了怎么办。
