微服务：注册中心的作用

1、为什么需要服务注册中心

微服务时代的服务管理
在微服务时代，我们所有的服务都被劲量拆分成最小的粒度，原先所有的服务都在混在1个server里，现在就被按照功能或者对象拆分成N个服务模块，这样做的好处是深度解耦，1个模块只负责自己的事情就好，能够实现快速的迭代更新。坏处就是服务的管理和控制变得异常的复杂和繁琐，人工维护难度变大。还有排查问题和性能变差（服务调用时的网络开销）

2、什么是注册中心？

注册中心的作用一句话概括就是存放和调度服务，实现服务和注册中心，服务和服务之间的相互通信。注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。

如果没有注册中心？会怎样

 在不用服务注册之前，怎么去维护这种复制的关系网络呢？答案就是：写死！。

将其他模块的ip和端口写死在自己的配置文件里，甚至写死在代码里，每次要去新增或者移除1个服务的实例的时候，就得去通知其他所有相关联的服务去修改。
随之而来的就是各个项目的配置文件的反复更新、每隔一段时间大规模的ip修改和机器裁撤，非常的痛苦。

而有了注册中心之后，每个服务在调用别人的时候只需要服务的名称就好，调用时会通过注册中心根据服务编码进行具体服务地址进行调用。

常用的注册中心中间件

服务注册中心的作用就是【服务的注册】和【服务的发现】

服务注册，就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到1个公共的组件上去（比如: zookeeper\consul）。
服务发现，就是新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。

你可以理解为：

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

//服务发现
NameServer->getAllServer();

借鉴博客：https://zhuanlan.zhihu.com/p/161277955

服务注册是怎么操作的。看下面的图：

每一个服务对应的机器或者实例在启动运行的时候，都去向名字服务集群注册自己，比如图中，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解析功能，直接就会把有问题的机器给去掉，你服务发现后的机器服务就是正常可用的。

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

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

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