说在前面

最近有小伙伴拿到了一线互联网企业如微博、阿里、汽车之家、极兔、有赞、希音、百度、网易、滴滴的面试资格，遇到一几个很重要的面试题：

服务注册发现，该选 AP 还是 CP？ 为什么？

最近有小伙伴在面 阿里。

小伙伴没有系统的去梳理和总结，所以支支吾吾的说了几句，面试官不满意，面试挂了。

所以，给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

为什么要使用服务发现?

在云原生+微服务时代，服务实例是 云原生的，动态部署的，我们甚至 不知道这个服务运行在哪台服务器上，不知道它的 IP 地址和端口 。

所以，现在的云原生+微服务架构下，情况变得复杂了：

• 服务的地址不是固定的，每次启动都可能不一样。

• 服务可能会自动扩容、缩容、重启或升级，导致地址频繁变化。

这就带来一个问题：怎么让client 客户端始终找到正确的服务server？

为了解决这个问题，引入了一个叫“服务发现”的机制。

具体流程如下：

(1) 服务注册：每个服务启动后，会把自己的网络地址告诉一个叫“服务注册中心”的地方。

(2) 定期更新：服务会定时发送“心跳”来告诉注册中心自己还活着。

(3) 服务下线：如果服务停止或者出问题，注册中心会把它从列表中移除。

(4) 客户端查询：当其他服务想调用它时，先去注册中心获取可用的服务地址。

(5) 负载均衡：客户端从多个可用实例中选一个，发起请求。

这样即使服务地址经常变，也能保证请求能正确发到可用的服务上。

• 微服务环境下，服务地址不固定。

• 需要通过“服务注册中心”动态管理服务位置。

• 客户端通过查询注册中心 + 负载均衡，实现对服务的可靠调用。

CAP 理论

CAP 理论是分布式系统中最基础、最重要的理论之一。

它最早由加州大学的 Eric Brewer 在 1998 年提出，后来在 2000 年他提出了一个猜想：一致性（C）、可用性（A）、分区容错性（P）这三项，在分布式系统中无法同时满足。

这个猜想在 2002 年被麻省理工的两位科学家 Seth Gilbert 和 Nancy Lynch 从理论上证明成立，从此被称为 CAP 定理。

CAP 是哪三个指标？

CAP 指的是：

• C（Consistency）一致性：所有节点看到的数据都是一样的。

• A（Availability）可用性：每次请求都能得到响应。

• P（Partition Tolerance）分区容错性：网络出问题时，系统还能继续工作。

它们不能三者兼得，只能选两个。

C：一致性是什么意思？

你刚写进去的数据，马上就能读出来。

比如你在 Node1 写入了 V1，别人访问 Node2 也能立刻读到 V1。

A：可用性是什么意思？

不管什么时候发请求，系统都会给你一个回应，哪怕不是最新的数据，也不能不回。

P：分区容错性是什么意思？

就是当网络断了、部分节点失联时，系统仍然能对外提供服务。

正常情况下的运行

假设我们有两个节点 Node1 和 Node2，初始数据都是 V0。

• 用户向 Node1 更新为 V1；

• Node1 把更新同步给 Node2；

• Node2 成功更新为 V1；

• 这时候无论访问哪个节点，都能读到 V1。

这样就同时满足了 C、A、P。

网络异常时的情况

现在 Node1 和 Node2 之间的网络断开了。

用户向 Node1 写入 V1；

Node2 不知道这个变化，还是 V0；

如果用户访问 Node2：- 要么返回旧数据 V0（牺牲一致性）；- 要么一直等直到恢复（牺牲可用性）；

所以，只要支持分区容错（P），就必须在一致性和可用性之间做选择。

CAP 的三种组合方式

CA 架构（放弃 P）

• 系统只保证一致性和可用性；

• 前提是网络永远正常；

• 实际上很少用，因为网络不可能不出问题。

CP 架构（放弃 A）

• 遇到网络问题时，宁愿暂停服务也要保证数据一致；

• 常用于对数据准确性要求高的场景，如银行交易、数据库。

AP 架构（放弃 C）

• 遇到网络问题时，先保证服务能用，数据可以暂时不一致；

• 常见于社交平台、购票系统等对用户体验更敏感的场景。

CAP 的常见误解和实际应用

误区一：CAP 是非黑即白的选择

实际上，很多系统并不是完全选 C 或 A，而是根据业务阶段灵活调整。

例如：

• 查票时可以用 AP；

• 支付时必须用 CP。

误区二：没有考虑延迟和弱一致性

CAP 只讲了“是否满足”，但现实中有很多中间状态：

• 数据可以慢慢同步（最终一致性）；

• 有些功能可用，有些不可用；

