spring cloud - eureka高可用及其缺陷

世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。

Eureka实现高可用有两种方式：
一种是通过server之间的同步
一种是通过自我保护机制
server之间同步就不用多说了，只是相同的数据同步到多个server中，以保证其中一个挂掉以后其他的可以正常工作。
自我保护机制：
一种是为了避免网络分区带来的因为server误判client的不可用而导致的client之间的无法相互调用。但是万一不是误判，而是真的不可调用呢？会不会因此给客户端带来错觉，依然调用不可用的client？我想如果是客户端负载均衡，对于server认为不可用的但是仍然被保护的客户端，应该做低权重处理；而对于没有负载的唯一的client，如果本来不可用，却仍然存在于可用列表中，给人一种可用的错觉，而造成故障不能及时处理，也是一个大坑，所以应该在可用与不可用之间增加一种保护状态，这种保护状态代表的是server检测到其不可用，但是仍然把他留下了，而出现这种状态时，运维人员可以及时发现并确认处理，同时也不会影响其高可用性。
一种是为了弥补Eureka心跳间隔时间太长的缺陷，eureka默认时间间隔是30秒，在这个时间间隔内可以处理好多请求了，如果相互之间不能调用，实际上已经影响到业务正常运转，所以哪怕检测到不可用也会让client去试一试，万一调用的时候又可用了呢！而这种时间间隔当然是可以缩短的，但是eureka之间是通过http通信的，交互太过频繁对性能是有影响的。面对这种情况，最好的方式是改变心跳的实现，使用netty来做心跳，将心跳的时间间隔缩短，比如2秒一个，即zk的一个tick，会是更好的选择。

最后

以上就是糟糕芹菜为你收集整理的spring cloud - eureka高可用及其缺陷的全部内容，希望文章能够帮你解决spring cloud - eureka高可用及其缺陷所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。