nacos进阶一 - 注册中心的演变历程及原理

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

其实, 他确定是有本身的一个演变过程的, 必定是由于须要, 因此才出现.

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

1. 最初的单体应用时代, 若是我一个服务是产品服务,一个试订单服务. 产品服务想要去访问订单服务, 咱们都是怎么作的呢?

 

 也就是说: 商品服务调用订单服务, 经过的是http远程调用的方式实现的, 这样的问题是什么呢?

• 若是订单服务宕机了, 商品服务还能调通么?
• 若是订单服务的ip地址更改了, 商品服务的远程调用地址是否是也要一块儿发生变化?
• 若是订单服务一台服务器不够用了,  须要增长一台服务器, 商品服务就要本身维护一个订单服务的ip列表. 并按照必定规则访问

这就是单体服务的问题, 由于ip是写死在商品服务里面的, 因此, 一旦发生变化, 不能自动感知, 必须手动修改. 

2. 订单服务流量增多, 变成了多个订单服务

 

 这个时候, 咱们怎么作的呢? 咱们要知足实际业务的需求, 订单量太大了, 单台服务器常常支撑不了了, 因而就想到, 部署多台服务来分担压力.

就出现了上面的模型, 但是, 这个模型存在什么样的问题呢?

• 程序员本身维护的ip列表, 若是订单服务某一台挂了怎么办, 那就请求不通了
• 若是订单服服务依然不能知足需求, 还要继续扩容, 程序员又要从新维护一份订单服务的ip列表. 

手动维护ip列表确定很差, 一方面一旦有任何变更, 就须要进行维护; 另外一方面, 从效率上来说, 也不高. 还容易出错. 因而慢慢有就有了nginx

3. 使用nginx来维护订单服务的ip列表

 

 商品服务的全部请求过来了, 不要直接去请求订单服务. 经过nginx去请求订单服务. 在nginx中维护了订单服务的ip列表. 而且能够指定负载均衡策略.

嗯, 这个选择好像还不错, 不用程序员常常改商品服务代码了, 也不用程序员本身写如何分配请求的流量了. 那么他就知足咱们全部的需求么?固然也不是

• 虽然程序员不用在代码中维护ip列表了, 可是在nginx中依然要维护. 若是订单服务有不少不少, 怎么办? 咱们知道在nginx上是经过upstream来维护ip的, 若是有成百上千的服务, 那么咱们要维护成百上千个ip么?
• 若是订单服务扩缩容了, 是否是同样要修改nginx的配置文件呢?

因而咱们就想,有没有一种办法, 可以让微服务自动的就被注册上呢?这个需求迫在眉睫

4. 因而, 就有了注册中心的概念. 最初, 咱们的想法也很简单

 

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

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

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

第四, 根据ip发送请求. 

 

这里面也会有一些问题

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

因而, 想到将咱们的注册中心进行改造. 改造的更加完美一些

5. 改造后的注册中心

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

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

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

3. 商品服务和订单服务有一个定时任务timetask1, 按期发送心跳. 而后注册中心就会修改这个心跳时间. 一般是30秒发送一次. 

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

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

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

 

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