分布式篇:对比一下各种服务注册中心

目前业内的微服务解决方案

通常分为两块

1、以 Dubbo 为主的微服务解决方案
2、以 Spring Cloud 为主的微服务解决方案

这两块微服务解决方案都采用了不同的 注册中心

以 Dubbo 作为服务框架的一般会选择 Zookeeper 为注册中心

以ZK作为服务注册和发现的集群模式

这种多台机器的情况下 ZK 会有2个角色 Leader / Follower

只有 Leader 是可以写,也就是服务注册,它可以把注册信息同步给 Follower

读的时候,两个角色都可以读

ZK ,遵循了CAP 中的 CP

它保证了一致性和分区容错性

ZK有一个Leader节点会接收数据,然后同步到其它节点

一旦Leader挂了,这个时候要重新选举Leader,这个过程为了保证C,就牺牲了A,不可用一段时间

一旦Leader选举好了,那么就可以继续写数据了,保证了一致性

以ZK作为服务注册发现的时效性一般秒级可以感知到

不适合大规模的服务实例,因为服务上下线的时候,要瞬间推送数据通知到所以其他服务实例,一旦服务规模过大,上千个的时候,会导致网络带宽被大量占用

分布式篇:对比一下各种服务注册中心_第1张图片

以 Spring Cloud 作为服务框架的一般会选择 Eureka 为注册中心

以 Eureka 作为服务注册和发现的集群模式

这种情况下集群里面的机器都是对等的,每个服务都可以进行服务注册与服务发现

并且集群中任意一台机器收到写请求后,会自动同步给其余机器

Eureka ,遵循了CAP 中的 AP

它保证了可用性和分区容错性

Eureka 每个实例的平级的,可能数据还没同步过去,自己就挂了

此时还是可以从别的机器上获取注册表,但是看到的就不是最新的数据,保证了可用性,但是 Eureka 遵循的是最终一致性

以 Eureka 作为服务注册发现的时效性默认配置非常差,服务感知可能几十秒甚至几分钟级别

因为从注册中心的缓存刷新,服务同步注册中心的数据,服务故障检查心跳,都有一个时间间隔

针对这种情况,是肯定不能用默认配置在生产上的

eureka,必须优化参数

## 每隔  3秒 只读 从 只写 缓存 更新缓存
eureka.server.responseCacheUpdateIntervalMs = 3000 

## 客户端获取注册表信息缓存
eureka.client.registryFetchIntervalSeconds = 3000

## 心跳间隔,5秒
eureka.client.leaseRenewalIntervalInSeconds = 5

## 主动失效检测间隔,配置成5秒
eureka.server.evictionIntervalTimerInMs = 5

## 没有心跳的淘汰时间,10秒
eureka.instance.leaseExpirationDurationInSeconds = 10

服务发现的时效性变成秒级,几秒钟可以感知服务的上线和下线

eureka 也很难支持大规模的服务实例

因为每个实例都要接收写请求,需要同步,实例太多扛不住,很难达到几千服务实例

分布式篇:对比一下各种服务注册中心_第2张图片

你可能感兴趣的:(概要)