深入浅出分布式技术原理
陈现麟
伴鱼技术中台负责人,前小米工程师
21241 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 39 讲
深入浅出分布式技术原理
15
15
1.0x
00:00/00:00
登录|注册

04|注册发现: AP 系统和 CP 系统哪个更合适?

一致性优先
ZooKeeper
etcd
最终一致性
高可用性
Eureka
服务发现
服务注册
Eureka
ZooKeeper
etcd
API 友好程度
数据容量要求低
性能要求中等
可用性要求高
REST API 或 RPC 需要知道 IP 和 Port
业务迭代周期差异
局部风险放大到全局
单一语言和生态限制
串行编译、测试和发布
不同保障级别
异构工作负载
AP 系统与 CP 系统的选择
互联网作为分布式系统的服务注册发现系统
服务注册发现的实现方式
单体服务拆分的必要性
服务注册发现的重要性
CP 系统
AP 系统
服务状态的更新与通知
适合的存储系统
选择适合的中介存储
状态更新与通知
统一的中介存储
跨服务调用问题
按资源和业务维度进行拆分
稳定性问题
研发效率问题
成本问题
思考题
总结
选择 AP 系统还是 CP 系统
实现服务注册发现
服务注册发现的关键问题
服务注册发现的业务场景
拆分单体服务的动机
单体服务的问题
分布式系统:服务注册发现

该思维导图由 AI 生成,仅供参考

