精华内容
下载资源
问答
  • 注册中心
    千次阅读
    2022-03-28 23:01:15

    1、服务注册中心分类

    • 应用内:直接集成到应用中,依赖于应用自身完成服务的注册与发现,最典型的是Netflix提供的Eureka,还可以基于ZooKeeper或者Etcd自行实现一套服务注册机制

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

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

     

    2、CAP理论

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

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

      在分布式系统内,P 是必然的发生的,不选 P,一旦发生分区错误,整个分布式系统就完全无法使用了,这是不符合实际需要的。所以,对于分布式系统,我们只能能考虑当发生分区错误时,如何选择一致性和可用性。

      根据一致性和可用性的选择不同,开源的分布式系统往往又被分为 CP 系统和 AP 系统。

    • 当一套系统在发生分区故障后,客户端的任何请求都被卡死或者超时,但是,系统的每个节点总是会返回一致的数据,则这套系统就是 CP 系统,经典的比如 Zookeeper。

    • 如果一套系统发生分区故障后,客户端依然可以访问系统,但是获取的数据有的是新的数据,有的还是老数据,那么这套系统就是 AP 系统,经典的比如 Eureka。
       

    3、各注册中心特性对比

    特性NacosEurekaConsulETCDZookeeperCoreDNS
    一致性协议CP+APAPCPCPCP
    健康检查TCP/HTTP/MYSQL/Client BeatClient BeatTCP/HTTP/gRPC/CmdClient BeatKeep Alive
    负载均衡策略权重/ metadata/SelectorRibbonFabio轮询-RoundRobin
    雪崩保护
    自动注销实例支持支持支持支持支持不支持
    访问协议HTTP/DNSHTTPHTTP/DNSHTTP/GRPCTCPDNS
    监听支持支持支持支持支持(3.0)支持不支持
    安全acl-acl / httpshttpsacl-
    多数据中心支持支持支持-不支持不支持
    作为配置中心支持不支持支持支持支持不支持
    跨注册中心同步支持不支持支持-不支持不支持
    SpringCloud集成支持支持支持支持支持不支持
    Dubbo集成支持不支持支持支持支持不支持
    K8S集成支持不支持支持支持不支持不支持

    其中,- 表示不确定,不是不支持,有知道的大佬可以告知我补充一下!
     

      实践中,在 CAP 的权衡中,注册中心的可用性比数据强一致性更宝贵,所以整体设计更应该偏向 AP,而非 CP,注册中心不能因为自身的任何原因破坏服务之间本身的可连通性

     

    4、各方案说明

    Eureka

       Eureka 遵循AP原理中的「AP」原则,Eureka的集群中,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性),当数据出现不一致时,虽然A, B上的注册信息不完全相同,但每个Eureka节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求A查不到,但请求B就能查到。

       Eureka2.0已经停止维护.

     

    Consul

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

     

    Zookeeper

       Zookeeper 遵循CAP原理中的「CP」原则,任何时候对 Zookeeper 的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性,但是 Zookeeper 不能保证每次服务请求都是可达的,不能保证服务可用性。

     

    ETCD

       ETCD遵循CAP原理中的「CP」原则,在选主完成前会导致服务不可用。
     

    Nacos

      Nacos 的注册中心支持 CP 也支持 AP。

     
     
    参考链接:
    https://glory.blog.csdn.net/article/details/100023415
    https://blog.csdn.net/u012921921/article/details/106521181
    https://blog.csdn.net/qq_42046105/article/details/123436832
    https://blog.csdn.net/weixin_41605937/article/details/121885248
     
    如有不对,烦请指出,感谢~

    更多相关内容
  • 【RPC】注册中心

    千次阅读 2022-06-30 16:40:27
    注册中心是什么?看到“注册”两个字,最想想到的就是访问有些平台需要登陆账号,我们可以通过注册账号的方式获得一个合规的登陆账号,用于访问相关平台。在微服务架构体系中,注册中心是一个用来提供服务注册的重要...

    本文章介绍什么是注册中心?为什么要有注册中心,它解决了什么问题?同时,带来了哪些弊端?

    注册中心是什么?看到“注册”两个字,最想想到的就是访问有些平台需要登陆账号,我们可以通过注册账号的方式获得一个合规的登陆账号,用于访问相关平台。

    在微服务架构体系中,注册中心是一个用来提供服务注册的重要组件,他本身就是一个服务。RPC中的服务暴露的过程,其中服务导出到远程的过程就会将服务注册到注册中心。将服务注册到注册中心,本质上就是将服务的信息存储在注册中心的Server端,和注册账号的行为非常类似。注册中心管理者服务的这些信息:服务提供者和服务消费者的地址信息、服务接口的全限定名,并且管理这些信息的关系。

    • 服务提供者的地址信息与服务接口的全限定名是多对多的关系:在分布式系统中,一个服务一般会都会部署在多个节点上,所以一个服务会有多个服务提供者,这种关系有一个名称叫做集群。集群部署服务是为了保证服务高吞吐量、高可用,而一个服务提供者的地址上也会提供多个服务接口。
    • 服务接口的全限定名与服务消费者的地址信息是多对多的关系:一个服务消费者可以依赖多个服务,所以可以调用多个服务。反过来看,一个服务也可以被多个消费者所消费。
    • 服务提供者的地址信息和服务消费者的地址信息的关系不确定:服务提供者和服务消费者之间的关系应该是多对多的关系,但是从注册中心存储的数据来看,服务提供者的地址信息和服务消费者的地址信息之间没有直接的关联,它们都需要根据服务接口的全限定名进行关联。只有当服务限定名确定的时候,服务提供者的地址和服务消费者的地址之间才是多对多的关系。服务提供者能够被多个服务消费者进行服务发现,除此之外,在进行某个服务的服务发现时,服务消费者需要获得服务提供者的地址。虽然每一次的 RPC 调用仅需要服务提供者中的一个节点,但服务消费者还是会持有所有该服务的提供者,以满足一些流量负载均衡等需求。

    最基础的注册中心只需要接口全限定名、服务提供者的地址和服务消费的地址这三个内容即可提供注册中心的能力。但是在微服务架构中,服务的理解是非常重要的。


    那么注册中心到底为什么重要?它到底解决了哪些痛点问题?它在微服务架构体系中承担着什么样的角色?

    来看两个场景:

    • 场景一

    在两台服务器上部署了两个服务,分别是服务A和服务B,服务A依赖于服务B,如果需要调用服务B中的方法,那么服务A就需要与服务B进行远程通信。通信的必要条件之一就是服务A需要知道服务B的服务器的地址及服务绑定的端口B。设想一下,如果没有注册中心会出现什么情况?服务A需要在自己这边维护一份服务B的地址和端口号信息。当发生服务迁移时,假设服务B的地址变了,那么就必须要在服务A中手动修改维护的信息,并且重启服务A。

    在真实的生产环境中,为了保证服务的高可用,服务部署不会出现单点状态,也就是服务不会仅部署在同一台服务器上,基本上会部署在集群内。由于业务的扩张,流量增大,需要对服务B进行横向扩容。如果没有注册中心,这时也需要手动修改配置。配置项越多,需要维护的地址越多,维护的成本就越大。

    • 场景二

    服务A依赖于服务B,由于一些原因需要对服务B中的节点1所在的机器做隔离,这时节点1是不希望有请求被路由到本台机器上的。为了让该节点隔离更加迅速和平滑,需要解决两个核心问题,分别是如何保证服务B的节点1隔离时通知客户端不再发送请求到节点1,以及如何保证服务消费者不再发起与节点1建立新连接的请求。

    针对第一个问题,可以通过消息通道从服务B发送隔离通知消息给服务A,因为目前许多网络应用框架都支持双向通信,比如用Netty、Grizzly等建立的通信通道就是双向的。服务A收到隔离通知消息后,能够感知该节点不可用,所以可以保证不在发送请求到该节点。

    为什么要解决第二个问题呢? 因为解决第一个问题后,现有连接中不再有新的请求进入该节点,但是如果在隔离时建立新的连接,那么就无法保证新的连接没有请求进入节点1 。所以除了保证旧连接中没有请求,还要保证不会建立新的连接。针对第二个问题,没有注册中心会比较麻烦。假设没有注册中心,那么服务A肯定维护了服务B的节点1的信息,所以在服务B的节点1被隔离之前,必须先修改服务A中的配置并重启服务A,保证服务A不再路由到服务B的节点1,并且不再对节点1发起建立连接的请求,然后才能完成节点1的隔离。仅仅是一个节点的流量隔离,却要牵扯上游服务,这种做法增大了运维成本,是一种非常烦琐且不优雅的行为。


    通过上述两个例子能够直观地感受到注册中心的重要性。概括地说,如果只是按照直连的方式而不是通过注册中心进行远程过程调用,则会有以下弊端

    • 服务消费者需要维护服务提供者的地址信息,随着服务节点增多,部署规模变大,弹性扩/缩容、流量隔离等需求量越来越大,维护的地址信息不管是增删还是修改,都需要手动修改配置,维护成本也随之上升。
    • 服务节点在下线或者隔离时无法做到足够平滑和优雅,还是会有部分流量被分配到该节点上。
    • 故障的服务节点只有在服务消费者请求失败后才能够被感知,服务本身一般不会提供自检的能力,只能通过定时脚本去做服务的健康检查。“人”是一个不确定的因素,就算配置了异常告警,比如短信告警、邮件告警、电话告警等,工程师也有可能由于手机没开提示音等原因而错过了告警信息,导致服务异常的影响面扩大。

    要解决上述的三个弊端,就需要在服务消费者和服务提供者中间新增一个注册中心组件,如下图所示。
    在这里插入图片描述

    图中的 4 个箭头分别代表了注册中心的 4 个核心功能:

    • register:表明了服务提供者会将服务信息注册到注册中心,注册中心管理该服务的地址、接口等信息。
    • subscribe: 表明了服务消费者在做服务发现时会从注册中心获取目标服务的所有节点信息,作为自己远程通信的条件。所谓订阅的含义远不止拉取节点信息这么简单,它主要是在注册中心中存储了自己的服务信息,让注册中心知道哪些 Consumer 正在消费这个服务,以方便后面的 notify 操作。
    • notify:表明了一旦该服务的节点信息变更,注册中心就会通知所有订阅了该服务的Consumer。有了该机制,在面对上述提到的弹性扩/缩容、服务宕机立即下线等会造成服务节点信息变更的情况时,就能够保证服务消费者可以及时感知最新且可靠的服务节点,防止因为个别节点下线不平滑导致的大面积请求失败的局面发生。
    • check:表明了注册中心一般会与服务消费者有一个健康检查的机制,或许是心跳,又或许是长连接的 keepalive 等机制,目前不同的注册中心的实现方案有着不同的健康检查机制。

    使用注册中心到底带来了哪些收益呢?

    • 第一个收益当然就是释放了劳动力,节约了人力成本,降低了因工程师手动维护节点信息而导致失误的概率。
    • 第二个收益是进一步降低了消费者在选择服务提供者的时候选择到不可用的服务提供者的概率。
    • 第三个收益就是服务提供者和服务消费者实现解耦,在整个微服务架构设计中增加注册中心,能够保证服务消费者不在强依赖于服务提供者的地址信息。
    • 第四个收益是为负载均衡策略等提供服务节点的数据,因为注册中心会维护某个服务有哪些服务消费者、有哪些服务提供者的信息。

    同时,注册中心也引入了一些问题。

    首先就是注册中心自身的高可用问题,注册中心是一个服务,在分布式系统中,如果只有一个注册中心节点,就会出现单点问题,也就是当这个注册中心服务“挂了”之后,注册中心将无法提供服务发现、服务注册、健康检查等能力,最严重的就是服务消费者无法获取服务提供者最新的地址信息。虽然可以在 Consumer 端缓存旧的服务提供者地址信息,但是只要其中一个 Provider节点不可用,就会导致大量的调用失败。所以注册中心不能有单点问题,要解决单点问题,就需要部署多个注册中心节点。由于必须部署多个注册中心节点,并且注册中心内维护的信息是实时改变的,注册中心是一个有状态的服务,所以它将面临多个注册中心节点之间的数据一致性问题。针对分布式中数据一致性问题,就会涉及 CAP 定理。如何在一致性(C)、可用性(A)、分区容错性(P)中做选择,将是注册中心一直会面临的问题。

    展开全文
  • Nacos注册中心的部署与用法详细介绍

    万次阅读 2022-02-13 22:48:44
    注册中心是微服务架构中的纽带,类似于”通讯录“,它记录了服务和服务地址的映射关系。在分布式架构中,服务会注册到这里,当服务需要调用其它服务时,就到这里找到服务的地址并进行调用。注册中心本质上是为了解耦...

    一、什么是注册中心:

             我们知道微服务彼此间独立部署、具有清晰的边界,服务间通过远程调用来构建复杂的业务功能。而服务册中心在微服务项目中扮演着非常重要的角色,那么注册中心又是什么,使用服务注册中心可以解决微服务中的哪些问题呢?

    1、什么是注册中心:

            注册中心是微服务架构中的纽带,类似于“通讯录”,它记录了服务和服务地址的映射关系。在分布式架构中,服务会注册到这里,当服务需要调用其它服务时,就到这里找到服务的地址并进行调用。注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务,原则上都应存在或者支持多个提供者,这是由微服务的分布式属性决定的,更进一步,为了支持弹性扩缩容特性,一个微服务的提供者的数量和分布往往是动态变化的,也是无法预先确定的。因此,原本在单体应用阶段常用的静态LB机制就不再适用了,需要引入额外的组件来管理微服务提供者的注册与发现,而这个组件就是服务注册中心。

     2、注册中心的核心功能:

    • 服务注册:服务实例将自身服务信息注册到注册中心
    • 服务发现:服务实例通过注册中心,获取到注册到其中的服务实例的信息,通过这些信息去请求它们提供的服务
    • 服务剔除:服务注册中心将出问题的服务自动剔除到可用列表之外,使其不会被调用到

    3、注册中心解决的问题:

    (1)屏蔽、解耦服务之间相互依赖的细节:

            服务之间的远程调用必须要知道对方IP、端口。但是该调用方式存在明显的问题,如被调用的IP、端口变化后,调用方也要同步修改。通过服务发现,将服务之间IP与端口的依赖转化为服务名的依赖,服务名可以根据具体微服务业务来做标识。

    (2)对服务进行动态管理:

            在微服务架构中,服务数量多且依赖错综复杂,无论是服务主动停止、意外挂掉,还是因为流量增加对服务扩容,这些服务状态上的动态变化,都需要尽快的通知到被调用方,被调用方才采取相应的措施。所以,对于服务注册中心要实时管理服务的数据与状态,包括服务的注册上线、服务主动下线,异常服务的剔除。

    (3)降低服务端负载均衡中间件的压力:

            当服务越来越多时,服务 URL 配置管理变得非常困难,服务端的负载均衡中间件,比如 F5、Nginx 压力也越来越大。通过服务注册中心,就可以实现动态地注册和发现服务,使服务的位置透明,并通过在消费方获取服务提供方地址列表,实现软负载均衡和 Failover,降低对服务端的负载均衡中间件,也能减少部分成本。

    4、服务的发现与注册的实现模式:

            上面提到,硬件的 F5、软件的 Nginx 也可以实现服务的发现,那么这与注册中心的服务发现有什么区别呢?这其实是服务发现与注册的两种实现模式:服务端的发现模式 和 客户端的发现模式。F5、Nginx 属于服务端的发现模式,服务注册中心属于客户端的发现模式,两种模式各有优缺点,也适用于不同的场景,对于大型应用一般会有多层负载,外层用服务器端负载均衡,内部用客户端负载均衡。接下来我们就具体看看两种服务发现模式是怎么样的:

    (1)服务端的发现模式:

            服务端的发现模式是通过使用一个中间的服务器,来屏蔽被调用服务的复杂性与变动性,当有新的服务加入或老服务剔除时,只需要修改中间服务器上的配置即可,此模式的显著特点是:引入独立的中间代理服务器来屏蔽真实服务的具体细节。

            如下图所示:当服务A要调用服务B时,先通过 DNS 域名解析找到 Nginx 服务器,然后将请求发送给Nginx,因为在 Nginx 上配置了服务B的真实访问地址,Nginx 收到请求后根据负载均衡算法,将请求转发到某个真实的服务B,服务B将请求结果返回给 Nginx,Nginx 再将返回结果给服务A,整个请求流程结束。当然中间服务器不一定非得是 Nginx,还可以是基于硬件的 F5,也可以是工作在传输层的 IP 负载均衡等。

            该模式的优点是:配置集中在独立的中间服务器端完成,对代码没有任何入侵,也不存在跨平台跨语言的问题。但缺点也很明显,因为所有请求都需要穿透中间服务器,所以中间服务器会成为一个单点,对性能也会有所影响。

    (2)客户端的发现模式:

            我们再看看客户端的发现模式,服务A调用服务B时,不需要通过中间服务器,而是在自己进程内维护了服务B的信息,再通过负载算法选择一个服务B直接调用。那服务A具体是怎么维护服务B的信息呢?为此引入了服务注册中心的概念,当服务B启动时向注册中心注册自己(将自己的信息发送到注册中心的注册表里),服务A再从注册中心获取所有注册的服务,这就是客户端模式的基本原理。

            客户端模式因为在进程内直接调用服务,也叫做进程内负载,由于不需要穿透中间服务器,所以客户端模式的性能损耗比较小。但是,需要在服务内部维护服务注册信息,负载算法等,有一定的代码入侵性,对于跨平台,跨语言的支持不太友好。

    5、服务注册表:

            微服务架构中,所有的服务启动后都通过注册中心来注册自己,同时把注册中心里面的服务信息拉回本地,后续调用时就直接检查本地的服务和节点信息来进行服务节点的调用。每个服务节点都会来注册中心进行服务注册,那注册信息是如何在服务端保存的呢,其实就是注册表,服务注册的时候把自己的信息上报上来,然后注册中心把注册表,返回给客户端,那服务之间就知道要调用服务的节点了。

            服务注册表需要高可用而且随时更新。客户端能够缓存从服务注册表中获取的服务地址,然而,这些信息最终会过时,客户端也就无法发现服务实例。因此,服务注册表会包含若干服务端,并使用复制协议保持一致性。服务注册表不能是单点,否则存在单点故障,当服务注册表有多台服务器的时需要考虑服务注册表的信息在多台机器上的实时同步和一致。

    二、主流服务注册中心的对比:

     (1)Zookeeper 和 Consul 遵循 CP 原则,保证了强一致性和分区容错性,放弃可用性,在分布式环境中,如果涉及数据存储的场景,数据一致性应该是首先被保证的,但对于服务发现来说,可用性才是最核心的,针对同一个服务,即使注册中心的不同节点保存的服务提供者信息不相同,也并不会造成灾难性的后果。因为对于服务消费者来说,能消费才是最重要的,消费者拿到不正确的服务实例信息后尝试消费一下,也胜过因为无法获取实例信息而不去消费而导致系统异常

    (2)Eureka 遵循 AP 原则,保证可用性,放弃数据一致性,基本能满足注册中心所需的核心功能,但 Eureka 2.x 版本已停止开发,并且宣布如果继续使用的话,风险自负。

    (3)Nacos 同时支持 AP 与 CP,默认是 AP,同时功能更丰富,与 SpringCloud Alibaba 的兼容性更好,使用更简单灵活,可以满足更多的业务场景,且支持 K8S 的集成。

    不同的服务注册中心组件的应用场景不同,读者可以根据自己的业务情况进行选型。但下文我们主要以 Nacos 注册中心为例进行介绍,其他几种注册中心读者自行上网查阅

    三、Nacos 注册中心的部署与使用:

    1、Nacos 注册中心的搭建:

            我们先去 Nacos 的 Github(Tags · alibaba/nacos · GitHub)下载我们所需的 Nacos 版本,可以选择 windows 或者 Linux,如下图:

            由于当时在搭建项目的时候,考虑到与 SpringBoot 和 SpringCloud 的版本对应问题,我这里是下载了 2.0.0 的版本进行搭建,读者可以根据自己的情况选择对应的 Nacos 版本。

     1.1、Windows 环境:

    下载并解压 nacos-server-2.0.0.zip,解压完成后进入 /bin 目录,可以看到下面两个脚本:

    windows 环境直接运行 startup.cmd 启动项目,出现以下界面则启动完成:

    在浏览器输入 http://localhost:8848/nacos 进入Nacos的登录界面,用户名与密码默认都是 nacos,登录成功后界面如下:

    1.2、Linux 环境:

            Nacos 在 Linux 环境下的启停跟在 windows 环境的启停基本一致,先下载 nacos-server-2.0.0.tar.zip 压缩包,然后上传到 Linux 服务器上进行解压(解压命令:tar -zxvf nacos-server-2.0.0.tar.gz),解压完成后同样进入 /bin 目录执行启动命令(单机模式启动命令:sh startup.sh -m standalone),启动完成后再访问 nacos 控制台地址(http://服务器ip地址:8848/nacos/index.html)验证是否成功启动即可。

    2、SpringBoot 整合 Nacos 进行服务注册发现:

    我们首先看一下 nacos 的简单架构图:

    参照上面的架构图,我们分别创建两个模块,分别是 cloud-producer-server(服务提供者)、cloud-consumer(服务消费者),职责如下:

    • cloud-producer-server:注册进入nacos-server,对外暴露服务
    • cloud-consumer:注册进入nacos-server,调用 cloud-producer-server 的服务

    创建这两个模块前,我们先声明项目的版本信息:

    <properties>
        <spring-boot.version>2.3.2.RELEASE</spring-boot.version>
        <spring-cloud.version>Hoxton.SR9</spring-cloud.version>
        <spring-cloud-alibaba.version>2.2.6.RELEASE</spring-cloud-alibaba.version>
    </properties>
    
    <!--  只声明依赖,不引入依赖 -->
    <dependencyManagement>
        <dependencies>
            <!-- 声明springBoot版本 -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>${spring-boot.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <!-- 声明springCloud版本 -->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <!-- 声明 springCloud Alibaba 版本 -->
            <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>${spring-cloud-alibaba.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    2.1、创建服务提供者 cloud-producer-server:

    (1)引入maven依赖:

      	<!-- 引入阿里的nacos作为服务注册中心 -->
    	<dependency>
          <groupId>com.alibaba.cloud</groupId>
          <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    	</dependency>

    (2)添加 nacos 相关的配置信息:

    在 application.properties 配置文件指定服务名称、端口号、nacos-server 的地址信息,如下:

    spring.application.name = cloud-producer-server
    server.servlet.context-path = /${spring.application.name}
    server.port=9000
    
    # nacos注册中心配置
    spring.cloud.nacos.discovery.server-addr = localhost:8848
    spring.cloud.nacos.discovery.namespace = 91b5489b-d009-4725-86fa-534f760b4d04
    spring.cloud.nacos.discovery.register-enabled = true

    (3)开启服务注册发现的功能:

    在主 Application 启动类加入 @EnableDiscoveryClient 注解开启服务注册发现的功能,如下:

    /**
     * SpringBoot启动类
     * @EnableDiscoveryClient 开启服务注册发现的功能
     */
    @EnableDiscoveryClient
    @SpringBootApplication
    public class ProducerApplication
    {
    	public static void main(String[] args)
    	{
    		SpringApplication.run(ProducerApplication.class, args);
    	}
    }

    (4)实现个演示功能:

            cloud-producer-server 作为服务提供者注册到 nacos 中,肯定需要提供个服务来供消费者 cloud-consumer 调用,下面简单写一个演示接口:

    @RestController
    @RequestMapping (value = "/")
    public class CloudController
    {
        @PostMapping ("getSum")
        public String getSum(@RequestParam (value = "num1") Integer num1, @RequestParam (value = "num2") Integer num2)
        {
             return "success:两数求和结果=" + (num1 + num2);
        }
    }

    (5)启动项目:

            启动项目之后,我们进入 nacos 控制台,在 nacos 的 “服务管理->服务列表” 的 “91b5489b-d009-4725-86fa-534f760b4d04” 空间中将会发现注册进入的 cloud-producer-server 这个服务,如下图:

     2.2、创建服务消费者 cloud-consumer:

    服务消费者的创建步骤与服务提供者基本一致

    (1)引入maven依赖:

      	<!-- 引入阿里的nacos作为服务注册中心 -->
    	<dependency>
          <groupId>com.alibaba.cloud</groupId>
          <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    	</dependency>

    (2)添加 nacos 相关的配置信息:

    spring.application.name = cloud-consumer
    server.port=9001
    
    # nacos注册中心配置
    spring.cloud.nacos.discovery.server-addr = localhost:8848
    spring.cloud.nacos.discovery.namespace = 91b5489b-d009-4725-86fa-534f760b4d04
    spring.cloud.nacos.discovery.register-enabled = true

    (3)开启服务注册发现的功能:

    /**
     * SpringBoot启动类
     * @EnableDiscoveryClient 开启服务注册发现的功能
     */
    @EnableDiscoveryClient
    @SpringBootApplication
    public class ConsumerApplication
    {
    	public static void main(String[] args)
    	{
    		SpringApplication.run(ConsumerApplication.class, args);
    	}
    }

    (4)调用服务提供方的演示功能:

            cloud-producer-server 服务提供方提供一个演示功能,那我们如何调用该功能呢?其实 Nacos 集成了 Ribbon(有关 Ribbon 的详细介绍请参考这篇文章:https://blog.csdn.net/a745233700/article/details/122916856),因此我们便能使用 Ribbon 的负载均衡来调用服务,步骤如下:

    ① 创建 RestTemplate,使用 @LoadBalanced 注解标注开启负载均衡:

    @Configuration
    public class RestConfig
    {
        /**
         * 创建restTemplate对象。
         * LoadBalanced注解表示赋予restTemplate使用Ribbon的负载均衡的能力(一定要加上注解,否则无法远程调用)
         */
        @Bean
        @LoadBalanced
        public RestTemplate restTemplate(){
            return new RestTemplate();
        }
    }

    ② 通过 RestTemplate 请求远程服务地址并接收返回值

    @RestController
    @RequestMapping (value = "api/invoke")
    public class InvokeController
    {
        @Autowired
        private RestTemplate restTemplate;
    
        /**
         * 使用 RestTemplate 进行远程服务调用,并且使用 Ribbon 进行负载均衡
         */
        @ApiOperation (value = "RestTemplate", notes = "使用RestTemplate进行远程服务调用,并使用Ribbon进行负载均衡")
        @GetMapping ("getByRestTemplate")
        public String getByRestTemplate(Integer num1, Integer num2)
        {
            //第一个cloud-producer-server代表在nacos注册中心中的服务名,第二个cloud-producer-server代表contextPath配置的项目路径
            String url = "http://cloud-producer-server/cloud-producer-server/getSum";
            MultiValueMap<String, Object> params = new LinkedMultiValueMap<>();
            params.add("num1", num1);
            params.add("num2", num2);
    
            //通过服务名的方式调用远程服务(非ip端口)
            return restTemplate.postForObject(url, params, String.class);
        }
    }

    (5)启动测试,查看nacos注册中心控制面板情况

            启动成功后将会在 nacos 中的服务列表中看到 cloud-consumer,如下图:

     那么接下来就测试下服务能否调的通?访问服务消费方的 api/invoke/getByRestTemplate接口,可以看到请求结果如下:

    3、Nacos 的集群化部署:

            前面的介绍中,我们并未对 Nacos 服务端做任何特殊的配置,一切均以默认的单机模式运行,但是单机运行模式仅适用于学习与测试环境,对于有高可用要求的生产环境显然是不合适的。那我们怎么搭建支持高可用的集群环境呢?

            在搭建 Nacos 集群前,我们需要先修改 Nacos 的数据持久化配置为 MySQL 存储。默认情况下,Nacos 使用内嵌的数据库 Derby实现数据的存储,这种情况下,如果启动多个默认配置下的 Nacos 节点,数据存储是存在一致性问题的。为了解决这个问题,Nacos 采用了集中式存储的方式来支持集群化部署,但目前 Nacos 只支持 MySQL 的存储,且版本要求:5.6.5+

    3.1、Nacos 配置的持久化:

    (1)初始化 MySQL 数据库:

            首先在 MySQL 中新建一个数据库 nacos-config(名称随意),然后执行 Nacos 中的SQL脚本,该脚本是 Nacos-server 的 conf 文件夹中的 nacos-mysql.sql,如下图:

    执行该脚本,将会自动创建表,如下图:

     (2)修改 conf/application.properties 配置文件:

            Nacos-server 也是一个Spring Boot 项目,想要连接自己的数据库,当然要配置数据源了,配置文件同样在 Nacos-server 中的 conf 目录下,如下图:

     只需要将 application.properties 中的 Mysql 配置成自己的数据源并重启 Nacos-server 即可 ,如下:

    # 此项一定要启用,默认是注释掉的
    spring.datasource.platform=mysql
    
    # 注意MySQL8.0以上版本指定url时一定要带入serverTimezone参数
    db.num=1
    db.url.0=jdbc:mysql://localhost:3306/nacos_config?serverTimezone=Asia/Shanghai&characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
    db.user=root
    db.password=123456
    
    # 可选启用配置
    nacos.cmdb.dumpTaskInterval=3600
    nacos.cmdb.eventTaskInterval=10
    nacos.cmdb.labelTaskInterval=300
    nacos.cmdb.loadDataAtStart=false

    3.2、Nacos 集群化部署:

            Nacos 官方推荐在生产环境使用集群模式部署,这样可以避免单点故障,集群化部署的架构图如下:

    ​        请求先通过 Nginx 集群进行转发到 Nacos 集群中,当然为了保持高可用,数据库也需要是集群模式。那么接下来我们就演示下搭建 Nacos 集群的方法。

    ​        由于条件限制,我们仅在一台服务器上启动三个Nacos服务演示。Nacos的端口分别为8848、8849、8850。

    (1)修改端口号:

    ​        Nacos 默认的端口号是 8848,那么如何修改端口呢?只需要修改 conf 目录下的 application.properties 中的 server.port 即可,如下图:

    (2)修改集群配置:

    那么如何配置集群呢?在 conf 目录下有一个 cluster.conf.example 文件,如下图:

    只需要将 cluster.conf.example 这个文件复制一份为 cluster.conf 放在 conf 目录下,其中配置的内容如下:

    172.16.1.84:8848
    172.16.1.84:8849
    172.16.1.84:8850

    (3)修改数据源:

    这个在持久化的那里已经讲过了,只需要将 application.properties 中的数据源替换掉,如下:

    # 此项一定要启用,默认是注释掉的
    spring.datasource.platform=mysql
    
    # 注意MySQL8.0以上版本指定url时一定要带入serverTimezone参数
    db.num=1
    db.url.0=jdbc:mysql://localhost:3306/nacos_config?serverTimezone=Asia/Shanghai&characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
    db.user=root
    db.password=123456
    
    # 可选启用配置
    nacos.cmdb.dumpTaskInterval=3600
    nacos.cmdb.eventTaskInterval=10
    nacos.cmdb.labelTaskInterval=300
    nacos.cmdb.loadDataAtStart=false

    (4)启动Nacos:

            经过上述的步骤 Nacos 集群已经配置好了,启动 Nacos 成功后,访问任意一个端口的 Nacos 服务,在 “集群管理->节点列表” 中将会看到自己搭建的三个节点,如下图:

    至此,Nacos集群算是搭建完成了

    (5)Nginx 中的配置:

    此处就不演示Nginx集群搭建了,直接在单机的Nginx中配置。直接修改nginx的conf文件,内容如下:

    upstream nacos{
    		server 172.16.1.84:8848;
    		server 172.16.1.84:8849;
    		server 172.16.1.84:8850;
    	 }
    	 
    	 server{
    		listen 80;
    		location / {
    			proxy_pass http://nacos;
    		}
    	 }

    (6)项目中配置 server-addr:

    既然搭建了集群,那么项目中也要配置一下,有两种方式,下面分别介绍:

    第一种:通过直连的方式配置,如下:

    spring:
      application:
        ## 指定服务名称,在nacos中的名字
        name: cloud-producer-server
      cloud:
        nacos:
          discovery:
            # nacos的服务地址,nacos-server中IP地址:端口号
            server-addr: 172.16.1.84:8848,172.16.1.84:8849,172.16.1.84:8850

    第二种:直接连接Nginx,如下:

    spring:
      application:
        ## 指定服务名称,在nacos中的名字
        name: cloud-producer-server
      cloud:
        nacos:
          discovery:
            # nacos的服务地址,nacos-server中IP地址:端口号
            server-addr: 172.16.1.84:80

    Nacos 集群搭建非常简单,唯一的配置就是在 cluster.conf 中设置三个 Nacos 服务的地址。


    相关阅读:

    常见的服务器架构入门:从单体架构、EAI 到 SOA 再到微服务和 ServiceMesh

    常见分布式理论(CAP、BASE)和一致性协议(Gosssip协议、Raft一致性算法)

    一致性哈希算法原理详解

    Nacos注册中心的部署与用法详细介绍

    Nacos配置中心用法详细介绍

    SpringCloud OpenFeign 远程HTTP服务调用用法与原理

    什么是RPC?RPC框架dubbo的核心流程

    服务容错设计:流量控制、服务熔断、服务降级

    sentinel 限流熔断神器详细介绍

    Sentinel 规则持久化到 apollo 配置中心

    Sentinel-Dashboard 与 apollo 规则的相互同步

    Spring Cloud Gateway 服务网关的部署与使用详细介绍

    Spring Cloud Gateway 整合 sentinel 实现流控熔断

    Spring Cloud Gateway 整合 knife4j 聚合接口文档

    常见分布式事务详解(2PC、3PC、TCC、Saga、本地事务表、MQ事务消息、最大努力通知)

    分布式事务Seata原理

    RocketMQ事务消息原理


    参考文章:

    微服务为什么要有服务发现与注册?

    五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强?

    展开全文
  • SpringCloud常见服务注册中心

    千次阅读 多人点赞 2022-02-23 14:02:10
    SpringCloud常用注册中心组件:eureka(netfix),zookeeper(java),consul(Go),nacos(java阿里巴巴)

     🍅程序员小王的博客:程序员小王的博客  ​​​​​​                                                                         

     🍅 欢迎点赞 👍 收藏 ⭐留言 📝                                                                                         

     🍅 如有编辑错误联系作者,如果有比较好的文章欢迎分享给我,我会取其精华去其糟粕 

     🍅java自学的学习路线:java自学的学习路线

    一、什么是SpringCloud

    1、定义

    • 官方定义: springcloud为开发人员提供了在分布式系统中快速构建一些通用模式的工具(例如配置管理(配置管理组件)、服务发现(服务注册中心)、断路器(服务熔断)、集成路由(网关)、微代理、控制总线(完成自动配置刷新))

    • 通俗定义:springcloud是一个含概多个子项目的开发工具集,集合了众多的开源框架

    2、微服务

    • 基于单体业务进行拆分,每个服务都是独立应用,独立部署 运行在自己计算机进程,对于这些服务都是分布式管理

    二、SpringCloud版本命名和SpringBoot版本选择

    1、SpringCloud命名 数字命名

    定义:SpringCloud涵盖众多子项目工具集 服务发现,服务注册,负载均衡,子项目版本使用数字

    • 早期命名:选择伦敦的地铁站名称作为发布版本的命名

                    ` Angel、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton,敦地铁站的名称(“天使”是第一个版本,“布里斯顿”是第二个版本,"卡姆登"是第三个版本)`
      
    • 后期改为: 2021.0.0

    2、SpringCloud和SpringBoot的版本对应关系

    1. Angel                     版本基于springboot1.2.x版本构建与1.3版本不兼容
    
    2. Brixton                    版本基于springboot1.3.x版本构建与1.2版本不兼容
      `2017年Brixton and Angel release官方宣布报废
      
    3. Camden                    版本基于springboot1.4.x版本构建并在1.5版本通过测试
      `2018年Camden release官方宣布报废
      
    4. Dalston、Edgware          版本基于springboot1.5.x版本构建目前不能再springboot2.0.x版本中使用
      `Dalston(达尔斯顿)将于2018年12月官方宣布报废。Edgware将遵循Spring Boot 1.5.x的生命周期结束。
      
    5. Finchley                   版本基于springboot2.0.x版本进行构建,不能兼容1.x版本
    
    6. Greenwich                  版本基于springboot2.1.x版本进行构建,不能兼容1.x版本
    
    7. Hoxton                      版本基于springboot2.2.x版本进行构建
    
    8. 2020.0.x aka Ilford         版本基于springboot 2.4.x, 2.5.x (Starting with 2020.0.3)
    
    9. 2021.0.x aka Jubilee       版本基于springboot 2.6.x
    
    
    

    三、SpringCloud的环境搭建

    1、微服务

    • 定义:基于单个应用围绕业务进行拆分,拆分出来每一个服务独立项目 ,单独部署,运行自己计算机进程(不是部署在一台计算机上面),基于分布式管理2

    2、SpringCloud工具集

    • 定义:用来帮助开发人员快速构建一套分布式应用 微服务工具集(服务注册,发现,负载均衡,路由组件,统一配置管理)

    3、环境搭建

    • SpringCloud+SpringBoot

    (1)版本选择

    -SpringCloud H.SR6(目前已经达到10了)
    -SpringBoot    2.2.5版本
    -JDK1.8
    -maven 3.x
    -idea:2021
    

    (2)创建SpringCloud项目父项目,管理版本

    • SpringCloud_parent 管理维护依赖

    • 选择maven,跳过骨架

    • 选择稳定版本

    • 在父项目中继承SpringBoot父项目, 指定版本为 2.2.5版本

     <!--1.在父项目中继承SpringBoot父项目-->
        <parent>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-parent</artifactId>
            <version>2.2.5.RELEASE</version>
        </parent>
    
    • 引入springcloud的版本管理

    <!--维护SpringCloud的依赖,定义springcloud使用版本号-->
        <properties>
            <java.version>1.8</java.version>
            <spring-Cloud.version>Hoxton.SR6</spring-Cloud.version>
        </properties>
    
        <!--全局管理springcloud版本,并不会引入具体依赖-->
        <dependencyManagement>
            <dependencies>
                <dependency>
                    <groupId>org.springframework.cloud</groupId>
                    <artifactId>spring-cloud-dependencies</artifactId>
                    <version>${spring-Cloud.version}</version>
                    <type>pom</type>
                    <scope>import</scope>
                </dependency>
            </dependencies>
        </dependencyManagement>-  
    
    • 注意:dependency为什么会有typepom,默认的值是什么?

    dependency中type默认为jar即引入一个特定的jar包。那么为什么还会有type为pom呢?<br />当我们需要引入很多jar包的时候会导致pom.xml过大,我们可以想到的一种解决方案是定义一个父项目,但是父项目只有一个,也有可能导致父项目的pom.xml文件过大。这个时候我们引进来一个type为pom,意味着我们可以将所有的jar包打包成一个pom,然后我们依赖了pom,即可以下载下来所有依赖的jar包

    四、服务注册中心

    1、什么服务注册中心

    所谓服务注册中心就是在整个的微服务架构中单独提出一个服务,这个服务不完成系统的任何的业务功能,仅仅用来完成对整个微服务系统的服务注册和服务发现,以及对服务健康状态的监控和管理功能。

    定义:服务注册中心就是在整个微服务中单独抽取一个服务,这个服务不完成项目中任何业务功能,只用来在微服务中记录微服务以及对整个系统微服务进行健康状态检查,以及服务元数据信息存储

    # 1.服务注册中心
    - 可以对所有的微服务的信息进行存储,如微服务的名称、IP、端口等
    
    - 可以在进行服务调用时通过服务发现查询可用的微服务列表及网络地址进行服务调用
    
    - 可以对所有的微服务进行心跳检测,如发现某实例长时间无法访问,就会从服务注册表移除该实例
    

    2、常用的服务注册中心

    常用注册中心组件:eureka(netfix),zookeeper(java),consul(Go),nacos(java阿里巴巴)

    五、开发服务注册中心eureka(易瑞卡 )server

    # 0.简介
    - https://github.com/Netflix/eureka/wiki
    - Eureka是Netflix开发的服务发现框架,本身是一个基于REST的服务。
    SpringCloud将它集成在其子项目spring-cloud-netflix中,    
    以实现SpringCloud的服务注册和发现功能。
      Eureka包含两个组件:`Eureka Server和Eureka Client。`
    

    1、

    1、创建项目并引入eureka server依赖

     <parent>
            <artifactId>SpringCloud_Parent</artifactId>
            <groupId>com.tjcu</groupId>
            <version>1.0-RELEASE</version>
        </parent>
        <modelVersion>4.0.0</modelVersion>
    
        <artifactId>eurekaServe</artifactId>
    
      
    
        <dependencies>
            <!--1、引入SpringBootWeb-->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-web</artifactId>
            </dependency>
            
            <!--2、引入 eureka server-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
            </dependency>
    
        </dependencies>
    

    2、编写配置application.properties

    #执行服务端口
    server.port=8761
    #服务注册中心名称 唯一标识
    spring.application.name=EUREKASERVER
    #指定服务中心地址
    eureka.client.service-url.defaultZone=http://localhost:8761/eureka
    

    3、开启Eureka Server,入口类加入注解

    @SpringBootApplication
    @EnableEurekaServer  //开启Eureka Server
    public class EurekaServeApplication {
        public static void main(String[] args) {
            SpringApplication.run(EurekaServeApplication.class,args);
        }
    }
    
    

    4、访问Eureka的服务注册页面

    5、注意事项

    • 在项目启动成功后默认在eureka server管理界面出现UNKNOWN 一个未知应用

    注意:在微服务架构中服务名称代表服务唯一标识,至关重要,服务名称必须唯一

    • 在eureka server启动过程中报错

    出现上述问题原因:eureka组件包含 eurekaserver 和 eurekaclient。server是一个服务注册中心,用来接受客户端的注册。client的特性会让当前启动的服务把自己作为eureka的客户端进行服务中心的注册,当项目启动时服务注册中心还没有创建好,所以找我不到服务的客户端组件就直接报错了,当启动成功服务注册中心创建好了,日后client也能进行注册,就不再报错啦!

    6、关闭Eureka自己注册自己

    #执行服务端口
    server.port=8761
    #服务注册中心名称 唯一标识
    spring.application.name=EUREKASERVER
    #指定服务中心地址
    eureka.client.service-url.defaultZone=http://localhost:8
    #不再将自己作为客户端注册,只作为服务注册中心
    eureka.client.register-with-eureka=false
    #关闭作为客户端时从eureka server 获取服务信息
    eureka.client.fetch-registry=false
    

    六、开发Eureka Client

    1.创建项目并引入eureka client依赖

        <parent>
            <artifactId>SpringCloud_Parent</artifactId>
            <groupId>com.tjcu</groupId>
            <version>1.0-RELEASE</version>
        </parent>
        <modelVersion>4.0.0</modelVersion>
    
        <artifactId>eurekaClient</artifactId>
    
       <dependencies>
           <!--引入springBoot web依赖-->
           <dependency>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-starter-web</artifactId>
           </dependency>
           <!--引入eureka client-->
           <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
           </dependency>
    
       </dependencies>
    

    2.编写配置application.properties

    #服务端口号
    server.port=8989
    #服务名称唯一标识
    spring.application.name=eurekaClient8888
    #eureka服务注册中心地址
    eureka.client.service-url.defaultZone=http://localhost:8761/eureka
    

    3.开启eureka客户端加入注解

    @SpringBootApplication
    @EnableEurekaClient
    public class EurekaClientApplication {
        public static void main(String[] args) {
            SpringApplication.run(EurekaClientApplication.class, args);
        }
    }
    

    4.启动之前的8761的服务注册中心,在启动eureka客户端服务

    5.查看eureka server的服务注册情况

    6.eureka自我保护机制

    • 服务频繁启动时 EurekaServer出现错误

    EMERGENCY! 
    EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE 
    UP WHEN THEY'RE NOT. 
    RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE
     INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
    

    • eureka自我保护机制

    - 官网地址: https://github.com/Netflix/eureka/wiki/Server-Self-Preservation-Mode
    
    
    - 默认情况下,如果Eureka Server在一定时间内(默认90秒)没有接收到某个微服务实例的心跳,
    Eureka Server将会移除该实例。但是当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,
    而微服务本身是正常运行的,此时不应该移除这个微服务,所以引入了自我保护机制。
    Eureka Server在运行期间会去统计心跳失败比例在 15 分钟之内是否低于 85%,
    如果低于 85%,Eureka Server 会将这些实例保护起来,让这些实例不会过期。
    这种设计的哲学原理就是"宁可信其有不可信其无!"。
    自我保护模式正是一种针对网络异常波动的安全保护措施,
    使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。
    
    • 在eureka server端关闭自我保护机制

    eureka.server.enable-self-preservation=false  #关闭自我保护
    eureka.server.eviction-interval-timer-in-ms=3000 #超时3s自动清除
    
    • eureka client微服务修改减短服务心跳的时间

     eureka.instance.lease-expiration-duration-in-seconds=10 #用来修改eureka server默认接受心跳的最大时间 默认是90s
    eureka.instance.lease-renewal-interval-in-seconds=5     #指定客户端多久向eureka server发送一次心跳 默认是30s
    
    • 尽管如此关闭自我保护机制还是会出现警告

    - THE SELF PRESERVATION MODE IS TURNED OFF.
        THIS MAY NOT PROTECT INSTANCE EXPIRY IN CASE OF NETWORK/OTHER PROBLEMS.
        
    - `官方并不建议在生产情况下关闭
    
    • eureka 停止更新

    官方停止更新说明
    - https://github.com/Netflix/eureka/wiki
    - 在1.x版本项目还是活跃的,但是在2.x版本中停止维护,出现问题后果自负!!!
    

    7、Eureka server集群搭建

    • 不再推荐使用eureka服务注册中心:

      1. 最新版本停止更新

    1. 每次必须通过手动代码形式开发服务注册中心

    七、Consul 服务注册中心

    1、consul 简介

    基于go语言进行开发服务注册中心 轻量级服务注册中心 google

    • consul是一个可以提供服务发现,健康检查,多数据中心,Key/Value存储等功能的分布式服务框架,用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案,使用起来也较为简单。Consul用Golang实现,因此具有天然可移植性(支持Linux、Windows和Mac OS X);安装包仅包含一个可执行文件,方便部署。

    2、安装consul及部署运行

    (1)下载consul

    (2)安装consul

    解压之后发现consul只有一个脚本文件

    (3)根据解压缩目录配置环境变量

    在path里面配置路径

    (4)查看consul环境变量是否配置成功,执行命令出现如下信息代表成功

    consul -v
    

    (5) 启动consul服务

    consul agent -dev

    (6)访问consul的web服务端口

    • dc1:datacenter1 数据中心 默认为dc1 指定数据中心启动 consul agent -dev -datacenter aa

    • service:当前consul中服务注册中注册服务列表 默认:client server同时启动自己注册一个 会出现一个consul服务

    • nodes:用来查看consul的集群节点

    3、开发consul 客户端即微服务

    (1)创建项目并引入consul客户端依赖

    <parent>
            <artifactId>SpringCloud_Parent</artifactId>
            <groupId>com.tjcu</groupId>
            <version>1.0-RELEASE</version>
        </parent>
        <modelVersion>4.0.0</modelVersion>
    
        <artifactId>consulClient</artifactId>
    
        <properties>
            <maven.compiler.source>8</maven.compiler.source>
            <maven.compiler.target>8</maven.compiler.target>
        </properties>
        <dependencies>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-web</artifactId>
            </dependency>
    
            <!--引入consul依赖-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-consul-discovery</artifactId>
            </dependency>
        </dependencies>
    
    

    (2)编写properties配置

    server.port=8889
    spring.application.name=consulClient8889
    #注册consul服务的主机
    spring.cloud.consul.host=localhost
    #注册consul服务的端口号
    spring.cloud.consul.port=8500
    #关闭consul服务的健康检查 【不推荐】
    spring.cloud.consul.discovery.register-health-check=false
    #指定注册的服务名称默认就是应用名
    spring.cloud.consul.discovery.service-name=${spring.application.name}
    

    (3)启动服务查看consul界面服务信息(没有开启健康检查的)

    (4)consul 开启健康监控检查

    默认情况consul监控健康是开启的,但是必须依赖健康监控依赖才能正确监控健康状态所以直接启动会显示错误,引入健康监控依赖之后服务正常

    • 健康检查的依赖

    <!-- 这个包是用做健康度监控的-->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    

    4、不同注册中心区别

    (1)CAP定理

    • CAP定理:CAP定理又称CAP原则,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本) 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性) 分区容忍性(P),就是高可用性,一个节点崩了,并不影响其它的节点(100个节点,挂了几个,不影响服务,越多机器越好)

    (2)Eureka特点

    • Eureka中没有使用任何的数据强一致性算法保证不同集群间的Server的数据一致,仅通过数据拷贝的方式争取注册中心数据的最终一致性,虽然放弃数据强一致性但是换来了Server的可用性,降低了注册的代价,提高了集群运行的健壮性。

    (3)Consul特点

    • 基于Raft算法,Consul提供强一致性的注册中心服务,但是由于Leader节点承担了所有的处理工作,势必加大了注册和发现的代价,降低了服务的可用性。通过Gossip协议,Consul可以很好地监控Consul集群的运行,同时可以方便通知各类事件,如Leader选择发生、Server地址变更等。

    (4)zookeeper特点

    • 基于Zab协议,Zookeeper可以用于构建具备数据强一致性的服务注册与发现中心,而与此相对地牺牲了服务的可用性和提高了注册需要的时间。

    展开全文
  • 几种常见的注册中心以及区别

    千次阅读 2022-03-06 21:55:01
    文章目录服务注册服务发现心跳机制常见的注册中心consulclientserverserver-leaderraft服务发现协议服务注册服务发现eurekaEureka ClientEureka Server自我保护机制Eureka 集群原理Eurka 保证 APEurka 工作流程...
  • Python发布微服务到注册中心Nacos

    千次阅读 2022-04-14 11:29:39
    通过一个案例,演示python发布一个http服务接口,并且注册到nacos,供其他的Java微服务调用。
  • 微服务:注册中心的作用

    千次阅读 2022-03-17 14:36:58
    1、为什么需要服务注册中心 微服务时代的服务管理 在微服务时代,我们所有的服务都被劲量拆分成最小的粒度,原先所有的服务都在混在1个server里,现在就被按照功能或者对象拆分成N个服务模块,这样做的好处是深度...
  • SpringCloud之Eureka注册中心与Robbin负载均衡

    千次阅读 多人点赞 2022-03-11 14:29:42
    学习目标 了解系统架构的演变 知道什么是SpringCloud 独立搭建Eureka注册中心 独立配置Robbin负载均衡 系统架构演变 要学微服务,我们先来看看系统架构的演变史,从而对微服务架构进行更深层次的了解。 随着互联网的...
  • 常用的注册中心

    千次阅读 2022-04-05 13:05:28
    springcloud支持的多种注册中心Eureka、Consul、Zookeeper、以及阿里巴巴推出Nacos。这些注册中心在本质上都是用来管理服务的注册和发现以及服务状态的检查的。
  • 【RPC】注册中心实现方案之ZooKeeper

    千次阅读 2022-07-07 18:05:12
    ZooKeeper 可以作为微服务架构中注册中心的选型,它最需要被关心的也是数据模型和一致性协议。数据模型关乎服务信息在 ZooKeeper 服务中的存储结构,而一致性协议是注册中心服务状态一致性的保障。首先介绍 ...
  • 讲解5种常用的注册中心,对比其流程和原理,无论是面试还是技术选型,都非常有帮助。 往期精选: 如何看待程序员35岁职业危机? 2年经验总结,告诉你如何做好项目管理 Java全套学习资料(14W字),...
  • 注册中心注册中心原理

    千次阅读 2021-02-01 14:10:09
    在微服务架构中,注册中心是最核心的基础服务之一,本文将详细介绍下注册中心的组成部分和它们之前的关系。 目录 一、注册中心原理 二、注册中心功能 三、常见的注册中心 一、注册中心原理 注册中心主要涉及...
  • Nacos注册中心

    千次阅读 2022-02-26 14:36:04
    Nacos注册中心
  • redis作为注册中心

    千次阅读 2020-06-21 10:48:38
    redis registry center下载dubbo源码修改demo运行原理 ...里面的RedisRegistry类是redis作为注册中心的核心逻辑: //获得Redis主节点名称 String masterName = url.getParameter(REDIS_MASTER_NAME_KEY);
  • 微服务之注册中心

    千次阅读 2020-12-20 14:43:45
    一、概念注册中心这一概念在面向服务设计的架构中起着举足轻重的作用,不论是在SOA架构还是微服务架构之中,注册中心的作用一句话概括就是存放和调度服务,实现服务和注册中心,服务和服务之间的相互通信。注册中心...
  • Dubbo多注册中心配置

    千次阅读 2021-09-02 17:23:48
    1、Dubbo支持的注册中心 Zookeeper(官方推荐) 优点:支持分布式.很多周边产品. 缺点:受限于Zookeeper软件的稳定性.Zookeeper专门分布式辅助软件,稳定较优 Multicast 优点:去中心化,不需要单独安装软件. 缺点:...
  • 深入理解Consul注册中心机制

    千次阅读 2022-03-14 11:52:26
    概述 Consul作为注册中心,提供服务发现、配置、健康检查、安全服务通信以及多数据中心等功能, 这些功能可以根据需要单独使用,也可以一起使用来构建完整的微服务系统。 Consul agent Consul agent是Consul的核心...
  • nacos注册中心的注册原理深度解析

    千次阅读 2021-09-09 14:50:25
    整个注册中心的注册和发现流程主要有三个方面来完成:服务的提供方(以下简称server)、服务的消费者(以下简称client)、注册中心(nacos)。首先我们来探讨server与nacos的交互过程。 server需要通过nacos官方的...
  • 微服务:注册中心ZooKeeper、Eureka、Consul 、Nacos对比

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

    万次阅读 2019-01-18 14:10:58
    单机模式Eureka注册中心搭建 引入Eureka-Server依赖 创建启动类 添加配置 高可用Eureka注册中心搭建 双节点注册中心 修改配置文件 修改hosts文件 启动测试 多节点注册中心 修改配置文件 启动测试 常见...
  • Nacos——注册中心

    万次阅读 2021-12-04 10:01:19
    Nacos 英文全称Dynamic Naming and Configuration Service,Na为naming/nameServer即注册中心,co为configuration即注册中心,service是指该注册/配置中心都是以服务为核心,是阿里巴巴的产品 相较于Eureka也是Spring...
  • Spring Cloud服务注册中心简述

    千次阅读 2021-03-16 12:55:24
    概念当一个大型系统拥有很多服务时,往往需要一个服务注册中心来管理这些服务,它可以提供如下功能:登记每个服务提供的功能检测每个服务是否可用,不可用的服务剔除服务间互相调用时,通过服务注册中心很容易找到...
  • 注册中心eureka的介绍及源码探索

    万次阅读 2022-02-19 14:46:39
    1.1. 注册中心是什么 注册中心可以说是微服务架构中的”通讯录“,它记录了服务和服务地址的映射关系。在分布式架构中,服务会注册到这里,当服务需要调用其它服务时,就到这里找到服务的地址,进行调用。 1.2. 为...
  • 服务注册中心---服务发现nacos

    万次阅读 2021-07-15 16:05:09
    英文全称Dynamic Naming and Configuration Service,Na为naming/nameServer即注册中心,co为configuration即注册中心,service是指该注册/配置中心都是以服务为核心。服务在nacos是一等公民 二、有了Eureka为啥还要...
  • 注册中心为服务平台提供了核心的服务发现功能,其健壮性对服务调用的成功率起着至关重要的作用。近年来,随着服务架构落地范围迅速扩大,注册中心性能容量支撑能力面临更高挑战。工商银行结合...
  • 基于Eureka实现服务注册中心

    千次阅读 2020-06-29 23:24:25
    微服务下为什么需要注册中心注册中心有什么用?如何搭建一个高可用的注册中心
  • Consitency Protocol是一致性协议,用来实现Nacos集群节点的数据同步,这里使用的是Raft算法(Etcd、Redis哨兵选举) Nacos Console:控制台 注册中心的原理 服务实例在启动时注册到服务注册表,并在关闭时注销 ...
  • 【中间件系列】Nacos注册中心妙用

    千次阅读 2020-06-15 12:26:34
    ​ 不知道有没有考虑过这样一个问题,为什么要注册中心呢?以及注册中心该如何的选择呢?还是默认的哪个是最新的,哪个用的人多,就选用哪个呢? ​ 服务之间的互相调用时,需要服务端开启服务,客户端进行对接。...
  • 服务注册中心原理

    千次阅读 2022-03-16 17:51:41
    服务提供者:提供服务,在启动时,根据服务发布文件中的配置的信息,向注册中心注册自身服务,并向注册中心定期发送心跳汇报存活状态。 服务消费者:调用服务,在启动时,根据服务引用文件中配置的信息,将注册中心...
  • 而RocketMQ 需要一个注册中心实现服务的发现和注册,在某些情况下,RocketMQ 的注册中心可以出现数据不一致性,但必须保证高可用,就算是返回了包含不实的信息的结果也比什么都不返回要好,如果采用zookeeper来提供...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 390,858
精华内容 156,343
关键字:

注册中心