精华内容
下载资源
问答
  • 服务发现原理

    2021-05-05 15:29:58
    服务接口注册:在服务提供方启动时,将自己提供的服务的接口和自己的id注册到注册中心 服务接口订阅:服务调用方启动的时候,去注册中心查找和订阅服务提供方的ip,然后缓存到本地,用于后续的远程调用 ...

    服务发现原理图
    服务接口注册:在服务提供方启动时,将自己提供的服务的接口和自己的ip注册到注册中心
    服务接口订阅:服务调用方启动的时候,去注册中心查找和订阅服务提供方的ip,然后缓存到本地,用于后续的远程调用

    服务发现AP还是CP

    综合来看还是AP比较合适一点,因为rpc可以容忍刚上线的几秒钟服务感知不到,所以一般来说只要实现了最终一致性就可以了。
    基于zookeeper的服务发现,采用的是CP,在存储的节点很多,且读写很频繁的时候可能由于自身的负载能力而宕机。
    基于消息总线的服务发现,注册数据可以全量的放在每个注册中心的内存中,利用消息总线来更新数据。当有一个中心注册节点接受到服务节点注册时,会产生一个消息推给总线,再通过消息总线通知其他注册中心节点更新数据并且服务下发,从而各注册中心间达到最终一致性。
    推拉结合,以拉为准。

    展开全文
  • 简介:本文介绍 Kubernetes 集群中 DNS 服务发现原理。本文介绍 Kubernetes 集群中 DNS 服务发现原理。前提需要 拥有一个 Kubernetes 集群(可以通过 ACK 创建一个 Kubernetes 集群) 能通过 kubectl 连接 ...
    简介:本文介绍 Kubernetes 集群中 DNS 服务发现原理。

    本文介绍 Kubernetes 集群中 DNS 服务发现原理。

    前提需要

    1. 拥有一个 Kubernetes 集群(可以通过 ACK 创建一个 Kubernetes 集群
    2. 能通过 kubectl 连接 Kubernetes 集群

    集群 DNS 服务

    Kubernetes 集群中部署了一套 DNS 服务,通过 kube-dns 的服务名暴露 DNS 服务。您可执行以下命令查看 kube-dns 的服务详情。

    kubectl get svc kube-dns -n kube-system

    输出:

    NAME       TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                  AGE
    kube-dns   ClusterIP   172.24.0.10   <none>        53/UDP,53/TCP,9153/TCP   27d

    服务后端是两个名为 coredns(下文会介绍 CoreDNS 解析原理) 的 Pod。您可执行以下命令查看 coredns 的 Pod 详情。

    kubectl get deployment coredns -n kube-system

    输出:

    NAME      READY   UP-TO-DATE   AVAILABLE   AGE
    coredns   2/2     2            2           27d

    集群内域名解析原理

    Kubernetes 集群节点上 kubelet 有--cluster-dns=${dns-service-ip} 和 --cluster-domain=${default-local-domain} 两个 dns 相关参数,分别被用来设置集群DNS服务器的IP地址和主域名后缀。

    查看集群 default 命名空间下 dnsPolicy:ClusterFirst (下文会介绍 dnsPolicy)模式的 Pod 内的 DNS 域名解析配置文件 /etc/resolv.conf 内容:

    nameserver 172.24.0.10
    search default.svc.cluster.local svc.cluster.local cluster.local
    options ndots:5

    各参数描述如下:

    1. nameserver: 定义 DNS 服务器的 IP 地址。
    2. search: 设置域名的查找后缀规则,查找配置越多,说明域名解析查找匹配次数越多。集群匹配有 default.svc.cluster.local、svc.cluster.local、cluster.local 3个后缀,最多进行8次查询 (IPV4和IPV6查询各四次) 才能得到正确解析结果。
    3. option: 定义域名解析配置文件选项,支持多个KV值。例如该参数设置成ndots:5,说明如果访问的域名字符串内的点字符数量超过ndots值,则认为是完整域名,并被直接解析;如果不足ndots值,则追加search段后缀再进行查询。

    根据上述文件配置,在 Pod 内尝试解析:

    1. 同命名空间下服务,如 kubernetes:添加一次 search 域,发送kubernetes.default.svc.cluster.local. 一次 ipv4 域名解析请求到 172.24.0.10 进行解析即可。
    2. 跨命名空间下的服务,如 kube-dns.kue-system:添加两次 search 域,发送 kube-dns.kue-system.default.svc.cluster.local. 和 kube-dns.kue-system.svc.cluster.local. 两次 ipv4 域名解析请求到 172.24.0.10 才能解析出正确结果。
    3. 集群外服务,如 aliyun.com:添加三次 search 域,发送 aliyun.com.default.svc.cluster.local.、aliyun.com.svc.cluster.local.、aliyun.com.cluster.local. 和 aliyun.com 四次 ipv4 域名解析请求到 172.24.0.10 才能解析出正确结果。

    Pod dnsPolicy

    Kubernetes 集群中支持通过 dnsPolicy 字段为每个 Pod 配置不同的 DNS 策略。目前支持四种策略:

    ClusterFirst:通过集群 DNS 服务来做域名解析,Pod 内 /etc/resolv.conf 配置的 DNS 服务地址是集群 DNS 服务的 kube-dns 地址。该策略是集群工作负载的默认策略。
    None:忽略集群 DNS 策略,需要您提供 dnsConfig 字段来指定 DNS 配置信息。
    Default:Pod 直接继承集群节点的域名解析配置。即在集群直接使用节点的 /etc/resolv.conf 文件。
    ClusterFirstWithHostNetwork:强制在 hostNetWork 网络模式下使用 ClusterFirst 策略(默认使用 Default 策略)。

    CoreDNS

    CoreDNS 目前是 Kubernetes 标准的服务发现组件,dnsPolicy: ClusterFirst 模式的 Pod 会使用 CoreDNS 来解析集群内外部域名。

    在命名空间 kube-system 下,集群有一个名为 coredns 的 configmap。其 Corefile 字段的文件配置内容如下(CoreDNS 功能都是通过 Corefile 内的插件提供)。

      Corefile: |
        .:53 {
            errors
            health {
               lameduck 5s
            }
            ready
            kubernetes cluster.local in-addr.arpa ip6.arpa {
              pods insecure
              upstream
              fallthrough in-addr.arpa ip6.arpa
              ttl 30
            }
            prometheus :9153
            forward . /etc/resolv.conf
            cache 30
            loop
            reload
            loadbalance
        }

    其中,各插件说明:

    1. errors:错误信息到标准输出。
    2. health:CoreDNS自身健康状态报告,默认监听端口8080,一般用来做健康检查。您可以通过http://localhost:8080/health获取健康状态。
    3. ready:CoreDNS插件状态报告,默认监听端口8181,一般用来做可读性检查。可以通过http://localhost:8181/ready获取可读状态。当所有插件都运行后,ready状态为200。
    4. kubernetes:CoreDNS kubernetes插件,提供集群内服务解析能力。
    5. prometheus:CoreDNS自身metrics数据接口。可以通过http://localhost:9153/metrics获取prometheus格式的监控数据。
    6. forward(或proxy):将域名查询请求转到预定义的DNS服务器。默认配置中,当域名不在kubernetes域时,将请求转发到预定义的解析器(/etc/resolv.conf)中。默认使用宿主机的/etc/resolv.conf配置。
    7. cache:DNS缓存。
    8. loop:环路检测,如果检测到环路,则停止CoreDNS。
    9. reload:允许自动重新加载已更改的Corefile。编辑ConfigMap配置后,请等待两分钟以使更改生效。
    10. loadbalance:循环DNS负载均衡器,可以在答案中随机A、AAAA、MX记录的顺序。

    原文链接:https://developer.aliyun.com/article/779121?

    版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
    展开全文
  • Consul服务发现原理 使用以下案例进行Consul服务发现原理的讲解,如图所示: 1、部署集群。首先需要有一个正常的Consul集群,有Server,有Leader。这里在服务器Server1、Server2、Server3上分别部署了Consul ...

    Consul服务发现原理

    使用以下案例进行Consul服务发现原理的讲解,如图所示:

    1、部署集群。首先需要有一个正常的Consul集群,有Server,有Leader。这里在服务器Server1、Server2、Server3上分别部署了Consul Server。

    2、选举Leader节点。假设他们选举了Server2上的 Consul Server 节点为Leader。这些服务器上最好只部署Consul程序,以尽量维护Consul Server的稳定。

    3、注册服务。然后在服务器Server4和Server5上通过Consul Client分别注册Service A、B、C,这里每个Service 分别部署在了两个服务器上,这样可以避免Service的单点问题。服务注册到Consul可以通过 HTTP API(8500 端口)的方式,也可以通过 Consul 配置文件的方式。

    4、Consul client转发注册消息。Consul Client 可以认为是无状态的,它将注册信息通过RPC转发到Consul Server,服务信息保存在Server的各个节点中,并且通过Raft实现了强一致性。

    5、服务发起通信请求。最后在服务器Server6中Program D需要访问Service B,这时候Program D首先访问本机Consul Client提供的HTTP API,本机Client会将请求转发到 Consul Server。

    6、Consul Server查询到Service B当前的信息返回,最终Program D拿到了Service B的所有部署的IP和端口,然后就可以选择Service B的其中一个部署并向其发起请求了。

    展开全文
  • 服务发现原理 原理:如下图 1.1、发现原理 1.1.1、服务部署情况 注册中心:部署在上海机房,北京机房,深圳机房 服务提供者:部署在上海机房,深圳机房 消费者:部署在上海机房,北京机房 1.1.2、服务注册情况 ...

    服务发现原理

    • 原理:如下图

    1.1、发现原理

    1.1.1、服务部署情况
    • 注册中心:部署在上海机房,北京机房,深圳机房
    • 服务提供者:部署在上海机房,深圳机房
    • 消费者:部署在上海机房,北京机房
    1.1.2、服务注册情况
    • 注册中心:Server之间通过同步复制进行数据同步
    • 提供者(上海机房):注册到上海机房Server,并提供者数据同步到注册中心
    • 提供者(深圳机房):注册到深圳机房Server,并提供者数据同步到注册中心
    • 消费者(上海机房):注册到上海机房Server,并提供者数据同步到注册中心
    • 消费者(北京机房):注册到北京机房Server,并提供者数据同步到注册中心
    1.1.3、服务调用情况
    • 消费者(上海机房):优先调用上海机房提供者,当上海机房提供者下线时远程调用深圳机房提供者
    • 消费者(北京机房):北京区域没有提供者,会通过负债均衡计算调用深圳机房或上海机房服务提供者

    1.2、组建行为

    • Eureka Server:服务注册中心角度,提供服务注册和发现功能
    • Eureka Client提供者:是一个Client,扮演提供者角色,提供专业服务,向Server注册和更新自己的信息,也能从Server中获取到其他服务信息
    • Eureka Client消费者:是一个Client,扮演消费者角色,通过Server获取到其他服务信息,从而实现远程调用
    展开全文
  • Docker Kubernetes 服务发现原理详解 服务发现支持Service环境变量和DNS两种模式: 一、环境变量 (默认) 当一个Pod运行到Node,kubelet会为每个容器添加一组环境变量,Pod容器中程序就可以使用这些环境变量发现...
  • Etcd服务发现原理

    2021-03-18 17:57:02
    etcd 是基于 Go 语言实现的一个 KV 结构的存储系统,支持服务注册与发现的功能,官方将其定义为一个可信赖的分布式键值存储服务,主要用于共享配置和服务发现。 简单:安装配置简单,而且提供了 HTTP API 进行交互...
  • 高并发服务发现原理

    2021-01-05 15:05:24
    在一个超大型的系统中,有100K个Client,也就是10万个服务,这么多个服务定时向Eureka注册中心请求发现服务时,应该怎样处理? 首先,我们可以让多个Eureka相互注册构成集群,多个服务向集群内的不同Eureka定时请求...
  • Ribbon是使用拦截器来实现服务的远程调用的,源码如下: public class LoadBalancerAutoConfiguration { @LoadBalanced @Autowired(required = false) private List<RestTemplate> restTemplates = ...
  • Consul服务发现原理 使用以下案例进行Consul服务发现原理的讲解,如图所示: 1、部署集群。首先需要有一个正常的Consul集群,有Server,有Leader。这里在服务器Server1、Server2、Server3上分别部署了Consul ...
  • 在一个超大型的系统中,有100K个Client,也就是10万个服务,这么多个服务定时向Eureka注册中心请求发现服务时,应该怎样处理? 首先,我们可以让多个Eureka相互注册构成集群,多个服务向集群内的不同Eureka定时请求...
  • a. 每30s发送⼼跳检测重新进⾏租约,如果客户端不能多次更新租约,它将在... a.... 们的服务,并进⾏远程调⽤。 b. 客户端还可以缓存⼀些服务实例信息,所以即使Eureka全挂掉,客户端也是可以定位到服务地址的。 ...
  • 我的博客地址,Eureka原始... #Eureka Server会定时(间隔值是eureka.server.eviction-interval-timer-in-ms,默认60s)进行检查,如果发现实例在在一定时间 #(此值由客户端设置的eureka.instance.lease-expiration-dur

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,045
精华内容 2,418
关键字:

服务发现原理