你好,我是陈现麟。
在前面的“概述篇”里,我们介绍了分布式技术的来龙去脉,以及在构建一个分布式系统的时候,我们会面临的相关挑战。从这节课开始,我们将一起进入到“分布式技术篇”的学习当中。
在这个专栏里,我们会聚焦日常工作中接触最频繁的分布式在线业务技术。学完这部分内容,相信你会对分布式计算技术心中有数,同时不会迷失于实现的细节中。
当然,分布式计算是个非常大的技术体系,包括 MapReduce 之类的分布式批处理技术,Flink 之类的分布式流计算技术和 Istio 之类的分布式在线业务技术。但是万变不离其宗,我们掌握了分布式计算技术中稳定不变的知识、原理和解决问题的思路,再研究这些技术的时候也会一通百通。
如果直接讨论技术知识和原理,可能会让你觉得非常枯燥和抽象。通过具体的场景案例来讨论技术是非常好的方式,所以我给你虚构了后面这个场景。
假设你是极客时间的一个研发工程师,负责极客时间 App 的后端开发工作。目前极客时间采用的是单体架构,服务端所有的功能、模块都耦合在一个服务里。由于现在用户数据和流量都在快速增长,经常会因为一次小的发布,导致全站都不可用,所以在白天的时候,你都不敢发布服务。
等到时间一长,凌晨流量低峰时的运维慢慢变成常态,你经常收到机器 CPU、内存的报警,但是每一次都很难知道是什么业务功能导致的,只能直接升级机器配置。慢慢的,你发现工作中的问题和挑战越来越多,但是不知道怎么处理。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式系统中的服务注册发现是一个关键组件,本文从极客时间服务器采用的单体架构面临的问题出发,探讨了为什么需要服务注册发现以及服务注册发现的业务场景。文章指出,单体服务面临成本、研发效率和稳定性等问题,需要按资源和业务等维度对单体服务进行拆分。在拆分为多个服务后,如何调用其他服务的函数成为一个新的问题,需要解决服务注册发现的业务场景。通过具体的场景案例,文章生动地阐述了分布式系统中服务注册发现的重要性和应用场景,为读者提供了深入了解分布式系统技术的入口。 文章详细讨论了服务注册发现的关键问题,包括统一的中介存储和状态更新与通知。针对中介存储的选择,文章分析了常见存储系统的特点,并提出了etcd、ZooKeeper和Eureka等存储系统作为合适的选择。此外,文章还探讨了服务状态的更新与通知的解决方案,以及在AP系统和CP系统中选择适合的服务注册发现系统的原则。 总的来说,本文通过深入讨论服务注册发现的原理和实现方式,为读者提供了全面的分布式系统服务注册发现知识。文章内容丰富,涵盖了分布式系统中服务注册发现的重要性、解决方案以及选择原则,对于想要深入了解分布式系统技术的读者具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入浅出分布式技术原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • 青鸟飞鱼
    老师,redis做服务注册发现,从高可用角度来看其实挺合适的,主从架构足够存储ip、port等信息。

    作者回复: Redis 高可用是满足要求的,只不过 Redis 的高可用需要我们自己来运维,比如通过哨兵机制在检察和剔除出现故障的节点等,而 etcd、ZooKeeper 和 Eureka 它们的高可用是系统自带的,所以课程中说 Redis 高可用的运维成本高。

    2022-01-30
    3
    13
  • 努力努力再努力
    思考题: 互联网中 一个服务的调用流程 1. 客户端 访问域名 -》 DNS (获取对应的ip)-〉 局域网内部路由器 (再获取下一个局域网的ip) -》 一直到服务端 -〉 返回 当然了中间还少了 消息怎么组成 域名的解析过程 等等 但是不是重点 这个流程中 其实DNS 就属于域名-ip的注册中心 猜想: 1. DNS 域名到ip 映射修改是CP (必须成功) 2 各地DNS 自身刷新是 定时更新 (异步) 需要之后实践: 1. 一个信息在多实例上同时生效 ,要通过配置信息来实现,配置信息为什么能实现这个功能 和 区别点是什么?

    作者回复: 整体思路非常正确,有两个细节问题: 1、服务的调用流程,获得ip后,通过ip路由的过程,一般是 局域网 -> NAT -> 公网。 2、“DNS 域名到ip 映射修改是CP (必须成功)”,DNS域名到ip是AP的,C 强调的是修改多节点的数据是原子和瞬时的,和单节点的一样,一致性的讨论在后面「一致性与共识」中会讨论。

    2022-01-28
    11
  • Ricky Gu
    互联网系统通过DNS 实现服务注册和发现。所以中介存储是DNS。DNS 存在缓存,修改DNS 之后会有生效时间,所以DNS 是最终一致性而不是强一致性系统。同时DNS的可用性几乎是100%的。所以我觉得DNS是AP 系统。

    作者回复: 是的

    2022-02-11
    9
  • blentle
    老师,有个疑问.如果选择ap作为服务发现中心,网络发生分区时.读到过时的数据,如果刚好那个服务更新后因为网络分区没有来得及更新,比如广告竞价出价服务的价格变更,岂不是比cp服务发现产生更大的灾难.这时候可以容忍调用失败不会损失广告主的利益.

    作者回复: 首先,一般来说,为了平滑升级,服务发布都是滚动的,也就是说同一个服务的多个实例的发布不是一个原子和瞬间操作,所以正常情况下也会存在新老版本共存的情况。 其次,客户端是通过网络去服务注册发现中心获取服务的列表是通过网络的,可能有的客户端 A 10 ms 就获得到最新的列表了,客户端 B 由于网络丢包,经过重试 30 s 后才获得列表,这里就导致就算服务注册发现中心内部是CP的,但是从客户端获取服务列表的角度来看,依然是最终一致性的。 最后,关于你这个场景,如果需要一个信息在多实例上同时生效,比较好的方式是通过配置信息来实现,在后面的课程「配置中心」中有详细的讨论。

    2022-01-28
    2
    6
  • GAC·DU
    老师,如何优雅的摘掉一个发生故障的服务,让注册中心处理还是让上游服务调用时发现故障通报注册中心?如果这个服务有十个接口,只有其中的一个接口出了故障,能做到接口级别的隔离吗? 之前在传统的物理机部署服务时利用Etcd来做服务的注册与发现,后来所有的服务都迁移到云原生下部署利用Service来进行服务发现和负载均衡很方便,老师我这个跟进的方向正确吗? 服务注册与发现本质是实现服务的负载均衡,最终的目的还是让整个分布式系统实现高可靠,是AP系统还是CP系统,要看最终的服务用户的忍受度。比如一个量化交易系统CP应该比AP更合适。

    作者回复: 如何优雅的摘掉一个发生故障的服务,让注册中心处理还是让上游服务调用时发现故障通报注册中心? 实例在注册发现中心上的注册信息是有时效性的,如果一个服务的实例发生故障,这个实例就不会再次和注册发现中心发送心跳或者注册了,这个实例的注册信息就会因为过期而被删除了 如果这个服务有十个接口,只有其中的一个接口出了故障,能做到接口级别的隔离吗? 注册发现中心是关注实例层面的,对于接口层面不应该由注册发现来处理,不过熔断机制可以进行隔离,在后面的课程中会讨论这个问题。 云原生是大趋势,利用Service来进行服务发现和负载均衡的方向是正确的。 关于“比如一个量化交易系统CP应该比AP更合适。”的问题,在前面的问题中回复了,这里就不重复了。

    2022-01-28
    4
  • janey
    老师你好,解释贴合场景非常方便理解,感觉非常赞。业务经验不是很多,在学习本章的时候,单体服务局限在异构负载上的解释不是特别理解,希望能得到答疑:如果说服务里有模块A是IO密集型,模块B是CPU密集型,那么单体部署的时候肯定要同时兼顾IO和CPU;假设我们把这2个模块拆开了,模块A可以部署到一台IO好的机器上,模块B部署到一台CPU好的机器上;现在需要2台机器资源,并且2台机器CPU和IO资源加和不能降,从资源上看的话,收益在哪里呢?

    作者回复: 1、从稳定性角度,可以避免相互影响 2、从成本角度,比如A模块需要ssd磁盘200G,B模块只需要普通磁盘200G,如果一台机器就需要400G的ssd磁盘(当然可以一台机器挂两块盘,ssd和机械盘各200g,但是对于运维部署的成本很大)

    2022-07-23
    2
  • Pikachu
    一直有个问题想请老师帮忙解惑,使用kubernetes的部署的应用,服务间的访问可以通过k8s的service name进行访问,原理就类似于老师上面提到的,在K8s集群的DNS实现解析,并且集群还可以根据服务的可用状态进行节点加入和摘除。那么这种情况,我理解除了需要访问指定的节点情况以外,其他就已经满足服务注册和发现的机制了,是不是就不需要单独的服务发现中间件了?不知道理解的对不对

    作者回复: 是的,不需要了

    2022-03-09
    1
  • 约书亚
    个人感觉mysql和redis不适合做注册发现中心的最重要原因不是高可用,而是一致性。Eureka能满足最终一致性。mysql和redis满足不了。

    作者回复: 对于 mysql 和 redis,如果不要求高可用,是可以实现强一致性的,比如同步复制,比如主不可以切换等操作。 高可用问题和一致性问题很多时候是可以相互转换的,CAP😀

    2022-04-12
    2
  • 不吃辣👾
    老师 假如我一个底层服务部署节点万年不变,迭代周期非常长。这还适合做服务注册发现吗?是否为核心服务,是否需要平滑升级的场景才需要注册发现?注册发现与版本变更有啥区别和联系?

    作者回复: 服务发现是服务治理的一部分,是在微服务服务太多的情况下自动化运维服务的,如果从不更新,也就是运维成本低,那也不用服务发现也可以。 不过正常情况来说,服务发现就是非常方便集成的,集成一个 SDK就行,服务网格则更简单,新的服务应该使用。 版本变更的时候,可以通过注册发现发现新版本的服务。

    2022-03-31
  • 不吃辣👾
    老师你怎么知道eureka zookeeper etcd redis的高可用存在的问题,哪里可以学习这部分知识?

    作者回复: 后面的课程,“复制”和“一致性与共识”序列有详细介绍

    2022-03-31
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部