之前介绍了服务注册与发现,其中服务注册中心Eureka Server,是一个实例,当成千上万个服务向它注册的时候,它的负载是非常高的,这在生产环境上是不太合适的,这篇文章主要介绍怎么将Eureka Server集群化
完成目标:
演示单机服务注册中心和高可用服务注册中心这两种情况
结合实际场景深入理解高可用服务注册中心
准备工作
linux系统:vim /etc/hosts 加上:127.0.0.1 peer1 127.0.0.1 peer2
windows系统:在C:\Windows\System32\drivers\etc\hosts 修改
基于这两篇博客进行改进:
Spring Cloud入门教程之服务注册与发现Eureka(一)
Spring Cloud入门教程之服务消费者 Ribbon(二)
单机服务注册中心:
1、启动服务注册中心
2、启动服务提供者、服务消费者
3、使用消费者消费
4、停止服务注册中心后消费
由于设置了断路器所以会提示这个
此时服务消费者、服务提供者均不能注册到服务注册中心,此时就出现了单机故障
高可用服务注册中心:
1、这里采用一个项目启动多个示例(可参看笔者博客),启动2个服务注册中心相互注册
2、启动服务提供者、服务消费者
3、停止一个服务注册中心后消费
此时看到服务提供者、服务消费者注册到第二个服务注册中心
深入理解高可用服务注册中心
虽然上面我们以双节点作为例子,但是实际上因负载等原因,我们往往可能需要在生产环境构建多于两个的Eureka Server节点。那么对于如何配置serviceUrl来让集群中的服务进行同步,需要我们更深入的理解节点间的同步机制来做出决策。
Eureka Server的同步遵循着一个非常简单的原则:只要有一条边将节点连接,就可以进行信息传播与同步。什么意思呢?不妨我们通过下面的实验来看看会发生什么。
- 场景一:假设我们有3个注册中心,我们将peer1、peer2、peer3各自都将serviceUrl指向另外两个节点。换言之,peer1、peer2、peer3是两两互相注册的。启动三个服务注册中心,并将compute-service的serviceUrl指向peer1并启动,可以获得如下图所示的集群效果。
访问http://localhost:1112/,可以看到3个注册中心组成了集群,compute-service服务通过peer1同步给了与之互相注册的peer2和peer3。
- 场景二:依然假设我们有3个注册中心,我们将peer1的serviceUrl指向peer2,peer2的指向peer3,peer3的指向peer1,此时peer1、peer2、peer3通过单向边形成环。分别启动peer1、peer2、peer3,并访问信息页面,我们可以找到下面的规律,peer1成为了peer2的分片节点,peer2成为了peer3的分片节点,peer3则成为了peer1的分片节点,再将compute-service的serviceUrl指向peer1并启动。放别访问peer1、peer2、peer3的信息页面,可以发现compute-service均被peer2和peer3同步过去了,所以单向边也能进行服务的传播与同步。此时,我们断开peer2,可以看到peer3中的compute-service消失了。重新开启peer2并断开peer3,可以看到peer2依然能同步到compute-service。所以我们可以得出结论,Eureka Server的传播与同步是具备方向性的。
通过上面的实验,我们可以得出下面的两点结论来指导我们搭建服务注册中心的高可用集群:
- 两两注册的方式可以实现集群中节点完全对等的效果,实现最高可用性集群,任何一台注册中心故障都不会影响服务的注册与发现
- Eureka Server具备单方面有指向的服务传播与同步机制,在一些对服务发现有限制的情况下,可以利用这样的机制进行服务注册与发现的的单向控制