04｜注册发现： AP 系统和 CP 系统哪个更合适？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
分布式系统中的服务注册发现是一个关键组件，本文从极客时间服务器采用的单体架构面临的问题出发，探讨了为什么需要服务注册发现以及服务注册发现的业务场景。文章指出，单体服务面临成本、研发效率和稳定性等问题，需要按资源和业务等维度对单体服务进行拆分。在拆分为多个服务后，如何调用其他服务的函数成为一个新的问题，需要解决服务注册发现的业务场景。通过具体的场景案例，文章生动地阐述了分布式系统中服务注册发现的重要性和应用场景，为读者提供了深入了解分布式系统技术的入口。 文章详细讨论了服务注册发现的关键问题，包括统一的中介存储和状态更新与通知。针对中介存储的选择，文章分析了常见存储系统的特点，并提出了etcd、ZooKeeper和Eureka等存储系统作为合适的选择。此外，文章还探讨了服务状态的更新与通知的解决方案，以及在AP系统和CP系统中选择适合的服务注册发现系统的原则。 总的来说，本文通过深入讨论服务注册发现的原理和实现方式，为读者提供了全面的分布式系统服务注册发现知识。文章内容丰富，涵盖了分布式系统中服务注册发现的重要性、解决方案以及选择原则，对于想要深入了解分布式系统技术的读者具有很高的参考价值。
《深入浅出分布式技术原理》，新⼈⾸单¥59
全部留言(12)
- 最新
- 精选
青鸟飞鱼老师，redis做服务注册发现，从高可用角度来看其实挺合适的，主从架构足够存储ip、port等信息。作者回复: Redis 高可用是满足要求的，只不过 Redis 的高可用需要我们自己来运维，比如通过哨兵机制在检察和剔除出现故障的节点等，而 etcd、ZooKeeper 和 Eureka 它们的高可用是系统自带的，所以课程中说 Redis 高可用的运维成本高。
2022-01-30313
努力努力再努力思考题： 互联网中 一个服务的调用流程 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-2811- Ricky Gu互联网系统通过DNS 实现服务注册和发现。所以中介存储是DNS。DNS 存在缓存，修改DNS 之后会有生效时间，所以DNS 是最终一致性而不是强一致性系统。同时DNS的可用性几乎是100%的。所以我觉得DNS是AP 系统。
作者回复: 是的
2022-02-119 
blentle老师，有个疑问.如果选择ap作为服务发现中心，网络发生分区时.读到过时的数据，如果刚好那个服务更新后因为网络分区没有来得及更新，比如广告竞价出价服务的价格变更，岂不是比cp服务发现产生更大的灾难.这时候可以容忍调用失败不会损失广告主的利益.作者回复: 首先，一般来说，为了平滑升级，服务发布都是滚动的，也就是说同一个服务的多个实例的发布不是一个原子和瞬间操作，所以正常情况下也会存在新老版本共存的情况。 其次，客户端是通过网络去服务注册发现中心获取服务的列表是通过网络的，可能有的客户端 A 10 ms 就获得到最新的列表了，客户端 B 由于网络丢包，经过重试 30 s 后才获得列表，这里就导致就算服务注册发现中心内部是CP的，但是从客户端获取服务列表的角度来看，依然是最终一致性的。 最后，关于你这个场景，如果需要一个信息在多实例上同时生效，比较好的方式是通过配置信息来实现，在后面的课程「配置中心」中有详细的讨论。
2022-01-2826
GAC·DU老师，如何优雅的摘掉一个发生故障的服务，让注册中心处理还是让上游服务调用时发现故障通报注册中心？如果这个服务有十个接口，只有其中的一个接口出了故障，能做到接口级别的隔离吗？ 之前在传统的物理机部署服务时利用Etcd来做服务的注册与发现，后来所有的服务都迁移到云原生下部署利用Service来进行服务发现和负载均衡很方便，老师我这个跟进的方向正确吗？ 服务注册与发现本质是实现服务的负载均衡，最终的目的还是让整个分布式系统实现高可靠，是AP系统还是CP系统，要看最终的服务用户的忍受度。比如一个量化交易系统CP应该比AP更合适。作者回复: 如何优雅的摘掉一个发生故障的服务，让注册中心处理还是让上游服务调用时发现故障通报注册中心？ 实例在注册发现中心上的注册信息是有时效性的，如果一个服务的实例发生故障，这个实例就不会再次和注册发现中心发送心跳或者注册了，这个实例的注册信息就会因为过期而被删除了 如果这个服务有十个接口，只有其中的一个接口出了故障，能做到接口级别的隔离吗？ 注册发现中心是关注实例层面的，对于接口层面不应该由注册发现来处理，不过熔断机制可以进行隔离，在后面的课程中会讨论这个问题。 云原生是大趋势，利用Service来进行服务发现和负载均衡的方向是正确的。 关于“比如一个量化交易系统CP应该比AP更合适。”的问题，在前面的问题中回复了，这里就不重复了。
2022-01-284
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-232
Pikachu一直有个问题想请老师帮忙解惑，使用kubernetes的部署的应用，服务间的访问可以通过k8s的service name进行访问，原理就类似于老师上面提到的，在K8s集群的DNS实现解析，并且集群还可以根据服务的可用状态进行节点加入和摘除。那么这种情况，我理解除了需要访问指定的节点情况以外，其他就已经满足服务注册和发现的机制了，是不是就不需要单独的服务发现中间件了？不知道理解的对不对作者回复: 是的，不需要了
2022-03-091
约书亚个人感觉mysql和redis不适合做注册发现中心的最重要原因不是高可用，而是一致性。Eureka能满足最终一致性。mysql和redis满足不了。作者回复: 对于 mysql 和 redis，如果不要求高可用，是可以实现强一致性的，比如同步复制，比如主不可以切换等操作。 高可用问题和一致性问题很多时候是可以相互转换的，CAP😀
2022-04-122
不吃辣👾老师 假如我一个底层服务部署节点万年不变，迭代周期非常长。这还适合做服务注册发现吗？是否为核心服务，是否需要平滑升级的场景才需要注册发现？注册发现与版本变更有啥区别和联系？作者回复: 服务发现是服务治理的一部分，是在微服务服务太多的情况下自动化运维服务的，如果从不更新，也就是运维成本低，那也不用服务发现也可以。 不过正常情况来说，服务发现就是非常方便集成的，集成一个 SDK就行，服务网格则更简单，新的服务应该使用。 版本变更的时候，可以通过注册发现发现新版本的服务。
2022-03-31- 不吃辣👾老师你怎么知道eureka zookeeper etcd redis的高可用存在的问题，哪里可以学习这部分知识？
作者回复: 后面的课程，“复制”和“一致性与共识”序列有详细介绍
2022-03-31
