精华内容
参与话题
问答
  • 微服务:注册中心ZooKeeper、Eureka、Consul 、Nacos对比

    万次阅读 多人点赞 2019-08-22 21:11:09
    服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务,原则上都应存在或者支持多个提供者,这是由微服务的分布式属性决定的。更进一步,为了支持弹性扩缩容特性,一个微服务的提供者的数量和...

    前言

    服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务,原则上都应存在或者支持多个提供者,这是由微服务的分布式属性决定的。更进一步,为了支持弹性扩缩容特性,一个微服务的提供者的数量和分布往往是动态变化的,也是无法预先确定的。因此,原本在单体应用阶段常用的静态LB机制就不再适用了,需要引入额外的组件来管理微服务提供者的注册与发现,而这个组件就是服务注册中心。

    CAP理论

    CAP理论是分布式架构中重要理论

    • 一致性(Consistency) (所有节点在同一时间具有相同的数据)
    • 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
    • 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

    关于

    P的理解,我觉得是在整个系统中某个部分,挂掉了,或者宕机了,并不影响整个系统的运作或者说使用,

    而可用性是,某个系统的某个节点挂了,但是并不影响系统的接受或者发出请求,CAP 不可能都取,只能取其中2个

    原因是

    如果C是第一需求的话,那么会影响A的性能,因为要数据同步,不然请求结果会有差异,但是数据同步会消耗时间,期间可用性就会降低。

    如果A是第一需求,那么只要有一个服务在,就能正常接受请求,但是对与返回结果变不能保证,原因是,在分布式部署的时候,数据一致的过程不可能想切线路那么快。

    再如果,同事满足一致性和可用性,那么分区容错就很难保证了,也就是单点,也是分布式的基本核心,好了,明白这些理论,就可以在相应的场景选取服务注册与发现了

     

    服务注册中心解决方案

    设计或者选型一个服务注册中心,首先要考虑的就是服务注册与发现机制。纵观当下各种主流的服务注册中心解决方案,大致可归为三类:

    • 应用内:直接集成到应用中,依赖于应用自身完成服务的注册与发现,最典型的是Netflix提供的Eureka

    • 应用外:把应用当成黑盒,通过应用外的某种机制将服务注册到注册中心,最小化对应用的侵入性,比如Airbnb的SmartStack,HashiCorp的Consul

    • DNS:将服务注册为DNS的SRV记录,严格来说,是一种特殊的应用外注册方式,SkyDNS是其中的代表

    注1:对于第一类注册方式,除了Eureka这种一站式解决方案,还可以基于ZooKeeper或者Etcd自行实现一套服务注册机制,这在大公司比较常见,但对于小公司而言显然性价比太低。

    注2:由于DNS固有的缓存缺陷,本文不对第三类注册方式作深入探讨。

    除了基本的服务注册与发现机制,从开发和运维角度,至少还要考虑如下五个方面:

    • 测活:服务注册之后,如何对服务进行测活以保证服务的可用性?

    • 负载均衡:当存在多个服务提供者时,如何均衡各个提供者的负载?

    • 集成:在服务提供端或者调用端,如何集成注册中心?

    • 运行时依赖:引入注册中心之后,对应用的运行时环境有何影响?

    • 可用性:如何保证注册中心本身的可用性,特别是消除单点故障?

     

    主流注册中心产品

    软件产品特性并非一成不变,如果发现功能特性有变更,欢迎评论指正

      Nacos Eureka Consul CoreDNS Zookeeper
    一致性协议 CP+AP AP CP CP
    健康检查 TCP/HTTP/MYSQL/Client Beat Client Beat TCP/HTTP/gRPC/Cmd Keep Alive
    负载均衡策略 权重/
    metadata/Selector
    Ribbon Fabio RoundRobin
    雪崩保护
    自动注销实例 支持 支持 支持 不支持 支持
    访问协议 HTTP/DNS HTTP HTTP/DNS DNS TCP
    监听支持 支持 支持 支持 不支持 支持
    多数据中心 支持 支持 支持 不支持 不支持
    跨注册中心同步 支持 不支持 支持 不支持 不支持
    SpringCloud集成 支持 支持 支持 不支持 支持
    Dubbo集成 支持 不支持 支持 不支持 支持
    K8S集成 支持 不支持 支持 支持 不支持
    • Consul是支持自动注销服务实例, 请见文档: https://www.consul.io/api-docs/agent/service,在check的 DeregisterCriticalServiceAfter 这个参数-- 感谢@超帅的菜鸟博主提供最新信息
    • 新版本的Dubbo也扩展了对 Consul 的支持。 参考: https://github.com/apache/dubbo/tree/master/dubbo-registry

    Apache Zookeeper -> CP


    与 Eureka 有所不同,Apache Zookeeper 在设计时就紧遵CP原则,即任何时候对 Zookeeper 的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性,但是 Zookeeper 不能保证每次服务请求都是可达的。

    从 Zookeeper 的实际应用情况来看,在使用 Zookeeper 获取服务列表时,如果此时的 Zookeeper 集群中的 Leader 宕机了,该集群就要进行 Leader 的选举,又或者 Zookeeper 集群中半数以上服务器节点不可用(例如有三个节点,如果节点一检测到节点三挂了 ,节点二也检测到节点三挂了,那这个节点才算是真的挂了),那么将无法处理该请求。所以说,Zookeeper 不能保证服务可用性。


    当然,在大多数分布式环境中,尤其是涉及到数据存储的场景,数据一致性应该是首先被保证的,这也是 Zookeeper 设计紧遵CP原则的另一个原因。

    但是对于服务发现来说,情况就不太一样了,针对同一个服务,即使注册中心的不同节点保存的服务提供者信息不尽相同,也并不会造成灾难性的后果。

    因为对于服务消费者来说,能消费才是最重要的,消费者虽然拿到可能不正确的服务实例信息后尝试消费一下,也要胜过因为无法获取实例信息而不去消费,导致系统异常要好(淘宝的双十一,京东的618就是紧遵AP的最好参照)。

    当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30~120s,而且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。

    在云部署环境下, 因为网络问题使得zk集群失去master节点是大概率事件,虽然服务能最终恢复,但是漫长的选举事件导致注册长期不可用是不能容忍的。

     

    Spring Cloud Eureka  -> AP

     


    Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则(尽管现在2.0发布了,但是由于其闭源的原因 ,但是目前 Ereka 1.x 任然是比较活跃的)。

    Eureka Server 也可以运行多个实例来构建集群,解决单点问题,但不同于 ZooKeeper 的选举 leader 的过程,Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构,无 master/slave 之分,每一个 Peer 都是对等的。在这种架构风格中,节点通过彼此互相注册来提高可用性,每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

    在集群环境中如果某台 Eureka Server 宕机,Eureka Client 的请求会自动切换到新的 Eureka Server 节点上,当宕机的服务器重新恢复后,Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时,所有的操作都会在节点间进行复制(replicate To Peer)操作,将请求复制到该 Eureka Server 当前所知的其它所有节点中。

    当一个新的 Eureka Server 节点启动后,会首先尝试从邻近节点获取所有注册列表信息,并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点,并且会通过心跳契约的方式定期更新。

    默认情况下,如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳(默认周期为30秒),Eureka Server 将会注销该实例(默认为90秒, eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置)。

    当 Eureka Server 节点在短时间内丢失过多的心跳时,那么这个节点就会进入自我保护模式。

    Eureka的集群中,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

    1. Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务;
    2. Eureka仍然能够接受新服务注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用);
    3. 当网络稳定时,当前实例新注册的信息会被同步到其它节点中;

    因此,Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使得整个注册服务瘫痪。

    Consul:

    Consul 是 HashiCorp 公司推出的开源工具,用于实现分布式系统的服务发现与配置。Consul 使用 Go 语言编写,因此具有天然可移植性(支持Linux、windows和Mac OS X)。

    Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案,不再需要依赖其他工具(比如 ZooKeeper 等),使用起来也较为简单。

    Consul 遵循CAP原理中的CP原则,保证了强一致性和分区容错性,且使用的是Raft算法,比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性,但是可用性就相应下降了,例如服务注册的时间会稍长一些,因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ;在leader挂掉了之后,重新选举出leader之前会导致Consul 服务不可用。

    默认依赖于SDK

     

     Consul本质上属于应用外的注册方式,但可以通过SDK简化注册流程。而服务发现恰好相反,默认依赖于SDK,但可以通过Consul Template(下文会提到)去除SDK依赖。

    Consul Template

    Consul Template

    Consul,默认服务调用者需要依赖Consul SDK来发现服务,这就无法保证对应用的零侵入性。

    所幸通过Consul Template,可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置(比如nginx的upstream),这样对于服务调用者而言,只需要配置一个统一的服务调用地址即可。

     

    Consul强一致性(C)带来的是:

    1. 服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
    2. Leader挂掉时,重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。

    Eureka保证高可用(A)和最终一致性:

    1. 服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否replicate成功
    2. 当数据出现不一致时,虽然A, B上的注册信息不完全相同,但每个Eureka节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求A查不到,但请求B就能查到。如此保证了可用性但牺牲了一致性。

    其他方面,eureka就是个servlet程序,跑在servlet容器中; Consul则是go编写而成。

    Nacos:

    Nacos是阿里开源的,Nacos 支持基于 DNS 和基于 RPC 的服务发现。在Spring Cloud中使用Nacos,只需要先下载 Nacos 并启动 Nacos server,Nacos只需要简单的配置就可以完成服务的注册发现。

    Nacos除了服务的注册发现之外,还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要,让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单,让服务按需弹性扩展变得更容易。

    一句话概括就是Nacos = Spring Cloud注册中心 + Spring Cloud配置中心。
     

    参考链接:

    https://yq.aliyun.com/articles/698930

    https://nacos.io

    展开全文
  • 微服务架构注册中心

    千次阅读 2019-06-05 11:47:47
    1什么是注册中心 注册中心相当于手机的通讯录,服务注册就是将服务的地址添加到通讯录里面,服务发现就是当需要找这个服务的时候通过这个通讯录找到服务的地址进行拨号。 2为什么要注册中心 服务中心的作用不仅是...

    1什么是注册中心

    注册中心相当于手机的通讯录,服务注册就是将服务的地址添加到通讯录里面,服务发现就是当需要找这个服务的时候通过这个通讯录找到服务的地址进行拨号。

    2为什么要注册中心

    服务中心的作用不仅是服务的注册和发现,还要考虑服务注册后服务的及时发现,服务宕机后的及时下线,路由,异常时降级,自身高可用。

    3springcloud 的注册中心

    springcloud主要支持三种注册中心,分别是Euraka、consul、zookeeper,其中用的最多的是euraka,它支持多节点部署来保证自身的高可用

    4注册中心的实现例子–euraka

    1添加注册中心的依赖

    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-eureka-server</artifactId>
    		</dependency>
    

    2添加配置文件applicaton.yml

    server:
      port: 1025
    spring:
      application:
        name: eureka-server
    eureka:
      client:
        fetch-registry: false
        register-with-eureka: false
        serviceUrl:
          defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      instance:
        hostname: localhost
      server:  #配置属性,但由于 Eureka 自我保护模式以及心跳周期长的原因,经常会遇到 Eureka Server 不剔除已关停的节点的问题
        enable-self-preservation: false
        eviction-interval-timer-in-ms: 5000
    
    

    3添加springboot启动类,在启动类的上面添加EnableEurekaServer的注解

    import org.springframework.boot.autoconfigure.SpringBootApplication;
    import org.springframework.boot.builder.SpringApplicationBuilder;
    import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
    
    @EnableEurekaServer
    @SpringBootApplication
    public class Application {
    
    	public static void main(String[] args) {
    		new SpringApplicationBuilder(Application.class).web(true).run(args);
    	}
    
    }
    

    4注册中心的高可用–euraka

    • 在hosts文件中添加主机peer1和peer2
    127.0.0.1 peer1 
    127.0.0.1 peer2
    
    • 修改application.yml
    ---
    spring:
      profiles: peer1                                 # 指定profile=peer1
    server:
      port: 8761
    eureka:
      instance:
        hostname: peer1                               # 指定当profile=peer1时,主机名
      client:
        serviceUrl:
          defaultZone: http://peer2:8762/eureka/      # 将自己注册到peer2这个Eureka上面去
    
    ---
    spring:
      profiles: peer2
    server:
      port: 8762
    eureka:
      instance:
        hostname: peer2
      client:
        serviceUrl:
          defaultZone: http://peer1:8761/eureka/
    
    
    • 分别启动两个Eureka应用:
    java -jar microservice-discovery-eureka-0.0.1-SNAPSHOT.jar --spring.profiles.active=peer1
    java -jar microservice-discovery-eureka-0.0.1-SNAPSHOT.jar --spring.profiles.active=peer2
    
    • 访问http://peer1:8761 ,我们会发现registered-replicas 中已经有peer2 节点了,同样地,访问http://peer2:8762 ,也能发现其中的registered-replicas 有peer1 节点,如下图:
      在这里插入图片描述
      我们尝试将peer2 节点关闭,然后访问http://peer1:8761 ,会发现此时peer2会被添加到unavaliable-replicas 一栏中。
    • 将服务注册到高可用的Eureka
      如果注册中心是高可用的,那么各个微服务配置只需要将defaultZone 改为如下即可
    eureka:
      client:
        serviceUrl:
          defaultZone: http://peer1:8761/eureka/,http://peer2:8762/eureka
    
    展开全文
  • 一、服务注册中心注册中心核心功能+实现策略 1.注册中心核心功能 2.注册中心实现策略 二、服务发布与注册 三、服务发现与调用 四、服务监控 基本思路:日志埋点 基本目标: 基本定位: 基本策略: 具体...

    目录

    一、服务注册中心:注册中心核心功能+实现策略

    1.注册中心核心功能

    2.注册中心实现策略

    二、服务发布与注册

    三、服务发现与调用

    四、服务监控

    基本思路:日志埋点

    基本目标:

    基本定位:

    基本策略:

    具体实现:

    参考书籍、文献和资料:


    服务治理在面临系统存在大量服务时可以解决基本的三大定位问题:提升服务架构的可扩展性;有效的服务监控和故障定位;对服务的有效划分和路由。在技术实现上,服务治理一般表现为服务发布与订阅机制以及实现该机制的服务注册中心。

    各个微服务需要通过服务治理实现自动化的注册和发现。服务治理的需求来自于服务的数量。为了实现微服务架构中的服务注册和发现,通常都需要构建一个独立的媒介来管理服务的实例,这个媒介一般被称为服务注册中心。

    一、服务注册中心:注册中心核心功能+实现策略

    主要充当服务注册和服务发现服务器的作用,不但是路由信息的存车仓库,也是服务提供者和服务消费者进行交互的媒介。

    1.注册中心核心功能

    (1)注册中心具备发布-订阅功能,体现在服务提供者可以根据服务的元数据发布服务,而服务消费者则通过自己感兴趣的服务进行订阅并获取包括服务地址在内的各项元数据。

    (2)布-订阅功能还体现在数据变更推送,即当注册中心服务定义发生变化时,主动推送变更到该服务的消费者从而实现间接路由。

    (3)需要确保数据的一致性,在任何时候服务提供者和服务消费者都应该看到同一份数据。

    (4)为了确保服务高可用性,一般也需要注册中心保持高可用性,也就意味着注册中心需要构建对等集群。

    对等集群,Peer-to-Peer Server Clusgter,指集群中所有服务器都提供同样的服务,客户端只连接一个服务器完成注册和发现即可,任何一台服务器宕机都不影响客户端的正常使用。

    (5)作为注册中心的客户端程序,一般对嵌入在服务提供者和服务消费者的应用程序中。

    在应用程序运行时,服务提供者的注册中心客户端程序会向注册中心注册自身提供的程序,而服务消费者的注册中心客户端程序则从注册中心查询当前订阅的服务信息并周期性的刷新服务状态。

    (6)服务消费者需配备缓存机制以加速服务路由,提高服务路由的效率和容错性,更重要的是,当服务注册中心不可用时,服务消费者可以利用本地缓存路由实现对现有服务的可靠调用。

    可以对注册中心进行抽象建模如下图,客户端可以是服务提供者也可以是服务消费者。

    2.注册中心实现策略

    在实现流程图上,服务提供者和服务消费者可以使用一定的通信机制与注册中心服务器建立连接并维持心跳检测,通过注册中心提供的操作接口分别完成发布和动态更新服务定义、获取制定服务地址列表、取消服务发布、获取服务地址更新等功能。同时,注册中心的服务监听机制确保消费者能够实时监控服务更新状态。

    具体流程如下图:

    二、服务发布与注册

    服务发布的目的是为了暴露服务访问的入口,是一个通过构建网络连接并启动端口监听请求的过程。服务发布注册流程如下:

    1.发布启动器:确定服务发布形式并启动发布平台。

    (1)服务发布形式常见的有三种:配置化+API调用+使用注解,各有利弊。

    配置化:通过以XML为代表的配置化工具,服务框架对业务代码零侵入,扩展和修改方便,同时配置信息修改能够实时生效。

    API调用:服务框架对业务代码侵入性较强,修改代码之后需要重新编译才能生效。

    注解方式:服务框架对业务代码零侵入,扩展和修改比较方便,但修改配置需要编译才能生效。

    一般我们倾向于使用配置方式,但涉及系统之间集成时,需要使用服务框架中较底层的服务接口,API调用有可能是唯一选择。

    (2)发布平台的启动与所选择的发布方式密切相关。

    使用配置化发布时:通常会借助诸如Spring的容器进行服务实例的配置和管理,容器的正常启动意味着发布平台的启动。

    使用API调用时:简单使用main函数进行启动。

    使用注解方式时:与使用配置化发布启动是类似的。

    2.动态代理

    在实现远程调用时必然会添加动态代理功能,通过动态代理来实现对服务发布进行动态拦截,可以对服务发布行为本身进行封装和抽象,同时也便于扩展和定制化。

    JDK自带的Proxy机制和诸如javassist的字节码编辑库都可以实现动态代理。

    3.发布管理器

    在流程中充当承上启下的门户Facade作用,一方面,获取协议服务器中生成的服务URL信息并发布到注册中心,另一方面,负责通知发布启动器本次发布是否成功。

    4.协议服务器

    是真正实现服务器创建和网络通信的组件,主要作用在于确定发布协议以及根据该协议建立网络连接、并管理心跳、断线重连、端口绑定与释放。常见的协议包括HTTP、RMI、Hessian等。

    5.注册中心

    主要用于保存和更新服务的地址信息。

    三、服务发现与调用

    较服务发布与注册而言,服务发现与调用是一个导入的过程,基本和服务发布与注册是对称结构流程:

    1.调用启动器

    确定服务的调用形式并启动调用平台,与发布启动器一样。

    2.动态代理

    完成本地接口到远程调用的转换,导入服务提供者接口API和服务信息并生成远程服务的本地动态代理对象,将本地API调用转换成远程服务调用并返回调用结果。

    3.调用管理器

    具备缓存功能,保存服务地址的缓存信息。当从注册中心获取服务提供者地址信息时,调用管理器根据需要更新本地缓存,确保在注册中心不可用的情况下,调用启动器仍然可以从本地缓存中获取服务提供者的有效地址信息。

    4.协议客户端

    根据服务调用指定的协议类型创建客户端并发起连接请求,负责与协议服务器进行交互并获取调用结果。

    5.注册中心

    主要用于保存和更新服务的地址信息。

    四、服务监控

    如图,在微服务架构中的服务调用中,服务中间件、数据库、缓存、文件系统以及其他服务之间都有可能存在依赖关系,为了确保系统运行时这些依赖关系的稳定性和可用性,服务调用路径、服务调用的业务数据、服务性能数据都是需要监控的内容,以便于系统定位和防御故障问题。 

    基本思路:日志埋点

    1.使用跟踪ID作为一次完整应用调用的唯一标识,然后将该次调用的详细信息通过日志的方式进行保存。

    2.日志埋点分为客户端埋点和服务器埋点

    客户端埋点:关注于跟踪ID、客户端IP、调用方接口、调用时间等信息。

    服务器端埋点:关注于跟踪ID、调用方上下文、服务端耗时、处理结果等信息。

    3.日志埋点的作用分为两类

    一类用于服用调用跟踪把所有请求过程的日志能够关联起来;

    一类用于统计各服务的处理时间,一般通过记录服务调用的开始时间和结束时间计算并统计时间延迟。

    4.针对日志埋点产生的海量运行时数据,通常需要专门的工具进行处理埋点数据。

    基于Hadoop、Storm、Spark等技术的离线/实时批量处理框架;

    基于Elastic Search、Solr的垂直化搜索引擎;

    专门的Flume/ELK等日志处理框架

    5.在日志埋点过程中也可以使用抽样思想,并一定将所有的场景都进行日志埋点。

    基本目标:

    保障线上服务运行质量,治理的对象是基于统一分布式服务框架开发的各项业务数据。

    基本定位:

    关注服务运行时的状态、细粒度治理等。

    基本策略:

    服务限流、降级、服务动态路由和灰度发布等。

    具体实现:

    采用通过注册中心对服务以来进行分析,结合运行时调用关系,梳理不合理的依赖和调用路径,优化服务架构;

    实时收集服务调用日志,分析、汇总、存储和展示,方便开发和运维人员进行实时诊断;

    执行服务运行时治理方案,包括限流降级、路由、统一配置等在线调整。

    参考书籍、文献和资料:

    【1】郑天民. 微服务设计原理与架构. 北京:人民邮电出版社,2018.

    展开全文
  • Zookeeper用作注册中心的原理

    万次阅读 2019-05-25 19:29:08
    注册中心 :保存所有服务的名字,服务提供者的IP列表,服务消费者的IP列表 服务提供者: 提供跨进程服务 服务消费者: 寻找到指定命名的服务并消费。 Zookeeper用作注册中心 简单来讲,zookeeper可以充当一个服务...

    RPC框架中有3个重要的角色:
    Zookeeper用作注册中心的原理
    注册中心 :保存所有服务的名字,服务提供者的IP列表,服务消费者的IP列表

    服务提供者: 提供跨进程服务

    服务消费者: 寻找到指定命名的服务并消费。

    Zookeeper用作注册中心
    简单来讲,zookeeper可以充当一个服务注册表(Service Registry),让多个服务提供者形成一个集群,让服务消费者通过服务注册表获取具体的服务访问地址(IP+端口)去访问具体的服务提供者。如下图所示:
    在这里插入图片描述

    具体来说,zookeeper就是个分布式文件系统,每当一个服务提供者部署后都要将自己的服务注册到zookeeper的某一路径上: /{service}/{version}/{ip:port},比如我们的HelloWorldService部署到两台机器,那么zookeeper上就会创建两条目录:分别为/HelloWorldService/1.0.0/100.100.0.237:16888

    /HelloWorldService/1.0.0/100.100.0.238:16888。

    如图:
    在这里插入图片描述
    在zookeeper中,进行服务注册,实际上就是在zookeeper中创建了一个znode节点,该节点存储了该服务的IP、端口、调用方式(协议、序列化方式)等。该节点承担着最重要的职责,它由服务提供者(发布服务时)创建,以供服务消费者获取节点中的信息,从而定位到服务提供者真正网络拓扑位置以及得知如何调用。RPC服务注册、发现过程简述如下:

    1.服务提供者启动时,会将其服务名称,ip地址注册到配置中心。

    2.服务消费者在第一次调用服务时,会通过注册中心找到相应的服务的IP地址列表,并缓存到本地,以供后续使用。当消费者调用服务时,不会再去请求注册中心,而是直接通过负载均衡算法从IP列表中取一个服务提供者的服务器调用服务。

    3.当服务提供者的某台服务器宕机或下线时,相应的ip会从服务提供者IP列表中移除。同时,注册中心会将新的服务IP地址列表发送给服务消费者机器,缓存在消费者本机。

    4.当某个服务的所有服务器都下线了,那么这个服务也就下线了。

    5.同样,当服务提供者的某台服务器上线时,注册中心会将新的服务IP地址列表发送给服务消费者机器,缓存在消费者本机。

    6.服务提供方可以根据服务消费者的数量来作为服务下线的依据。

    感知服务的下线&上线

    zookeeper提供了“心跳检测”功能,它会定时向各个服务提供者发送一个请求(实际上建立的是一个 socket 长连接),如果长期没有响应,服务中心就认为该服务提供者已经“挂了”,并将其剔除。比如100.100.0.237这台机器如果宕机了,那么zookeeper上的路径就会只剩/HelloWorldService/1.0.0/100.100.0.238:16888。

    服务消费者会去监听相应路径(/HelloWorldService/1.0.0),一旦路径上的数据有任务变化(增加或减少),zookeeper都会通知服务消费方、服务提供者地址列表已经发生改变,从而进行更新。

    更为重要的是zookeeper 与生俱来的容错容灾能力(比如leader选举),可以确保服务注册表的高可用性。

    使用 zookeeper 作为注册中心时,客户端订阅服务时会向 zookeeper 注册自身;主要是方便对调用方进行统计、管理。但订阅时是否注册 client 不是必要行为,和不同的注册中心实现有关,例如使用 consul 时便没有注册。

    展开全文
  • 服务注册中心

    千次阅读 2018-07-25 21:34:48
    一、服务注册中心介绍 分布式服务框架部署在多台不同的机器上,例如服务提供者在集群A,服务调用者在集群B,那么B在调用A的服务的过程中,集群A的机器需要和集群B的机器进行通信。 抠张图看看  在上图中,有...
  • 注册中心搞什么?

    2018-12-06 18:02:00
    2019独角兽企业重金招聘Python工程师标准>>> ...
  • 注册中心注册服务

    2019-03-19 14:55:52
    注册中心注册服务 一. 搭建一个Springboot项目 二. 导入eureka的jar包 <?xml version="1.0" encoding="UTF-8"?> <project xmlns=...
  • 在向注册中心注册服务提供者时必须先搭建好服务注册中心,可参考Spring Cloud (一)、搭建服务注册中心。搭建好服务注册中心,现在我们开始向服务注册中心中注册服务提供者。 一、创建项目 创建项目的过程和搭建...
  • dubbo注册中心

    千次阅读 2019-06-13 14:17:12
    Dubbo目前支持4种注册中心,(multicast zookeeper redis simple) 推荐使用Zookeeper注册中心, Multicast注册中心 不需要启动任何中心节点,只要广播地址一样,就可以互相发现 组播受网络结构限制,只适合小规模...
  • 这是dubbo的基本结构,但几乎所有服务发现的注册中心都这样。服务提供方注册到注册中心,消费方订阅或者拉取提供者信息,发起调用。客户端设计客户端比较简单:1. 从注册中心拉取服务信息2. 维持服务信息缓存3. ...
  • 文章目录扯一扯软件环境步骤创建工程pom文件配置声明为注册中心属性配置yamlproperties坑效果下集预告 扯一扯 以下内容将引起极度舒适,请在女朋友的陪同下观看。什么?你没有女朋友?哦,不好意思,我忘了,程序员...
  • 此文档有关于服务注册中心。快速构建一个服务注册中心项目,并实现高可用,简单搭建一个服务提供者进行注册。
  • nacos作为配置中心和服务注册中心 的完整使用案例

    万次阅读 多人点赞 2020-06-26 01:24:45
    通过maven搭建一个springboot项目 第一步、下载并运行起nacos ...下载tar.gz或者zip包进行解压,进入bin,双击startup.cmd运行nacos ...第二步、引入依赖,编写yml配置文件 spring-cloud-alibaba的依赖管理 ...
  • 文章 史上最简单的 SpringCloud 教程 | 第一篇: 服务的注册与发现(Eureka) 介绍了服务注册与发现,其中服务注册中心Eureka Server,是一个实例,当成千上万个服务向它注册的时候,它的负载是非常高的,这在生产...
  • 服务注册中心之Eureka简介及原理

    万次阅读 2018-07-04 11:31:04
    服务注册中心对整个微服务架构起着最核心的整合作用,因此对Eureka还是有很大的必要进行深入研究。 在讨论Eureka前我们先来了解下其与zookeeper的区别: 著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性...
  • 参见(SpringCloud+Nacos 配置中心与注册中心应用) 2. 启动服务 3. API文档访问 4. 动态路由 只需要修改对应的配置文件即可,nacos会发起刷新 附录 网关配置 TIMEOUT.IN.MILLISECONDS: 60000 hystrix: command: ...
  • SpringCloud+Nacos 配置中心与注册中心应用 1. 版本说明 序号 名称 版本号 1 spring-boot 2.1.1.RELEASE 2 spring-cloud Greenwich.RELEASE 3 spring-cloud-alibaba 2.1.2.RELEASE 引入pom ...... &...
  • Nacos(二):SpringCloud项目中接入Nacos作为注册中心

    万次阅读 多人点赞 2019-07-09 17:18:01
    通过上一篇文章:Nacos介绍 简单了解了Nacos的发展历程和现状,本文我们开始Nacos试水的第一步: 使用Nacos做注册中心 上周末(7.6)Nacos发布了V1.1.0版本,这次更新支持灰度配置、地址服务器模式、配置文件导入...
  • 微服务之注册中心

    千次阅读 2019-06-24 10:34:43
    相关文章 服务描述 ... 注册中心 https://blog.csdn.net/haponchang/article/details/93467008 服务框架 https://blog.csdn.net/haponchang/article/details/934680...

空空如也

1 2 3 4 5 ... 20
收藏数 250,880
精华内容 100,352
关键字:

注册中心