01｜服务注册与发现：AP和CP，你选哪个？
前置知识
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了微服务架构中的服务注册与发现的核心问题，从服务端崩溃检测、客户端容错和注册中心选型三个角度展开讨论。文章重点讨论了注册中心如何判断服务端已经崩溃，以及客户端在服务端崩溃时如何进行容错处理。强调了心跳机制在判断节点是否崩溃方面的重要性，以及客户端在服务端节点崩溃后如何进行节点切换和重试。文章为读者提供了全面的技术视角和实践经验，对微服务架构下的服务注册与发现进行了深入剖析，为读者快速了解微服务架构中服务注册与发现的关键问题提供了有益的指导。同时，还提供了注册中心选型的相关内容，强调了在注册中心选型上，应该选择AP模式，如Eureka或Nacos。整体而言，本文为读者提供了深入的技术视角和实践经验，对微服务架构下的服务注册与发现进行了全面剖析，为读者提供了有益的指导。
《后端工程师的高阶面经》，新⼈⾸单¥59
全部留言(28)
- 最新
- 精选
小虎子🐯置顶添加小助手微信geektime012，回复「后端面试」，即可进入专栏学习群，领取面试资料包~2023-07-21归属地：北京
牧童倒拔垂杨柳如果出现注册中崩溃，站在客户端的角度，会有两种情况 1. 只有注册中心崩溃了 2. 注册中心和所有服务端节点一起崩溃了 客户端需要确认是哪种情况，客户端需要继续向注册中心发送心跳，同时使用本地缓存的服务端节点列表，向服务端发送请求，确认是否出现无法访问的服务端节点，可以分为以下几种情况 1. 向注册中心发送心跳失败，但是服务端仍可调用，此时因根据客户端容错策略使用本地缓存的服务端节点进行调用 2. 向注册中心发送心跳失败，同时服务端不可调用，此时客户端需要使用本地缓存的服务端节点，确认是否所有服务端节点都不可用，如果都不可用，客户端停止向服务端发送请求，并保持向注册中心发送心跳，等待注册中心重新上线 还有一种情况是客户端还没缓存服务端节点列表，这时注册中心挂了，此时客户端无法获取到服务端节点的位置信息，只能保持向注册中心发送心跳 等待注册中心上线作者回复: 赞！
2023-07-21归属地：河北12
stg609好像并没有解释为什么高可用是标准答案作者回复: 嗯嗯，应该说 AP 和 CP 本身就是两相其害取其轻。在大规模集群上，注册中心崩溃的影响太大，因为大部分服务都是使用同一个注册中心的。 而选择 AP 放弃 C，也就是客户端会拿到一些错误的节点，但是可以通过客户端容错来解决。 不过我个人的观点是：小规模集群选 CP，大规模集群选 AP。我在课程里面用“标准答案”的说法，就是指大厂中比较多人赞同选 AP。
2023-06-21归属地：浙江48
杯莫停老师要是能距举例说明一下选C(数据一致性)和选A(服务可用性)的优缺点就更好了,谢谢。我觉的应该不是体量大小的问题，而是对数据的一致性要求是否严格的问题。不知道我理解的对不对。作者回复: 不是，这个不是你业务数据一致性的问题。 实际上选 C 还是选 A，实际上就是： - 你是要尽可能保证注册中心活着，但是你更大概率拿到错误的注册信息 - 还是你要尽可能拿到准确的注册信息，但是注册中心可能崩溃了 我个人的倾向是优先选用 CP，直到发现公司的体量上来了，CP 的注册中心撑不住读写压力了，就换 AP。 这里强调的一致性，是指注册信息的一致性，不是业务数据的一致性。也就是说，即便你拿到了错误的注册信息，也就是调不通而已，不会污染你的业务数据。
2023-07-05归属地：四川5
王博刚好经历过我司注册中心炸掉的outage，当时使用etcd作为注册中心，etcd维护团队离职了，我们做了以下事情： 1、禁止所有部署（我们使用aws，部署可能会换新机器） 2、保护住所有的现有机器，禁止scale in和scale out（多花了很多钱qaq） 3、在经历多轮抢修依然无法启动etcd的情况下，我们切换到了consul 4、注册中心团队对consul添加了fallback的方案，当consul挂掉的时候进行fallback 5、我们有个服务是通过注册中心获取有序的节点列表从而分配定时任务执行，注册中心故障时可能有时成功有时失败，所以我们添加了基于配置的固定列表，当注册中心down掉时，我们可以配置自己的机器列表，在内存中做排序，以分配定时任务作者回复: 赞！ 我可以总结为就是两个核心手段： - 启动备份注册中心，而且是异构的备份中心。这里你们能做到自动切换吗？还是依赖于人手动切换？ - 兜底节点：就是人手动配置一些固定 IP，万一注册中心崩了就用这个。这个缺陷就是 IP 需要人来维护，比如说万一某个IP 不可用了。 这两个手段用于面试都很不错！
2023-07-04归属地：河北35
penbox1. 如果注册中心崩溃了，你的系统会怎么样？ 注册中心崩溃之后，相当于三角形里面客户端与注册中心、服务端与注册中心这两条线断掉了。 对服务端的影响就是，服务端上线和下线没法通知到客户端。 对客户端的影响是，客户端没法更新可用服务端列表，只能使用本地现有的可用服务端列表，勉强维持服务。 2. 再列举一个心跳频率、心跳重试机制对系统可用性影响的例子？ 心跳频率过长，会增加系统判断故障的延迟；如果心跳频率过短，又会增加系统负载和网络流量，造成系统资源的过度消耗。需要在系统负载和实时性要求之间做权衡，选择合适的心跳频率。 心跳重试机制，避免了偶发性的网络抖动造成的故障误判，但同时也变相增加了判断故障的延迟。重试次数、间隔设计不合理，同样会造成系统资源的过度消耗。作者回复: 赞！ 我补充一个极端情况，心跳太频繁，还可能直接整个网络里面大部分都是心跳请求，或者心跳本身就就把服务器打垮了。
2023-06-29归属地：四川3
大将军Leo。。老师 如果是注册中心的节点信息被误删除了，而且这个信息注册中心已经同步给客户端了，这种情况客户端客户端是不是要做一个缓存历史节点的功能？不然被全删了没办法保持心跳了作者回复: 其实不太需要做这个历史节点的功能，因为很少出现注册中心节点被误删除。我能想到的就是这个误删除，是不是运维手贱，或者说开发在修复数据的时候手贱删了？这算是一个非常非常罕见的错误，所以我个人判断没有太大的必要去引入这个功能。
2023-11-04归属地：广东1
周新建”客户端也要朝着那个疑似崩溃的服务端节点继续发送心跳。如果心跳成功了，就将节点放回可用列表。“ 客户端能向服务端发送心跳么？对这个点比较疑惑作者回复: 能，而且很多微服务框架都有这个功能。因为服务发现只能证明，服务端和注册中心没问题。但是你不知道客户端和服务端之间有没有问题，因此会有一个心跳机制。
2023-08-18归属地：广东31- Geek_281b2d讀完這堂課有以下疑問,想請問一下課堂老師 1. 這邊的客戶端是包含瀏覽器& Mobile等等嗎 2. 每個服務前面都會一台loadbalance 主機去做附載平衡,請問是附載平衡主機的網址去服務註冊中心註冊還是服務去註冊 3. 如果目前系統是採用k8s+istio,但是目前是將k8s中每個服務對應的endpoint domain寫到istio中,讓istio的網關可以在api請求過來時,經由網址找到服務端,請問這樣的架構算是有服務註冊嗎?
作者回复: 1. 是指服务调用中的 A调用 B，那么 A 就是客户端。 2. 如果你的服务前已经有一个 loadbalance 了，这种形态其实接近使用网关了，你可以服务直连这个 loadbalance。一般这种 loadbalance 都是固定的，比如说有一个固定的域名。如果真要走服务注册与发现，则是注册 loadbalance 的地址。 3. 有服务注册，但是没有注册中心。也就是接近利用 DNS 来执行服务发现的机制。不过这算是正常做法，在 k8s 里面，服务中心其实也没太大必要。
2023-07-09归属地：中国台湾1 
木几丶回答问题：你可以再举出一个心跳频率、心跳重试机制对系统可用性影响的例子吗？ 据我所知，所有根据心跳来判断是否存活的系统都会有因延迟带来的可用性问题，例如Redis主从切换、Nginx反向代理upstream探测，不同系统应对这种可用性问题也有各自的办法，如Redis直接就是服务短暂不可用、Nginx则是选择下一个服务作者回复: 是的。这其实比较没办法，毕竟在分布式情况下，说到底一个节点要想知道另外一个节点的情况，都是只能发个请求。 这种决策背后都是有各自理由的。不过总的来说，我认为就是还是遵循了我这节课说的，要么就是误以为死了，要么就是误以为没死，总之就是难两全。
2023-06-26归属地：福建1
