高可用,即High Availability(HA),也就是经常说服务器可用为4个9(99.99%)或5个9(99.999%)。
在Spring Cloud体系中,生产部署时通常各个服务都是高可用的,只需要将同一服务部署在多台机器上(也可以同一机器部署多个使用不同端口,但一般不会这么做),然后注册到Eurake上即可,Eurake + Ribbon就自动帮我们解决了高可用,前面章节已经做过此类演示。
但是作为注册中心的Eurake,我们又该怎么做到高可用呢?
一、高可用Eurake
在分布式系统领域有个CAP定理(CAP theorem),又被称为布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下3点。
C指一致性(Consistency),同一个数据在集群中的所有节点,同一时刻是否都是同样的值。A表示可用性(Availability):集群中一部分节点故障后,集群整体是否还能处理客户端的请求。P是分区容忍性(Partition tolerance):是否允许数据的分区,数据分区的意思是指是否允许集群中的节点之间无法通信。
对于微服务的治理而言,核心就是服务的注册和发现。对于服务发现而言,可用性比数据一致性更加重要,AP胜过CP,即使拿到的可能是不正确的服务实例信息,都要尝试消费一下,也好过因为无法获取实例信息而不消费。因此,Netflix在设计Eureka时遵守的也就是AP原则。
在Eureka的实现中,节点之间是相互平等的,部分注册中心的节点“挂掉”也不会对集群造成影响,即使集群中只剩一个节点存活,也可以正常提供发现服务。即使所有的服务注册节点都“挂”了,Eureka客户端中所缓存的服务实例列表信息,也能够让服务消费者正常工作,这就保证了微服务之间的互相调用是足够健壮的,微服务系统是具有足够弹性的。
Eureka客户端在启动时会从Eureka服务器中获取注册表信息,并将其缓存在本地。并且Eurake默认开启自我保护,该模式下,Eureka服务器会保护服务注册表中的信息,不再注销任何服务实例,可以使用eureka.server.enable-self-preservation=false来关闭自我保护。
因为每一个节点都是对等的,实现高可用,一般Eureka服务器可以通过运行多个实例来构建集群,解决单点问题,提高可用率。在这种架构中,每个节点可以通过彼此互相注册来提高可用性,我们只需要在每个节点中添加一个或多个有效的serviceUrl指向其他Eureka服务器节点,这样每个节点都可被视为其他节点的副本,即通过eureka.client. service-url.defaultZone属性配置多个Eureka服务器地址。
二、示例演示
演示其实很简单,就是配置多个Eurake服务即可,让他们互相复制、同步所注册服务的实例信息。
继续沿用之前的项目,我们将eurake-server复制一份,并更名为eurake-server-2,然后更改其端口号为10811。这样一个新的eurake-server就搭建好了。
为了使他们互相复制、同步所注册服务的实例,需要设置eurake-server和eurake-server-2的eureka.client. service-url.defaultZone为多个节点,即http://localhost:10810/eureka/,http://localhost:10811/eureka/。
然后分别启动这两个Eurake,为了验证,我们再接着启动zuul-server和user-server。
启动完成后,打开http://localhost:10810/或者http://localhost:10811/,都可以看到同样的注册列表信息,因为他们已经相互复制、同步注册列表信息了。
然后我们使用工具或者地址栏调用get请求http://192.168.1.106:10840/api/user/user/find/feign/1,这个请求是通过zuul网关进行分发的,可以看到成功调用了,其中feign调用异常是因为没有启动book-server。然后我们停掉10810端口的eurake-server,继续访问,依旧可以访问成功,但是我们查看zuul-server和user-server中的defaultZone,其实我们只配置了10810。这就是因为10811的Eurake已经复制了10810的服务列表,即使10端口挂掉了,整个微服务环境依旧可以正常使用。
甚至我们将11端口也停掉,请求依然可以正常使用,因为Eureka客户端对服务实例列表信息进行了缓存,但是此时zuul-server和user-server会报连接异常的错误,因为对于Eurake的心跳检测无法正常连接了。
可以看到,我们在前面的试验中并没有修改其他项目的defaultZone一样可以正常使用,但是实际中是不建议这样使用的,因为只配置其中一个,需要保证其他服务在启动时该Eurake服务是正常启动状态,才能将该服务注册信息收集到。所以,为了保证容错,建议其他服务也修改对应defaultZone配置。
https://github.com/imyanger/springcloud-project/tree/master/p9-distributed-eurake