1、知名网站建设定制为什么需要服务注册中心
知名网站建设定制时代的服务管理
知名网站建设定制在微服务时代，知名网站建设定制我们所有的服务都被劲知名网站建设定制量拆分成最小的粒度，知名网站建设定制原先所有的服务都在混在1个server里，知名网站建设定制现在就被按照功能或者知名网站建设定制对象拆分成N知名网站建设定制个服务模块，知名网站建设定制这样做的好处是深度解耦，1知名网站建设定制个模块只负责自己的事情就好，能知名网站建设定制够实现快速的迭代更新。知名网站建设定制坏处就是服务的管理和控制变得异常的复杂和繁琐，人工维护难度变大。还有排查问题和性能变差（服务调用时的网络开销）
2、什么是注册中心？
注册中心的作用一句话概括就是存放和调度服务，实现服务和注册中心，服务和服务之间的相互通信。注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。
如果没有注册中心？会怎样
在不用服务注册之前，怎么去维护这种复制的关系网络呢？答案就是：写死！。- 1
- 将其他模块的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解析功能，直接就会把有问题的机器给去掉，你服务发现后的机器服务就是正常可用的。
同时，当服务不可用的时候，有些名字服务软件也会提供发送邮件或者消息功能，及时的提示你服务出现故障。这样一来，我们就通过健康检查功能，来帮我们及时的去规避问题，降低影响。
当出现故障的服务被修复后，服务重新启动后，健康检查会检查通过，然后这台机器就会被标记为健康，这样，服务发现，就又可以发现这台机器了。
这样，整个服务注册和服务发现，就实现了闭环。