• 网络延迟也可以看作一种“轻度分区”。

误区三：CAP 不适用于所有场景

CAP 是理想模型，实际系统要考虑更多因素，比如性能、成本、业务逻辑等。

总结一句话：

在分布式系统中，网络出问题是常态，所以必须支持分区容错（P）。

这就意味着，只能在一致性（C）和可用性（A）之间做取舍，不能三者都要。

CP 型  ：  基于 ZooKeeper  实现  服务发现

ZooKeeper  服务发现 流程分析

(1) 服务元数据znode

服务管理端先在 ZooKeeper 上建一个根目录，比如按接口名来命名：/dubbo/com.foo.BarService。

在这个目录下再建两个子目录：providers（放服务提供方信息）和 consumers（放服务调用方信息）。

2.服务注册

服务提供方注册时，会在 providers 目录下创建一个临时节点，里面记录自己的地址等信息。

用临时节点是因为如果服务挂了，ZooKeeper 会自动把这个节点删掉，表示这台服务不可用了。

(3) 服务订阅

服务调用方订阅服务时，会在 consumers 目录下创建一个临时节点，记录自己是谁。

同时它还会“监听”providers 目录下的所有节点变化。

(5) 服务通知

当有服务提供方上线或下线时，ZooKeeper 就会通知所有监听该服务的调用方，让它们知道最新的服务状态。

通过 ZooKeeper 的临时节点和监听机制，服务提供方和调用方可以自动感知彼此的状态变化，实现服务的注册与发现。

ZooKeeper  服务发现  存在的问题

问题一：

ZooKeeper 的一个特点是数据强一致，也就是说，只要有一个节点更新了数据，所有其他节点都会同步更新。

但这也带来一个问题：当连接的节点很多、读写频繁，并且存储的数据目录太多时，ZooKeeper 会变得很吃力，CPU 使用率飙升，最终可能直接崩溃。

更麻烦的是，一旦 ZooKeeper 宕机重启，那些还在不断发送请求的业务系统会瞬间给它很大压力，导致刚启动就再次崩溃。

问题二：

ZooKeeper 在遇到网络分区时处理不好服务发现的问题。

如果某个区域内的 ZooKeeper 节点数量不够多（达不到半数以上），这个区域的客户端就完全无法使用 ZooKeeper 的服务发现功能。

AP型： 基于 Eureka 的服务发现（AP）

Eureka  服务发现 流程分析

(1) Eureka-Client 启动时

会把自己注册到一个 Eureka-Server 上，并且每 30 秒发一次心跳，告诉服务器自己还活着。

(2) Eureka-Server  处理

(3) 接收到注册或心跳的 Eureka-Server 会把这些信息打包，统一同步给其他 Eureka-Server，保证所有服务器数据一致。

• Eureka-Client：就是你的服务应用。

• Eureka-Server：是服务的“登记处”，用来记录有哪些服务在运行。

• Client 会定时上报状态，Server 之间会互相通知更新，保持信息一致。

Eureka  服务发现  存在的问题

问题一：客户端拿到太多不需要的服务地址

客户端会拿到所有服务的地址列表，不管这些服务是不是自己需要的。

这会浪费很多内存资源，特别是在多个数据中心部署的情况下，本地客户端其实只需要访问本地的数据中心服务就够了。

问题二：客户端靠定时拉取更新数据，效率低

客户端是通过定时轮询的方式从服务端获取服务信息的。

这种方式有两个问题：

• 数据更新不及时，有延迟；

• 即使没有变化，也会不断拉取，浪费性能。

问题三：Eureka 集群一致性机制压力大

Eureka 集群中，每个节点都会把收到的写操作同步给其他所有节点（包括心跳信息）。这种设计带来几个问题：

• 每个节点都要存全部数据，内存容易撑不住；

• 客户端越多，集群写压力越大，扩容效果差；

• 所有节点配置必须一致，只能靠升级硬件来应对增长。

扩展：Eureka 2.0 的改进方向

为了解决这些问题，Eureka 2.0 提出了以下优化：

• 数据推送从“客户端主动拉”改为“服务端主动推”，并支持按需订阅具体服务；

• 写操作集中在稳定的小集群处理，读操作可以单独扩容；

• 增加了日志审计和更强大的管理界面。

这套系统在早期设计上存在一些效率和扩展性上的问题，Eureka 2.0 就是在尝试解决这些痛点，让服务发现更高效、更灵活。

（AP/CP）混合型：基于 阿里 Nacos 的服务发现

和 Eureka 1.x 相比，Nacos 做了这些改进：

• 数据同步更高效：

不再一个一个同步数据，而是批量处理，通过长连接+定时更新来保持数据一致；

• 按需推送数据：

