Eureka注册中心主要思想

之前一个项目用到了Eureka注册中心，然后面试的时候被问到了。由于年代有点久远，所以好多知识点忘记了。在这里重新捡起来，包括Eureka这个注册中心的思想也是很不错的思想，为以后升级架构师做准备。

Eureka简介

Eureka是Netflix开源的一个组件，被springcloud用于注册中心的配置。当然，由于不为人知的原因，Eureka变得不再开源，虽然不再开源，但是不妨碍人家依然是最优秀的注册中心之一。

Eureka支持高可用架构，就是集群模式。Eureka本身可以分为服务端（server）和客户端（client），而客户端可以分为服务的提供方（service provider）和服务的消费方（service consumer）。

• 服务端：提供服务的注册和服务的发现。
• 服务消费方：从服务端获取注册的服务，然后消费
• 服务提供方：将自身的服务注册给服务端，供其他消费方服务

说了这么多服务，那啥是服务？

server和service是不一样的。server是前后端概念中的后端，service是指应用为用户带来的什么样的服务，也可以说，一个应用就是一个服务。

CAP理论与Eureka

CAP理论一直谈，没必要再说了，不了解的同学可以看看我之前写的文章，关于redis服务集群的那一篇。

Eureka同样不能避免CAP的理论的束缚，而集群的目的就是高可用，Eureka选择的是AP，放弃了一致性的要求。Eureka能保证返回数据，但是不能保证数据的一致性，因此Eureka无法用于类似于银行系统的开发。

Eureka本身是去中心化的，这与Redis的主从不同，所有的服务端都是可用的。

Eureka基本原理

在单节点中，服务的提供者向Eureka server注册自己的服务，服务的消费者从server拉取服务，找到服务提供者的地址和接口，进行服务的消费。

当消费方进行一次消费的时候，会利用本地缓存，存储起来服务的地址，接口等相关信息，供下一次调用，就不必重新从注册中心拉取。

维持三者连接的还是传统的，03年google提出的GFS中的心跳服务。默认在90s内未收到一个模块的心跳信息，认为该服务崩溃，注销该服务。

存在一种情况，server与client’之间的连接中断，但是服务对外依然开放且可用。或者说server这边的网络不好，一次性失去过多的服务，那么注册中心将不会注销任何服务。

集群保证高可用

我们之前说，Eureka是AP的，所以放弃了数据的一致性要求。但是放弃的是高一致性要求，转而使用了数据的“最终一致性”。

这种最终一致性也是GFS论文中提出的，就是我不保证数据的时时刻刻一致，而是在某个状态后，达到一致性即可。Eureka会将同类型的节点进行数据异步同步。

具体怎么同步的数据，同步算法，我没找到。。。。但是可以根据它的机制推测出来：

1. 当新服务到来，注册到Eureka，Eureka会向其他的注册中心进行同步。
2. 没有新生产服务的时候，Eureka会利用心跳机制，判断某个服务是否下线。
3. 数据怎么同步？Eureka是注册中心，不保存任何数据，所有数据都从消费提供者提供，所以不需要对数据进行同步。Eureka只需要保存数据提供者的信息即可。

当服务注册以后，server会将节点同步给其他server。

不过，新server的加入会让其他server注册新server服务。有点绕嘴，意思就是，即使是Eureka server，本身也是client，所以本身需要对其他的server进行注册，才能达到相互同步消息的目的。

凑合看图。

服务端接受到的任何操作，比如服务下线，服务续约等，都会对其他server进行同步。