在前两篇文章中，我们多次讲到了注册中心。在Provider中，我们讲到在服务注册的过程中，需要注册到注册中心。在Consumer中，我们讲到从注册中心获取到Provider地址。可见注册中心是RPC中重要的组成部分。那么注册中心，担任哪些职责呢？注册中心需要有解决哪些问题呢？
注册中心的基本功能
我们先来看下注册中心在服务调用中的位置
从以上可以看出，注册中心有以下两个基本职责：
- 服务地址注册，服务提供者主要把服务地址注册到地址中心。在注册中心聚合了服务提供者的地址列表。能够提供给服务调用者使用
- 服务地址发现，注册中心需要为服务调用者提供，服务提供者的地址。并且能够感知到服务提供者的变化，并及时的更新地址列表，并通知给调用者
从以上可以看出，注册中心需要提供一个注册中心服务，一个注册中心客户端。注册中心负责感知服务提供者地址是否在线，服务地址列表的聚合。在服务地址发生变更时及时的通知服务的调用者。注册中心的客户端，在提供者端，负责将提供者的服务地址主动的通知给服务端，并且在服务发生了变更时及时的更新服务端的信息。在消费者端，负责从服务端拉去服务地址，并且缓存在本地。
从以上可以看出，对于注册中心来说，需要有服务提供者的地址、服务消费者的地址，以及服务消费者和服务的订阅关系。
服务的优雅上下线
实现优雅的上下线之前，我们先解决者怎么感知服务的上线和下线的问题
注册中心感知服务上线，在服务提供者时，会主动的通知给注册中心。在注册中心拿到新的服务地址之后，会通知给调用者客户端。这个上线过程比较简单。那么对于服务的下线如何感知呢？
服务下线有两种情况，一种是主动下线，另一种是心跳包检测服务下线。主动下线的操作比较可靠。心跳包检测到服务下线就有可能产生误判。有以下两种情况：
- 当注册中心的负载比较高时，服务提供者的心跳包来不及处理，就误认为服务已下线。并且通知给服务的调用者。导致本可以使用的服务，变成不可用。
- 注册中心和服务提供者的网络断了，这样导致注册中心产生误判。
针对以上的解决办法，可以通过在服务调用者判定服务下线之前，自己做一次检查。这样避免了注册中心误判而产生的服务提供者的下线。但这样就增加了一次服务调用者和服务提供者的一次通信。
以上解决了服务的上线和下线感知的问题，那么怎么做到优雅呢？
比如在我们做应用的发布时，我们通常使用分批发布应用，如果我们直接把服务停掉做发布。那么将会导致一些没处理完的任务报错，并且还有很多找不到服务的问题。做到优雅的发布，我们可以先把将要停止服务的地址，先主动从注册中心移除，等待正在处理的任务结束后，再进行停止服务。
服务分组
在平常开发中，一般会遇到以下服务分组的场景：
环境分组
比如在线上我们要区分预发环境、线上环境，线下需要区分测试环境、项目环境。环境的区分，就是通过在设计注册中心时，引入分组的方式完成。
优先级分组
比如对于一个电商网站的应用。交易链路的应用是它核心的应用。它调用的服务和一个后台运营平台也调用这个服务。显然这两个完全优先级不同的业务。这时对于服务做专门的分组，交易链路调用专用的分组。后台运营平台调用默认的分组。
欢迎关注我的公众号MyArtNote
