RPC 实战与核心原理
何小锋
京东云混合云首席架构师
39637 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 29 讲
RPC 实战与核心原理
15
15
1.0x
00:00/00:00
登录|注册

08 | 服务发现:到底是要CP还是AP?

你好,我是何小锋。在上一讲中,我讲了“怎么设计一个灵活的 RPC 框架”,总结起来,就是怎么在 RPC 框架中应用插件,用插件方式构造一个基于微内核的 RPC 框架,其关键点就是“插件化”。
今天,我要和你聊聊 RPC 里面的“服务发现”在超大规模集群的场景下所面临的挑战。

为什么需要服务发现?

先举个例子,假如你要给一位以前从未合作过的同事发邮件请求帮助,但你却没有他的邮箱地址。这个时候你会怎么办呢?如果是我,我会选择去看公司的企业“通信录”。
同理,为了高可用,在生产环境中服务提供方都是以集群的方式对外提供服务,集群里面的这些 IP 随时可能变化,我们也需要用一本“通信录”及时获取到对应的服务节点,这个获取的过程我们一般叫作“服务发现”。
对于服务调用方和服务提供方来说,其契约就是接口,相当于“通信录”中的姓名,服务节点就是提供该契约的一个具体实例。服务 IP 集合作为“通信录”中的地址,从而可以通过接口获取服务 IP 的集合来完成服务的发现。这就是我要说的 RPC 框架的服务发现机制,如下图所示:
RPC服务发现原理图
服务注册:在服务提供方启动的时候,将对外暴露的接口注册到注册中心之中,注册中心将这个服务节点的 IP 和接口保存下来。
服务订阅:在服务调用方启动的时候,去注册中心查找并订阅服务提供方的 IP,然后缓存到本地,并用于后续的远程调用。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《RPC 实战与核心原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(64)

  • 最新
  • 精选
  • 冰河时代
    记得之前在京东的时候,服务挂了,在注册中心上还得要手动删除下死亡节点,如果zk的话,服务没了,就代表会话也没了,临时节点的特性,应该会被通知到呀?为什么还要手动删除呢

    作者回复: 临时节点是需要等到超时时间之后才删除的,不够实时。

    4
    17
  • 雨霖铃声声慢
    如果要能切换流量,那么要服务端配置有权重负载均衡策略,这样服务器端可以通过调整权重来安排流量

    作者回复: 很好的思路

    13
  • 🌀Pick Monster 🌀
    消息总栈类似一个队列,队列表示是递增的数字,注册中心集群的任何一个节点接收到注册请求,都会把服务提供者信息发给消息总栈,消息总栈会像队列以先进先出的原则推送消息给所有注册中心集群节点,集群节点接收到消息后会比较自己内存中的当前版本,保存版本大的,这种方式有很强的实效性,注册中心集群也可以从消息总栈拉取消息,确保数据AP,个人理解这是为了防止消息未接收到导致个别节点数据不准确,因为服务提供者可以向任意一个节点发送注册请求,从而降低了单个注册中心的压力,而注册和注册中心同步是异步的,也解决了集中注册的压力,在Zookeeper中,因为Zookeeper注册集群的强一致性,导致必须所有节点执行完一次同步,才能执行新的同步,这样导致注册处理性能降低,从而高I/O操作宕机。 以上是我的个人理解,老师给看一下是否正确。 还有一个问题:当集中注册时,消息总栈下发通知给注册中心集群节点,对于单个节点也会不停的收到更新通知,这里也存在高I/O问题,会不会有宕机?

    作者回复: 上面理解的很棒。event bus可以改造成主从模式保证高可用

    3
    11
  • 松花皮蛋me
    路由负载

    作者回复: 很棒

    10
  • 楼下小黑哥
    服务消费者都是从注册中心拉取服务提供者的地址信息,所以我们要切走某些服务提供者数据,只需要将注册中心这些实例的地址信息删除(其实下线应用实例,实际也是去删除注册中心地址信息),然后注册中心反向通知消费者,消费者受到拉取最新提供者地址信息就没有这些实例了。 老师,提问一个问题:现有开源注册中心是不是还没有消息总线这种实现方式?消息总线有没有开源实现?

    作者回复: 通过服务发现来摘除流量是最常见的手段,还可以上下线状态、权重等方式。现成的MQ也是可以充当消息总线来用

    10
  • 君言
    老师,在AP实现中“两级缓存,注册中心和消费者的内存缓存,通过异步推拉模式来确保最终一致性”能展开讲一下具体实现吗?另外请教下CP可以基于zk实现,AP在业内的实现方式有哪些呢?

    作者回复: 推主要实现callback,拉的动作在客户端,像Eurek属于AP

    7
  • 南桥畂翊
    消息总线策略是啥,老师能指点下么,怎么保证消息总线全局版本递增

    作者回复: 最简单的就用时间戳

    6
  • 小结一下 1:注册中心的核心作用? 完成服务消费者和服务调用者,两者的路径匹配 2:注册中心的核心指标? 高效、稳定、高可用,使服务消费者及时感知节点的变化 3:路径匹配需要的信息? 服务提供者IP、端口、接口、方法+服务分组别名 服务消费者IP、端口 路径匹配可以把分组别名利用上,即使提供者实例上线,不过由于设置的别名和服务消费者需要的不一致流量也不会打过去,什么时候打过去可以通过配置中心来自由的控制。分组内也是有多个服务提供者的,这里可以再利用相关的负载均衡策略来具体分发流量。

    作者回复: 准确👍

    5
  • etdick
    EURAKA就是AP模型

    作者回复: 是的

    3
  • 阿卧
    zookeeper注册中心实现原理 1. 服务平台向zookeeper创建服务目录 2. 服务提供者向zookeeper创建临时节点 3. 服务调用者订阅zookeeper,创建临时节点,拉取服务全量数据,watch服务全部节点数据 4. zookeeper节点发生变化会通知服务调用者 切掉服务流量,只需要将注册中心的配置节点下掉就好了

    作者回复: 这还是利用了服务发现

    3
收起评论
显示
设置
留言
64
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部