【服务治理】服务注册与发现

什么是服务注册与发现

我们先来看下什么是服务注册与服务发现？

服务注册，就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到1个公共的组件上去（比如: zookeeper\consul）。

服务发现，就是新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。

你可以理解为：

//服务注册
NameServer->register(newServer); //服务发现
NameServer->getAllServer();

服务注册

用了服务注册和服务发现之后，我们的网络请求模块，发生了怎么的变化呢？先来看下，服务注册是怎么操作的。看下面的图：

每一个服务对应的机器或者实例在启动运行的时候，都去向名字服务集群注册自己，比如图中，User服务有6个docker实例，那么每个docker实例，启动后，都去把自己的信息注册到名字服务模块上去，同理Order服务也是一样。

对应的伪代码可以表示如下：

//给User服务申请1个独有的专属名字
UserNameServer = NameServer->apply('User');//User服务下的6台docker实例启动后，都去注册自己
UserServer1 = {ip: 192.178.1.1, port: 3445}
UserNameServer->register(UserServer1);......UserServer6 = {ip: 192.178.1.6, port: 3445}
UserNameServer->register(UserServer6);//给Order服务申请1个独有的专属名字
OrderNameServer = NameServer->apply('Order');//开始注册
OrderServer1 = {ip: 192.178.1.1, port: 3446}
OrderNameServer->register(OrderServer1);//给Search服务申请1个独有的专属名字
SearchNameServer = NameServer->apply('Search');//开始注册
SearchServer1 = {ip: 192.178.1.1, port: 3447}
SearchNameServer->register(SearchServer1);

这样，每个服务的机器实例在启动后，就完成了注册的操作。注册的方式有很多的形式，不同的名字服务软件方式不一样，有HTTP接口形式，有RPC的方式，也有使用JSON格式的配置表的形式的。方式虽然不同，但是结果都是一样。

实例注册到名字服务上之后，接下来就是服务发现了。

服务发现

我们把每个服务的机器实例注册到了名字服务器上之后，接下来，我们如何去发现我们需要调用的服务的信息呢？这就是服务发现了。

我们看下，服务发现是怎么做的：

在上图中，Order服务想要获取User服务相关的信息，首先向注册集群中心发送请求获取，然后就能收到User服务相关的信息。

伪代码可以表示如下：

//服务发现，获取User服务的列表
list = NameServer->getAllServer('User'); //list的内容
[{"ip": "192.178.1.1","port": 3445},{"ip": "192.178.1.2","port": 3445},......{"ip": "192.178.1.6","port": 3445}
]//服务发现，获取Goods服务的列表
list = NameServer->getAllServer('Goods');//list的内容
[{"ip": "192.178.1.1","port": 3788},{"ip": "192.178.1.2","port": 3788},......{"ip": "192.178.1.4","port": 3788}
]

我们通过服务发现，就获得了User模块的所有的ip列表，然后，我们再用一定的负载均衡算法，或者干脆随机取1个ip，进行调用。

当然，也有些注册服务软件也提供了DNS解析功能或者负载均衡功能，它会直接返回给你一个可用的ip，你直接调用就可以了，不用自己去做选择。

这样，我们获取了服务的IP信息后，就可以进行调用了，如图所示：

和服务注册的方式一样，服务发现的方式，不同的名字服务软件的方式也会不一样，有的是得自己发送HTTP接口去轮训调用，如果发现有更新，就更新自己本地的配置文件。有的是可以通过实时的sub/pub的方式实现的自动发现服务，当我订阅的这个服务内容发生了更新，就实时更新自己的配置文件。也有的是通过RPC的方式。方式虽然不同，但是结果都是一样。

这样一来，我们就可以通过服务注册和发现的方式，维护各个服务IP列表的更新，各个模块只需要向名字服务中心去获取某个服务的IP就可以了，不用再写死IP。整个服务的维护也变得轻松了很多。彻底解放了双手！

健康检查

可能你会说，这样加了1个中间代理，饶了一个大圈子，感觉也挺费劲的，难道仅仅是为了解决新增服务，动态获取IP的问题吗？

当然不是！服务注册和服务发现，不仅仅解决了服务调用这种写死IP以及杂乱无章的管理的状态，更重要的一点是它还管理了服务器的存活状态，也就是健康检查。

很多名字服务软件都会提供健康检查功能。注册服务的这一组机器，当这个服务组的某台机器，如果出现宕机或者服务死掉的时候，就会标记这个实例的状态为故障，或者干脆剔除掉这台机器。这样一来，就实现了自动监控和管理。

健康检查有多重实现方式，比如有几秒就发一次健康检查心跳，如果返回的HTTP状态不是200，那么就判断这台服务不可用，对它进行标记。也可以执行一个shell脚本，看执行的返回结果，来标记状态等等。

上图中，用心跳发送的方式来检查健康状态，当有1台机器出现异常，这样我们获取服务的时候，就能知道服务的健康状态了。

比如伪代码如下：

//服务发现，获取User服务的列表
list = NameServer->getAllServer('User'); //list的内容
[{"ip": "192.178.1.1","port": 3445,"status": "success"},{"ip": "192.178.1.2","port": 3445,"status": "success"},......{"ip": "192.178.1.6","port": 3445"status": "error" //故障,出现错误}
]

我们通过判断列表里的status的状态是不是success来确认调用的服务是可用的。有些名字服务会提供DNS解析功能，直接就会把有问题的机器给去掉，你服务发现后的机器服务就是正常可用的。

同时，当服务不可用的时候，有些名字服务软件也会提供发送邮件或者消息功能，及时的提示你服务出现故障。这样一来，我们就通过健康检查功能，来帮我们及时的去规避问题，降低影响。

当出现故障的服务被修复后，服务重新启动后，健康检查会检查通过，然后这台机器就会被标记为健康，这样，服务发现，就又可以发现这台机器了。

这样，整个服务注册和服务发现，就实现了闭环。

市面上业界的解决方案

目前市面上已经有了服务注册和服务发现的解决方案，代表作是：zookeeper、consul、Eureka以及etcd,他们功能强大，安全稳定，高并发高可用，强一致性，目前市面上都是用这几个来实现自己的服务注册和发现的。

其中，consul 是后起之秀，源于它安装简单，功能强大，提供健康检查，web管理后台，支持多数据中心，暴露了方便的HTTP接口，使得它被更多的人所使用，唯一不足的是它不支持sub/pub订阅机制，所以服务发现，得使用者自己去HTTP轮训发现变更。

解决方案	CAP	协议
ZooKeeper	CP	Zab
Eureka	AP	未公布
etcd	CP	Raft
Consul	AP	Raft

来源

服务治理-服务发现
深入了解服务注册与发现