客户端只订阅自己关心的服务信息，服务端只推送这部分数据；

• 双集群结构：

把集群分成两部分，一部分接收注册信息（session 集群），另一部分做数据汇总和压缩（data 集群），然后把整理好的数据再推回 session 层缓存，客户端直接从这里获取数据。

Nacos 的“推送”机制其实是“伪推送”：

虽然看起来像服务端主动推给客户端，其实还是客户端在不断拉取。

流程如下：

(1) 客户端每隔30秒请求一次服务端，看有没有配置变化；

(2) 如果有变化，服务端立刻返回结果；

(3) 客户端收到响应，就知道配置变了。

总结要点：

• 数据同步方式升级，效率更高；

• 客户端只关注自己需要的数据；

• 架构分层清晰，扩展性更强；

• 推送是假的，其实是客户端轮询拉取，但响应快，看起来像推送。

Nacos 满足AP，又满足CP

Nacos 和 Eureka、Zookeeper 不一样，它既可以支持 AP，也可以支持 CP。

默认情况下，Nacos 是 AP 模式。但它可以根据客户端注册时的设置，自动切换为 CP 模式。

• 如果 client 注册时设置了 ephemeral=true，那这个节点就是 AP 的，用的是 distro 协议；

• 如果 client 注册时设置了 ephemeral=false，那这个节点就是 CP 的，用的是 raft 协议。

也就是说，在同一个 Nacos 集群里，可以同时存在 AP 和 CP 的节点，只是对不同的服务节点有不同的行为。

这样设计的好处是：能适应更多实际业务场景的需求。

• AP模式：强调可用性，适合临时节点（如微服务实例），即使部分节点故障，系统也能继续运行。

• CP模式：强调一致性，适合持久化节点（如配置中心），保证数据准确无误。

通过这种方式，Nacos 实现了灵活的支持能力，满足不同场景需求。

吊打面试官：一般来说，服务发现 更看重可用性（A）而不是一致性（C）

在服务发现中，有信息比没信息好，哪怕这个信息可能不准。

所以》一般来说，更倾向于选择 AP 模式。

在 AP 模式下，可能会拿到错误的服务地址，比如某个已经宕机的服务器。

但只要系统里有重试机制和负载均衡，就能自动换一个正常的服务器继续请求，整体流程不会受影响。

• 图中展示了 AP 模式下调用服务的基本流程；

• 即使拿到的信息不准确，也能通过失败重试 + 负载均衡来兜底；

• 这是为什么在服务发现问题上，很多人更看重可用性（A）而不是一致性（C）。

如何学习AI大模型 ？

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。【保证100%免费】🆓

CSDN粉丝独家福利

这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取 【保证100%免费】

读者福利： 👉👉CSDN大礼包：《最新AI大模型学习资源包》免费分享 👈👈

（👆👆👆安全链接，放心点击）

对于0基础小白入门：

如果你是零基础小白，想快速入门大模型是可以考虑的。

一方面是学习时间相对较短，学习内容更全面更集中。
二方面是可以根据这些资料规划好学习计划和方向。

👉1.大模型入门学习思维导图👈

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

对于从来没有接触过AI大模型的同学，我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。（全套教程文末领取哈）

👉2.AGI大模型配套视频👈

很多朋友都不喜欢晦涩的文字，我也为大家准备了视频教程，每个章节都是当前板块的精华浓缩。

👉3.大模型实际应用报告合集👈

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。（全套教程文末领取哈）

👉4.大模型实战项目&项目源码👈

光学理论是没用的，要学会跟着一起做，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战项目来学习。（全套教程文末领取哈）

👉5.大模型经典学习电子书👈

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。（全套教程文末领取哈）

👉6.大模型面试题&答案👈

截至目前大模型已经超过200个，在大模型纵横的时代，不仅大模型技术越来越卷，就连大模型相关的岗位和面试也开始越来越卷了。为了让大家更容易上车大模型算法赛道，我总结了大模型常考的面试题。（全套教程文末领取哈）

为什么分享这些资料?

只要你是真心想学AI大模型，我这份资料就可以无偿分享给你学习，我国在这方面的相关人才比较紧缺，大模型行业确实也需要更多的有志之士加入进来，我也真心希望帮助大家学好这门技术，如果日后有什么学习上的问题，欢迎找我交流，有技术上面的问题，我是很愿意去帮助大家的！

这些资料真的有用吗?

这份资料由我和鲁为民博士共同整理，鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位，在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利，同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

CSDN粉丝独家福利

这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取 【保证100%免费】

读者福利： 👉👉CSDN大礼包：《最新AI大模型学习资源包》免费分享 👈👈

（👆👆👆安全链接，放心点击）