注册中心的演变历程及原理

我们原来使用单题架构的时候, 没有注册中心, 注册中心是如何悄悄的就出现在了我们的日常生活中的呢?

其实, 他肯定是有自己的一个演变过程的, 一定是因为有需求, 所以才出现.

下面我们就来分析注册中心是如何演变而来的.

1.最初的单体架构应用时代，一个是A服务，一个是B服务，如果说A服务要去调用B服务，我们是怎么做的呢？

也就是说A服务去调用B服务，是通过Http请求去远程调用的方式去实现的，那这样的问题是什么呢？

• 如果B服务宕机了，A服务还可以去调用吗？
• 如果B服务的IP地址发生了改变，那么调用的A服务是不是也要一起去发生变化？
• 如果B服务一台服务器不够用了，需要增加服务，那么A服务就要自己维护一个B服务的IP列表，并且按照一定的访问规则去访问

这就是单体服务的问题，因为IP是写死在A服务当中的，所以一但发生变化，不能够自动感知，必须得手动的去修改

2.B服务的流量增多，变成了多个B服务

这个时候我们怎么做呢？我们要满足实际业务的需求，B服务流量增多，单台的服务器已经无法支撑，于是我们想到的就是将服务进行部署多太服务器来分担单个的压力，就会导致上面的图片发生的情况，但是这种情况又会有什么问题呢？

• 如果说程序员去维护自己的IP列表，万一中间的一台服务器宕机了，那就请求不通了！！！！
• 如果B服务继续扛不住了，你是不是需要在加服务器，在去加IP列表，重新进行维护

手动的去维护IP列表肯定是不好的，一方面一旦有变动另一边就需要去改动；而且从效率上来讲，也不高，还特别容易出错，于是慢慢的Nginx就出现了

3.使用Nginx来维护B服务的IP列表

这样A服务发送过来的请求就不会直接去请求B服务，而是去通过Nginx请求B服务，在Nginx中维护了IP列表，并且可以指定负载均衡的策略。

到这时候呢是不是就变的方便了，程序猿不用去更改A服务的代码了，也不用去自己写算法去搞分流请求，那么他真的满足了我们所以的需求了吗？当然不是，到这里有没有发现一个问题？

• 程序员是不用在代码中维护ip的列表了，但是在Nginx中依然需要维护呢，如果B服务有很多怎么办？我们都知道在nginx中是通过upstream来维护ip的， 如果有成千上万的服务难道我们要去维护成千上万的IP吗？
• 如果后期B服务用不着那么多服务器了，我们要去缩减，那是不是一样的还要去修改nginx的配置文件呢？

于是我们就想，有没有一种办法，可以让微服务自己自动就被注册呢？（自己先想想！）

架构师传送门：O

4.于是我们就推出了注册中心的概念，最初我们的想法也是很简单的

首先有一个数据库表来维护所有的服务, 并标记这些服务的启动状态

然后, 每当有一个服务启动, 那么都调用注册接口, 其实注册接口就是一个insert服务器信息到数据库的过程

第三, 每次A服务要调用B服务了, 先去数据库里面查询可用的B服务列表. 然后根据策略选择服务ip,

第四, 根据ip发送请求.

这里面也会有一些问题

• 服务宕机了怎么办? 还来不及发出通知
• 每次A服务调用B服务, 都要去数据库查询可用的服务列表, 这样当流量大了, 就会给数据库造成很大的压力, 而且, 每次都查数据库, 效率也不高.
• 注册中心宕机 了怎么办?

于是, 想到将我们的注册中心进行改造. 改造的更加完美一些

5. 改造后的注册中心

这个就是在上面的基础上改造过来的

1. 增加了一个last_heartTime, 记录心跳时间.

2. 当A服务和B服务启动的时候, 需要调用注册接口, 告诉注册中心, 我上线了, 实质上这是一个insert记录的过程

3.A服务和B服务有一个定时任务timetask1, 定期发送心跳. 然后注册中心就会修改这个心跳时间. 通常是30秒发送一次.

4. A服务有一个定时任务timerTask2, 定期去任务中心拉取服务列表, 并将其保存在客户端缓存中, 当请求过来的时候, 通过ribbon拉取客户端缓存的ip, 按照负载均衡策略, 选择指定的B服务发送远程调用,

5. 在注册中心有一个定时任务timerTask3, 如果注册中心在规定的时间内, 没有收到微服务的心跳, 那么就认为服务挂了, 将其状态设置为down, 下次拉取的时候, 这台服务器不会被拉取过去. 其实,这是一个状态修改的过程

6. 当服务停止的时候, 会调用服务注销接口, 通知注册中心,服务停止, 注册中心就是将其从注册表中删除. 其实这就是一个delete记录的过程

以上就是注册中心的由来, 和根本的原理