精华内容
下载资源
问答
  • 2018-07-08 10:37:19

    SpringCloud和Dubbo都是当下流行的RPC框架,各自都集成了服务发现和治理组件。SpringCloud用Eureka,Dubbo用Zookeeper,这篇博客就将将这两个组件在各自系统中的作用机制的区别。

    1.注册的服务的区别

    Dubbo是基于java接口及Hession2序列化的来实现传输的,Provider对外暴露接口,Consumer根据接口的规则调用。也就是Provider向Zookeeper注册的是接口信息,Consumer从Zookeeper发现的是接口的信息,通过接口的name,group,version来匹配调用。Consumer只关注接口是否匹配,而对此接口属于什么应用不关心。当然接口的注册信息里会包含应用的ip,hostname等。

    SpringCloud的服务发现是基于Http协议来实现的,Provider对外暴露的是应用信息,比如应用名称,ip地址等等,Consumer发现的是应用的信息,当调用的时候随机选择一个Provider的IP地址,应用名称,然后依据Http协议发送请求。Consumer关注的是应用名称,根据应用名称来决定调用的是哪个服务集群,然后对此名称对应的服务集群做负载均衡。Provider接受到请求后,根据内置的SpringMVC来匹配路由处理请求。

    2 . Server集群服务信息同步的区别

    Dubbo使用Zookeeper做服务发现和治理,Zookeeper是一个分布式协调框架,其有很多很实用的功能,服务发现仅仅是其中的一个。Zookeeper基于著名的CAP理论中的C(一致性),P(分区可用性)实现,它的ZAB(zookeeper atomic broadcast protocol)协议,保证了集群里状态的一致性。Client的每一个事务操作都由Leader广播给所有Follower,当超过半数的Follower都返回执行成功后,才执行事务的ack。对于因网络崩溃或者宕机等问题而执行失败的zookeeper节点,zookeeper会基于zab的崩溃恢复机制来处理,这里不再讲述。每一个操作都需要过半数的zookeeper节点执行成功才确认成功,那么当zookeeper集群过半数节点出现问题时,服务发现功能就不可用。

    SpringCloud使用Eureka做服务发现和治理,它是一个专门用于服务发现和治理的框架,其基于CAP理论中的A(可用性),P(分区可用性)实现。EurekaServer节点间的服务信息同步是基于异步Http实现的。每隔Server节点在接收Client的服务请求时,立即处理请求,然后将此次请求的信息拷贝,封装成一个Task,存入Queue中。Server初始化时会启动一个线程定期的从TaskQueue中批量提取Task,然后执行。服务同步不保证一定成功,虽然有失败重试,但超过一定时限后就放弃同步。当然其有一个特性,当服务丢失后,同步的操作返回400,404后会立即将最新的服务信息同步过去,因此即使中途同步失败,不会对后续的同步有影响。

    3 . 服务更新机制的区别

    Dubbo使用Zookeeper做服务发现和治理,订阅Zookeeper下相应的znode。当节点发生变化,比如有新的元素增加,或者旧的元素移除,Zookeeper会通知所有订阅此节点的Client,将当前的全量数据同步给各Client,Dubbo里根据最新的数据来做相应处理,移除下线的,初始化新增的。每次更新都同步全量数据

    Eureka在启动时向Server进行一次全量拉取,获取所有的可用服务信息,之后默认情况下都是进行增量拉取。Server会将有变化的服务信息放在一个Queue里,Client每次同步时仅获取增量信息,根据信息里的操作类型,服务信息来对当前持有的服务做相应的处理,移除下线的,初始化新增的等。每次更新仅同步增量数据,也就是更新的数据

    4 . 服务更新反馈机制的区别

    Dubbo订阅Zookeeper下相应的节点,当节点的状态发生改变时,Zookeeper会立即反馈订阅的Client,实时性很高。

    Eureka Server在接收到Client的更新操作,或者移除服务信息时,仅仅会将更新消息存放入recentlyChangedQueue中,不会主动的反馈其他Client。其他Client只有在拉取服务增量信息时才会感知到某个服务的更新,延时最大为30S,也就是拉取周期。

    5 . 服务信息回收机制的区别

    Dubbo Provider初始化时会创建一个Zookeeper Client,专门用于与Zookeeper集群交互。维持与集群间的长连接,定时发送心跳,维护Zookeeper上自身节点的存在。节点类型是临时节点,也就是当心跳超时或者长连接断开时,会立即移除Provider对应的节点。
    Dubbo Consumer初始化时也会创建一个Zookeeper Client,专门用于与Zookeeper集群交互。维持长连接,创建EvenetListener,监听Provider节点的变动情况。当Provider节点新增或者移除时,Zookeeper会广播这个事件,然后将此节点的当前值(剩下的所有接口信息)发送给那些注册了此节点监听器的Client。Consumer获取到对应Provider节点下的所有接口信息后,移除已下线的,创建新增的。
    Zookeeper对服务信息的维护实时性和一致性比较高,但也可能因为网络问题或者集群问题导致服务不可用。

    SpringCloud的服务信息回收仅基于心跳超时,与长连接无关。当心跳超时后,EurekaServer回收服务信息,然后将此动作同步给其他Server节点。当然可能一个服务信息会存在多个Server上,多次回收操作的同步具备幂等性。也就是说服务回收只需要通知一个Server节点就可以了,回收动作会通过Server节点传播开来。EurekaServer能够回收服务信息由个重要前提:上一分钟内正常发送心跳的服务的比列超过总数的85%,如果因为网络波动等原因造成大量服务的心跳超时,那么EurekaServer会触发自我保护机制,放弃回收那些心跳超时的服务信息。服务发现组件应该优先保证可用性,Consumer能够发现Provider,即使发现的是非可用的Provider,但因为Conusmer一般具备容错机制,不会对服务的正常调用有太多影响。从这点上看Eureka的服务发现机制要比Zookeeper稍微合理一点的。

    6 . 节点性质的区别

    Dubbo只有Consumer订阅Provider节点,也就是Consumer发现Provider节点信息

    Eureka不区分Consumer或者Provider,两者都统称为Client,一个Client内可能同时含有Provider,Consumer,通过服务发现组件获取的是其他所有的Client节点信息,在调用时根据应用名称来筛选节点

    7 . 使用方式的区别

    Dubbo使用Zookeeper作为服务发现和治理的组件,所以需要搭建Zookeeper集群作为依赖。

    SpringCloud使用Eureka作为服务发现和治理组件,在Spring应用中整合Eureka还是很简单的,引入依赖,加个注解,指定集群Server的serviceUrl,其他的都可以使用默认配置即可,启动应用,Eureka集群就搭建好了。同时配合SpringCloudConfg,能够统一管理Eureka的集群配置信息,可以动态的增加或减少EurekaServer的集群节点。Eurerka会每隔15分钟根据配置上的集群信息重新生成集群节点,覆盖之前的。这种机制比Zookeeper要更优秀一些,毕竟Eureka算是Spring生态里的一环,已经被整合的非常好了,能够以很多匪夷所思的方式来使用。

    更多相关内容
  • Prometheus 服务发现机制

    千次阅读 2020-08-08 13:35:07
    目录Prometheus 服务发现机制概述static_configs: 静态服务发现file_sd_configs: 文件服务发现dns_sd_configs: DNS 服务发现kubernetes_sd_configs: Kubernetes 服务发现Prometheus 的relabel_configs配置详解:...

    Prometheus 服务发现机制概述

    Prometheus数据源的配置主要分为静态配置和动态发现, 常用的为以下几类:

    1. static_configs: #静态服务发现
    2. file_sd_configs: #文件服务发现
    3. dns_sd_configs: #DNS 服务发现
    4. kubernetes_sd_configs: #Kubernetes 服务发现
    5. consul_sd_configs: #Consul 服务发现(推荐使用)

    static_configs: 静态服务发现

    Prometheus.yaml配置文件:

    scrape_configs:
          - job_name: 'prometheus'
            static_configs:
              - targets: ['localhost:9090']
          - job_name: 'grafana'
            static_configs:
              - targets:
                  - 'grafana-service.ns-monitor:3000'
          - job_name: 'kubernetes-apiservers'
    
    

    file_sd_configs: 文件服务发现

    基于文件的服务发现方式不需要依赖其他平台与第三方服务,用户只需将要新的target信息以yaml或json文件格式添加到target文件中 ,prometheus会定期从指定文件中读取target信息并更新。

    target文件:

    vim targets.json
    [
      {
        "targets": [ "192.168.20.136:9100"],
        "labels": {
          "instance": "nodeone",
          "job": "expor_test1"
        }
      },
      {
        "targets": [ "192.168.20.137:9100"],
        "labels": {
          "instance": "nodetwo",
          "job": "expor_test2"
        }
      }
    ]
    

    Prometheus.yaml配置文件:

    scrape_configs:
    - job_name: 'file_sd'   #此处定义了自动发现的采集任务
      file_sd_configs:
        - files:
          - targets.json         #采集文件名
    

    查看web界面targets 出现targets.json 所定义的2个job。

    dns_sd_configs: DNS 服务发现

    忽略

    kubernetes_sd_configs: Kubernetes 服务发现

    对于kubernetes而言,Promethues通过与Kubernetes API交互,然后轮询资源端点。目前主要支持5种服务发现模式,分别是:
    1: Node、
    2 :Service、
    3 :Pod、
    4 :Endpoints、
    5 :Ingress
    对应配置文件中的role: node / role:service

    动态获取所有节点node的信息,可以添加如下配置:

    • role: node
    kubernetes_sd_configs:
            - role: node
            relabel_configs:
            - action: labelmap
              regex: __meta_kubernetes_node_label_(.+)
            - target_label: __address__
              replacement: kubernetes.default.svc:443
            - source_labels: [__meta_kubernetes_node_name]
              regex: (.+)
              target_label: __metrics_path__
              replacement: /api/v1/nodes/${1}/proxy/metrics
    
    
    • role: endpoints
          - job_name: 'kubernetes-service-endpoints'
    
            kubernetes_sd_configs:
            - role: endpoints
            relabel_configs:
            - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
              action: keep
              regex: true
            - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
              action: replace
              target_label: __scheme__
              regex: (https?)
            - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
              action: replace
              target_label: __metrics_path__
              regex: (.+)
            - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
              action: replace
              target_label: __address__
              regex: ([^:]+)(?::\d+)?;(\d+)
              replacement: $1:$2
            - action: labelmap
              regex: __meta_kubernetes_service_label_(.+)
            - source_labels: [__meta_kubernetes_namespace]
              action: replace
              target_label: kubernetes_namespace
            - source_labels: [__meta_kubernetes_service_name]
              action: replace
              target_label: kubernetes_name
    

    对应的service、pod也是同样的方式。
    需要注意的是,为了能够让Prometheus能够访问收到Kubernetes API,我们要对Prometheus进行访问授权,即serviceaccount。否则就算配置了,也没有权限获取。

    Prometheus 的relabel_configs配置详解:

    1. source_labels:源标签,没有经过relabel处理之前的标签名字

    2. target_label:通过action处理之后的新的标签名字

    3. regex:正则表达式,匹配源标签

    4. replacement:replacement指定的替换后的标签(target_label)对应的数值

    5. action:action定义了relabel的动作,action支持多种,如下:

      • replace: 替换标签值,根据regex正则匹配到源标签的值,并把匹配的值写入到目的标签中
      • keep: 满足regex正则条件的实例进行采集,把source_labels中没有匹配到regex正则内容的Target实例丢掉
      • drop: 满足regex正则条件的实例不采集,把source_labels中匹配到regex正则内容的Target实例丢掉
      • labeldrop: 对抓取到的符合过滤规则的target标签进行删除
      • labelkeep: 对抓取到的符合过滤规则的target标签进行保留
      • labelmap会根据regex的定义去匹配Target实例所有标签的名称,并且以匹配到的内容为新的标签名称,其值作为新标签的值
      • hashmod 设置target_label为modulus连接的哈希值source_labels

    consul_sd_configs: Consul 服务发现

    consul介绍

    Consul 是基于 GO 语言开发的开源工具,主要面向分布式,服务化的系统提供服务注册、服务发现和配置管理的功能。
    Consul 提供服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等功能。
    之前我们通过 Prometheus 实现监控,当新增一个 Target 时,需要变更服务器上的配置文件,即使使用 file_sd_configs 配置,也需要登录服务器修改对应 Json 文件,会非常麻烦。

    Consul 安装配置

    prometheus.yml 配置:

    - job_name: 'consul-prometheus'
      consul_sd_configs:
      - server: '172.30.12.167:8500'
        services: []  
    

    说明一下:这里需要使用 consul_sd_configs 来配置使用 Consul 服务发现类型,server 为 Consul 的服务地址。 配置完毕后,重启 Prometheus 服务。

    展开全文
  • Istio:服务发现和Pilot的架构机制

    千次阅读 2020-01-11 23:03:09
    Istio服务发现 Istio服务配置 stio服务发现&规则管理与Kubernetes结合 ShowCase Istio架构&Pilot介绍 Istio架构 Pilot功能 服务发现 服务配置 Istio服务发现 服务发现基本原理 a.app 88.88....

    大纲

    Istio架构&Pilot介绍
    Istio服务发现
    Istio服务配置
    stio服务发现&规则管理与Kubernetes结合
    ShowCase

    Istio架构&Pilot介绍

    Istio架构

    Pilot功能

    • 服务发现
    • 服务配置

    Istio服务发现

    服务发现基本原理
     

    a.app 88.88.88.66
    a.app 88.88.88.77
    a.app 88.88.88.88


    b.app 88.88.88.99
    b.app 88.88.88.55

    SpringCloud的服务(注册与)发现流程

    • 服务注册表:如Springcloud中一般Eureka服务;
    • 服务注册:服务配置文件中配置服务名和本实例地址,实例启动时自动注册到服务注册表;
    • 服务发现:访问目标服务时连服务注册表,获取服务实例列表。根据LB根据策略选择一个服务实例,建立连接去访问。

    Istio服务发现流程

    Istio服务发现流程
    • 服务注册表: Pilot 从平台获取服务发现数据, 并提供统一的服务发现接口。
    • 服务注册:
    • 服务发现: Envoy 实现服务发现,动态更新负载均衡池。在服务请求时使用对应的负载均衡策略将请求路由到对应的后端。

    Pilot服务发现机制的Adapter机制

    Istio服务发现实现:基于 Eureka

    1. Pilot 实现若干服务发现的接口定义
    2. Controller使用EurekaClient来获取服务列表, 提供转换后的标准的服务发现接口和数据结构;
    3. Discoveryserver基于Controller上维护的服务发现数据, 发布成gRPC协议的服务供Envoy使用。
    4. 当 有 服 务 访 问 时 , Envoy 在 处 理Outbound请求时, 根据配置的LB策略,选择一个服务实例发起访问

    Istio 服务发现实现:基于Kubernetes

    1. Pilot 实现若干服务发现的接口定义
    2. Pilot 的Controller List/WatchKubeAPIserver上service、endpoint等资源对象并转换成标准格式。
    3. Envoy从Pilot获取xDS,动态更新
    4. 当有服务访问时, Envoy在处理Outbound请求时,根据配置的LB策略,选择一个服务实例发起访问。

    Kubernetes & Istio 服务模型

    Kuberntes的服务发现

    Istio Upon Kubernetes场景

    Istio Upon Kubernetes场景

    Istio ( upon Kubernetes)服务发现和配置

    Istio ( upon Kubernetes)服务发现和配置

    Istio服务配置管理

    Istio 服务访问规则维护和工作机制

    Istio 服务访问规则维护和工作机制
    • 1. 配置:管理员通过Pilot配置治理规则
    • 2. 下发: Envoy从Pilot获取治理规则
    • 3. 执行:在流量访问的时候执行治理规则

    Istio治理规则

    • VirtualService
    •  DestinationRule
    • Gateway
    •  ServiceEntry
    •  …

    https://istio.io/docs/reference/config/istio.networking.v1alpha3/

    Istio流量规则: VirtualService

    Istio流量规则: VirtualService

    Istio流量规则: DestinationRule

    Istio流量规则: DestinationRule

    Istio流量规则: ServiceEntry & Gateway

    ServiceEntry:

    • 功能: Mesh外的服务加入到服务发现中,向Mesh里面的服务一样的被治理
    • 机制: 将ServiceEntry描述的服务加入到服务发现中;对这些服务的outbound流量进行拦截,进而进行治理

    Gateway:

    • 功能:将mesh内的一个服务发布成可供外部访问。
    • 机制:在入口处部署一个ingress的Envoy,在其上执行服务治理。

    Istio配置规则维护和下发流程

    治理规则定义 Istio VS Envoy
     

    Istio 规则
    Envoy规则

    Istio治理能力执行位置

    Istio服务发现&规则管理与Kubernetes结合

    Kubernetes & Istio 结合

    服务发现和配置管理: Istio+K8S

    服务发现和配置管理: Spring Cloud+K8S

     

    展开全文
  • 第四篇:服务发现机制

    万次阅读 2017-07-15 13:58:45
    本文出自Service Discovery in a Microservices Architecture,作者 Chris Richardson, 写于2015年5月19日这是本系列文章的第四篇。 第一篇文章:介绍微服务架构并...本文我们继续探索与服务发现紧密联系的有关问题。

    本文出自Service Discovery in a Microservices Architecture,作者 Chris Richardson, 写于2015年5月19日

    这是本系列文章的第四篇。

    本文我们继续探索与服务发现紧密联系的有关问题。

    一、为什么使用服务发现?

    想象一下编写代码调用REST或者Thrift API的服务,为了实现这个调用,你的代码需要知道服务实例的网络位置(IP 地址和端口)。在运行在物理硬件的传统应用中,服务实例的网络位置是相对静止的。例如,代码可以从配置文件中读取网络位置,这个配置文件偶尔会更新。

    但是,在现代基于云的微服务应用中,这是非常难以解决的问题,正如图4-1显示的一样:

    服务实例被动态地赋予网路位置。另外,由于自动伸缩、故障和升级,服务实例集合经常会动态改变。所以客户端代码需要使用详细设计的服务发现机制。

    这里写图片描述

    图4-1 客户端或者API网关需要帮助发现服务

    有两种主要的服务发现机制:客户端发现机制服务端发现机制。首先来看一下客户端发现机制。

    二、客户端发现模式

    当使用客户端发现模式时,客户端负责确定可用服务实例的网络位置并且对通过它们的请求进行负载均衡客户端查询服务注册中心,服务注册中心是一个可用服务实例的数据库。客户端接着使用负载均衡算法选择可用的服务实例中的一个并把这个请求路由到该实例

    图4-2显示这个模式的结构:

    这里写图片描述

    图4-2 客户端执行服务发现的任务

    当服务实例启动的时候,它的网络地址被注册到服务注册中心。当该实例终止的时候,该地址从服务注册中心移除服务实例的注册通常使用心跳机制定期刷新

    Netflix OSS 为客户端发现模式提供了很好的例证。Netflix Eureka 是一个服务注册中心,它提供了REST API来管理服务实例的注册和可用实例的查询。Netflix Ribbon是一个和Eureka共同工作的IPC客户端,它负责将请求负载均衡到可用的服务实例上。后面我们会深入讨论Eureka。

    客户端发现模式有很多的缺点和优点。

    优点:

    • 这个模式相对更直接一点,除了服务注册中心,没有要改变的地方;
    • 并且,因为客户端了解可用的服务实例,它能做出智能、针对特定应用的负载均衡决策,比如使用一致性哈希。

    缺点:

    • 这种模式的一个重要的缺陷是它将客户端与服务注册中心耦合在一起。你必须为服务客户端使用的每种编程语言和框架都实现服务发现逻辑;

    了解了客户端发现机制,让我们继续探索一下服务端发现模式。

    三、服务端发现模式

    另外一种到服务注册中心的途径是服务端发现模式 。图4-3 显示了这种模式的结构。

    这里写图片描述

    图4-3 服务注册中心也可以由服务器处理

    客户端通过负载均衡器向服务发送请求负载均衡器查询服务注册中心并路由每个请求到可用的服务实例。与客户端发现机制一样,服务实例也需要向服务注册中心注册和注销

    AWS Elastic Load Balancer (ELB) 是服务端发现路由器的一个例证。ELB通常用来对外部的因特网流量进行负载均衡。但是,你也可以在内部使用ELB进行到虚拟私有云(virtual private cloud ,VPC)的负载均衡。

    客户端使用ELB的域名来发送HTTP或者TCP请求。ELB将流量负载均衡地路由到一系列注册的Elastic Compute Cloud (EC2)实例,或者EC2 Container Service (ECS) 容器。不存在独立可见的服务注册中心。EC2实例和ECS容器直接注册到ELB本身。

    HTTP服务器和负载均衡器,比如NGINX Plus和NGINX,也可以用作服务端发现机制中的负载均衡器。例如,这篇文章描述了使用Consul Template动态地更新NGINX反向代理服务器的配置。Consul Template是一个可以根据存储在Consul service registry的数据定期重新生成任意配置文件的工具。无论什么时候文件改变,它都会运行任意的shell命令。在上面的文章中描述的例子中,Consul Template生成了一个nginx.conf的配置文件,用于配置反向代理,接着运行命令告诉NGINX重新加载该配置文件。一个更加复杂的实现,比如使用NGINX的HTTP API或者DNS也能动态地更新NGINX Plus的配置 。

    一些部署环境,比如KubernetesMarathon在集群的每个主机上都会运行代理。代理扮演服务端发现机制中的负载均衡器的角色。为了给服务发请求,客户端通过代理使用主机IP和服务的端口号路由请求。代理接着转发该请求到运行在集群上的可用服务实例。

    服务端发现模式有几个优点和缺点。

    优点:

    • 服务发现的细节从客户端抽象出来,客户端只需要给负载均衡器发请求即可。这种方式避免为服务客户端使用的每种编程语言和框架都实现服务发现逻辑;
    • 正如上文所说,一些部署环境免费提供了这种功能

    缺点:

    • 除非部署环境提供负载均衡器,否则它又是另一个需要设置和管理的高度可用的系统组件

    四、服务注册中心

    服务注册中心是服务发现机制中的核心部分。它是一个包含服务实例网络位置的数据库。服务注册中心需要高度可用并实时更新。客户端可以缓存从服务注册中心获取的网络位置。但是,信息最终会过期,导致客户端不能发现服务实例。于是,服务注册中心可以使用复制协议来维护一致性的服务器集群。

    上文提到,Netflix Eureka是服务注册中心的很好的例证。它提供REST API来注册和查询服务实例。服务实例通过POST请求来注册它的网络地址,每隔30s,它都要通过PUT请求来刷新它的注册信息。当服务实例发送HTTP 的DELETE请求,或者注册(包括刷新)超时的时候,该注册信息都会从服务注册中心移除。如你所想,客户端可以通过使用HTTPGET请求来获取已经注册的服务实例。

    Netflix通过在每个Amazon EC2可用区域运行一个或者多个Eureka服务器来实现高可用性。每个Eureka服务器运行在有弹性IP地址的EC2实例上。使用DNSTEXT记录来存储Eureka集群的配置,这个配置是从可用区域到Eureka服务器的网络地址的列表的映射表,当Eureka服务器启动的时候,它查询DNS来获取Eureka集群配置,定位它的伙伴,分配给自己一个没有使用的弹性IP地址

    Eureka客户端、服务和服务客户端通过查询DNS来发现Eureka服务器的网络地址。客户端更希望使用在相同可用区域里的Eureka服务器。但是,如果没有可用的,就需要使用别的可用区域的里的Eureka服务器。

    服务注册中心的其他例子:

    • etcd:高度可用,分布式,一致性的键值存储,用来共享配置或作为服务注册中心。Kubernetes和Cloud Foundry 这两个著名的项目使用了它;
    • Consul:一个发现和配置服务的工具,提供了API允许客户端注册并发现服务,也能通过健康检查来确定服务的可用性;
    • Apache ZooKeeper:用于分布式应用的广泛使用的、高性能的协调服务。开始作为Hadoop的子项目,但是现在是一个独立的顶级项目;

    正如前面提到的,一些系统,比如Kubernetes,Marathon和AWS不需要显式的服务注册中心,而是作为基础设施的内置的一部分。

    我们已经了解了服务注册中心的概念,继续看看服务实例是如何注册到服务注册中心的。

    五、服务注册选项

    如上所述,服务实例必须从服务注册中心注册和注销。有很多种方式可以处理注册和注销操作:

    首先看一下自我注册模式。

    5.1自我注册模式

    当使用自我注册模式时,服务实例自己负责从服务注册中心注册和注销。并且如果必要的话,服务实例要发送心跳请求来防止注册过期。图4-4显示了这种模式的结构:

    这里写图片描述

    图4-4 服务可以自己完成注册

    这种方法的一个例证是Netflix OSS Eureka client 。Eureka client可以处理服务实例注册和注销的所有方面的事情。Spring Cloud project 实现了多种模式,包括服务注册中心,使得自动注册服务实例到Eureka很容易。你只要在Java配置类中添加@EnableEurekaClient注解即可。

    自我注册模式也有很多优点和缺点。

    优点:

    • 相对简单,并且不要求额外的系统组件;

    缺点:

    • 将服务实例和服务注册中心耦合,导致为服务使用的每种编程语言和框架都实现服务注册逻辑;

    可以替代的方法是第三方注册模式,它将服务和服务注册中心解耦,

    5.2第三方注册模式

    当使用第三方注册模式时,服务实例不负责注册自己到服务注册中心。 而是通过其他称为服务注册组件的系统组件来处理服务注册。服务注册组件通过轮询部署环境或者订阅事件来追踪运行实例的集合的变化。当它注意到有新的可用的服务实例时,就会将该实例注册到服务注册中心。服务注册组件也可以注销终止的服务实例。

    图4-5 显示了这种模式的结构:

    这里写图片描述

    图4-5 独立的注册组件服务负责注册其他的服务

    服务注册组件的一个例证是开源的Registrator工程。它会自动的注册和注销部署为Docker容器的服务实例。注册组件支持多种服务注册中心,比如etcd和Consul。

    另外一个服务注册中心的例证是NetflixOSS Prana 。主要用于非JVM语言编写的服务,它是一个和服务实例并行运行的sidecar应用。Prana使用Netflix Eureka来注册和注销服务实例。

    服务注册组件在一些部署环境中是内建的组件。由Autoscaling Group 创建的EC2实例可以自动的注册到ELB。Kubernetes 服务会自动注册并被发现可用。

    第三方注册模式也有很多的缺点和优点。

    优点:

    • 一个主要的优点是服务与服务注册中心解耦,不需要为服务使用的每种编程语言和框架都实现服务注册逻辑。服务注册逻辑通过一个专门的服务以集中的方式处理;

    缺点:

    • 除非该注册组件在部署环境中内建,需要设置和管理一个高可用的系统组件

    六、总结

    在微服务架构中,运行的服务实例集合是动态变化的。实例也被动态的赋予网络地址。于是为了客户端能够给服务发送请求,就必须使用服务发现机制。

    服务发现机制中的核心部分是服务注册中心。服务注册中心是可用服务实例的数据库。服务注册中心提供管理API和查询API。服务实例使用管理API从服务注册中心注册和注销。系统组件使用查询API来发现可用的服务实例。

    服务从服务注册中心注册和注销有两种方式:

    在一些部署环境中,需要使用比如Netflix Eureka, etcd, 或者Apache ZooKeeper等设置自己的服务发现基础设施。在一些其他的部署环境中,服务发现机制是内建的。例如,KubernetesMarathon自己处理服务的注册和注销。它们也在每个集群主机上运行一个代理,这个集群主机扮演了服务端发现机制中的路由器的角色。

    HTTP 反向代理和负载均衡器比如NGINX也能用作服务端发现种的负载均衡器。服务注册中心可以给NGINX推送路由信息并且优雅的完成配置更新。例如可以使用Consul Template。NGINX Plus 支持更多的配置动态更新机制– 它可以使用DNS从服务注册中心拉取有关服务实例的信息,它也提供了API来远程完成配置重构。

    展开全文
  • 在之前是静态配置ip,需要修改配置文件,不灵活,可使用服务发现机制。 # Windows 监控 - job_name: 'wins' static_configs: - targets: ['localhost:9182'] 配置: # consul服务发现配置的列表。 consul_sd_...
  • Consul服务注册与服务发现机制

    千次阅读 多人点赞 2019-06-25 15:43:02
    1、什么是服务注册中心? 顾名思义,假设你有一个分布式系统,里面包含了多个服务,部署在不同的机器上,然后这些不同机器上的服务之间要互相调用。...现在订单服务是想要调用库存服务,但是他并不知道库存服务在...
  • 微服务系统中的服务发现机制

    万次阅读 2016-07-13 00:05:31
    为什么要使用服务发现? 我们可以想象一下,当我们需要远程的访问REST API或者Thrift API时,我们必须得知道服务的网络地址(IP Address和port)。传统的应用程序都是运行在固定的物理机器上,IP Address和端口号...
  • {{range service "nginx"}} //这里的“Nginx”是基于docker镜像进行搜索的,不是容器名称 server {{ .Address }}:{{ .Port }}; {{ end }} } server { listen 8000; //监听端口任意指定,...
  • 服务发现机制Kubernetes提供了两种发现Service的方法:1.环境变量当Pod运行的时候,Kubernetes会将之前存在的Service的信息通过环境变量写到Pod中。这种方法要求Pod必须要在Service之后启动。在Service之前启动的Pod...
  • 2、headless(去中心化) 图释: 我们在部署整个架构的时候,是不是经常会遇到一些去中心化的服务,比如zookeeper服务,本意是为了保证高可用的,但是这样子就面临一个问题,我们应该访问谁呢?这时候k8s就提出了一...
  • 在微服务架构或分布式环境下,服务注册与发现技术不可或缺​,这也是程序员进阶之路必须要掌握的核心技术之一,本文通过图解的方式带领大家轻轻松松掌握。 一、引入服务注册与发现组件的原因 先来看一个问题,...
  • 如果负载均衡器挂了,所有服务都不能被访问。就算负载均衡器是高可用的,它也会成为整个应用的瓶颈。 限制了水平扩展。单节点的负载均衡器能力是有限的。负载均衡器有两点制约: 冗余模型和许可证费用。大部分的...
  • RegistryDirectory,基于注册中心的服务发现,本文将重点探讨Dubbo是如何实现服务的自动注册与发现。从上篇文章,得知在消息消费者在创建服务调用器(Invoker)【消费者在初始时】时需要根据不同的协议,例如dubbo、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 638,660
精华内容 255,464
关键字:

服务发现机制

友情链接: wanggehua.zip