注册中心机制
服务启动过程
服务端在启动的时候需要在注册中心注册自身的信息。那么问题来了，服务端怎么知道注册中心在哪？
答案是通过域名+端口，或是IP+端口。如果服务端无法连上注册中心的话，服务端就直接退出了。
服务注册什么数据
服务端在注册的时候，究竟注册了什么信息？
- 定位信息：一般是IP+端口。
- 其他信息：和微服务框架的具体功能有关系，需要借助注册中心传递一些信息。比如支持分组功能的微服务框架里，服务端节点就会在注册信息里带上分组信息。比如基于权重的轮询，服务端就把权重写到注册中心里；比如标签路由，如何知道服务端有哪些标签，也是通过注册中心来获取的。其他信息一般都是用来搞服务治理的。
服务端和注册中心保持心跳
心跳有两种模式：
- 服务端主动：服务端每隔一段时间就向注册中心发一个心跳，注册中心可以选择应答也可以选择不应大。
- 注册中心主动：注册中心会朝着所有注册的服务端节点发送心跳。
注：不管是哪种方式，发送信息的时候只要没有收到网络错误，就认为联系是正常的，可以不用等待回应。
如果心跳失败，注册中心会判定服务端节点已经崩溃，然后通知客户端不再使用该节点。
思考：方式1更好。因为注册中心很容易成为瓶颈，如果注册中心有1w个服务端节点，给1w个服务端节点发信号是一件很庞大的事情，需要维持计时器，还有并行的时间问题。
心跳机制
本质上来说，注册中心和服务端的整个机制，可以看做是租约，心跳就是续租。
那么在租约里面讨论的心跳有关的问题，在注册机制这里一样要讨论。
• 心跳间隔多长？
• 如何判定节点连不上了？是一次心跳就连不上，还是多次心跳连不上？
正常来说，这些都是跟业务有关的。核心就是：
• 间隔越短，心跳越频繁，注册中心的压力越大。
• 次数越少，越快发现服务端节点崩溃，但是难以应对偶发性心跳失败；次数越多，越慢发现服务端节点崩溃，但是可以避免一些偶发性心跳失败的问题。
高级的心跳机制
很少采用，性价比不高。
• 双向心跳。也就是服务端会主动发心跳，注册中心也会主动发心跳。
• 单向心跳失败之后，另外一边主动发起心跳。例如说在正常情况下，都是服务端主动发心跳给注册中心，但是注册中心在一段时间没有收到服务端的心跳之后，会主动发起心跳。
服务下线
如果服务端要关闭了，需要通知注册中心，注册中心通知客户端。客户端将该节点从可用节点列表里挪走
优雅下线
下线还有一些细节需要思考：服务端能不能 在告诉注册中心自己下线了，立刻就退出？ 答案是不能。因为这个时候服务端上可能还有一 些请求正在处理，而网络上也还有客户端正在发请求。 因此实际上，服务端下线的过程要更加复杂一点。具体步骤如下：
- 首先要通知注册中心，服务端节点要下线了。
- 而后，服务端节点不再接受新请求，包括在网络中读取了一半的请求，也会在读完之后，直接拒绝。不会交给后端业务代码处理。同时，服务端需要等待正在处理的请求结束。如果该服务端节点上还有类似于定时任务之类的东西，也要等待运行结束。
- 等服务端已经接收的请求处理完毕，服务端就会结束运行。
- 进一步考虑部分请求运行太长时间，或者定时任务长时间不能结束，所以服务端节点的整个退出过程也会有超时控制，超过超时时间，就会直接退出。
客户端
根据微服务框架的设计，客户端发起服务发现有两个时机：
- 客户端启动的时候。这种设计一般是在客户端从配置文件，或者注册接口，拿到了所有的需要使用的微服务。于是可以在初始化的过程中直接执行服务发现，如果服务发现失败则客户端不会启动。
- 客户端启动的时候，并没有去做服务发现。而是在第一次调用某个服务的时候，执行服务发现。 循环依赖的时候一般用这种。
同样，注册中心和客户端之间也要保持心跳，这样可以保证在服务端数据变更的时候，能够连上客户端， 并且通知客户端。
