我特地按照播放量进行了排序，打算先找一个播放量较高的视频随便浏览一下。

排名第一的视频，播放量仅有 6.3 万。

说实话，在搜索之前，我内心直觉认为这个话题的头部视频至少也有 10 万+ 的播放量。

然而实际上，前四名视频的播放量加起来才 18 万。

这个数字让我立刻将共识算法抛在脑后，产生了另一个想法：或许可以看看“微服务”这个关键词的播放量如何？

你猜猜看，用“微服务”作为关键词，在 B 站搜索并按播放量排序，播放量最高的视频有多少，前四名加起来又是多少？

...

...

不要太过保守，大胆猜测。

...

...

用“微服务”作为关键词，播放量最高的视频有 462 万，前四名加起来有 1600 万，我甚至还去掉了 5 万的“零头”。

这种明显的对比确实引发了我一些思考。

从“共识算法”的 18 万到“微服务”的 1600 万，相差近 90 倍。看到这些数据，你大概能猜到我在想些什么。

面对这种现象，我在思考：

共识问题是微服务得以存在的理论基础。但从这些数据来看，我觉得知识体系在某个环节出现了严重断裂。

当然，我得先声明一下。

我知道这种统计方法完全不准确、不科学、不正确。

但“知识体系出现了断裂”这个结论，我认为是正确的，也是正常的现象。

只是让我感到惊讶的是，我原本以为差距不会达到十几万到一千六百万，这种近 90 倍的差距。

这背后其实有一个值得探讨的现象，即 IT 行业普遍存在的“快速上手”与“底层原理”之间的平衡问题。

数据为什么会这样

首先，我思考了一下：数据为什么会这样？

我观察到，“微服务”排名前四的视频都是培训机构上传的系统课程。

培训机构的目的很简单：尽快上手。

其底层逻辑是为了“尽快找到工作”。

本质上是将学员在最短时间内培养成能满足企业初级编码岗位需求的人才。

在这种标准下，一切不能直接、快速为初级编码岗位服务的知识，都会被认为是多余的。

因此，你看他们的课程：

例如讲到 Eureka 时，基本上都在讲解如何使用，代码如何编写，以及如何运行。

我快速浏览了相关内容，完全没有提到“共识算法”和 CAP 相关的内容。

当然，也可能是我跳着看的，看的不够仔细，其实讲了但我没看到，但这并不重要。

总之，事实是入门课程完全可以不涉及共识算法，甚至不提及 CAP 理论。

这类入门课程的受众广泛，播放量高是很自然的事情。

写到这里，不得不再次声明：我并不是在批评这种授课方式，我只是在陈述我认为“数据为什么会这样”的事实。

相反，从现在的角度看，这样的课程安排是合理的。

试想一下，对于一个刚从单体服务转向分布式系统的初学者来说，如果一开始就讲解注册中心时直接引入 CAP 和共识算法等非常抽象、难以理解的概念，可能会非常令人沮丧。

这会导致“从入门到放弃”的结果，与“尽快找到工作”的目标背道而驰。

在市场中，对于大多数初中级岗位，公司更看重的是你是否能在现有框架下完成业务开发。

如果公司使用的是 SpringCloud 全家桶来构建微服务，只要你能正确、熟练地使用，已经能够胜任大部分工作。

至于共识算法等概念，最多在面试时出现一下就已经很不错了。

更进一步

对于培训机构和学习者来说，都需要“更进一步”。

对于培训机构而言，虽然这些是入门课程，但我认为理想的状况是在讲解相关组件时，能够引出其背后的理论，但要适可而止。

例如：

从“为什么要使用服务注册中心？”引出服务发现的问题。

从“Eureka 和 Nacos 的区别？”引出 CAP 理论。

从“分布式事务如何实现？”引出数据一致性问题。

从“集群数据同步”引出共识问题。

只需帮助初学者建立一个宏观的、模糊的认知即可，就像种下一粒种子。

对于学习者来说，你不能一方面自嘲自己是“CRUD 工程师”，另一方面却没有足够的理论基础和技术决策能力。

你需要让前面提到的种子成长为一棵技能树。

例如，面对 CAP 权衡时，你应该通过你的技能树知道这不是一个选择题，而是一个权衡题。

举个简单的例子。

站在 CAP 的角度，你应该知道为什么 Eureka 客户端要缓存服务列表？

因为在与注册中心网络分区 P 时，为了保证服务的可用性 A，会牺牲部分一致性 C。

你也应该知道为什么 ZooKeeper 不能像 Eureka 那样允许节点间长时间失联？

因为它要保证一致性 C，在出现分区 P 时，宁愿牺牲可用性 A。

因此，你应该明白，在要求强一致性的金融场景下，底层设计要保证 CP；而在追求高可用的电商场景下，要保证 AP。

再比如，当学习到 Seata 时，需要深入探讨各种分布式事务模式的实现，例如 2PC、TCC、Saga 等，这些模式本质上是在传达什么信息，是如何与 ACID、BASE 理论以及最终一致性等概念联系起来的。

我知道这些要求对于新手来说，确实很高。

但结合我自己亲历的技术路径，我确实是先掌握了基本的使用方法，然后在多年的实践中逐渐理解了这些高级概念。

而我上述所说的这一切，核心是想表达：首先你需要有一个起点，然后让这个起点发展成一个体系。

有些人运气较好，获得起点的过程较为轻松，无需费太多力气，在这一点上确实存在差异。

但在将起点发展成体系的努力上，我认为大家所需投入的精力相差不大，而且这方面完全可以靠勤奋来弥补不足。

灌溉

要让起点发展成体系，你需要用知识去滋养。

例如，具体到前面讨论的问题。

写作过程中，我回想起了之前看过的一本书，《数据密集型应用系统设计》，这本关于分布式领域的书籍，是必读之作，是非常好的“养料”。

源码也是极佳的养料，可以从一些相对简单的项目开始阅读。

比如读一读 Nacos 客户端服务发现的流程，你会发现，理论在实际代码中是如何体现的。

也可以尝试阅读一些他人整理好的论文导读，比如前面提到的 Raft，相关论文已被许多人解读，甚至网上已有非常清晰的解释原理的可视化动画，有助于你理解其核心思想。

这些都是我过去采用的较为“传统”的学习方法。

如今有了 AI 大模型的支持，学习新技术、寻找优质资料变得更加便捷。

你可以让 AI 帮你解释复杂概念、推荐学习路径、甚至模拟面试问答，这大大降低了学习的难度。

写在最后

最后，我还想表达一个额外的观点。

我们回到最初的数据。

那 1600 万播放量，代表了一条顺畅、明确且宽广的道路。

而 6.3 万播放量，则代表了一条更加孤独、艰难、崎岖的通向山顶的路。

每个人都会在大路上走一段，但有人走着走着路就不一样了。

无论你选择哪条路，道路都是清晰的，资源都是丰富的。选择任何一条路，并坚定地走下去，都值得敬佩。

但是，你需要自洽。

自洽意味着，你不能一边享受着这条“顺畅、明确且宽广的道路”的便捷与轻松，一边自嘲自己是“CRUD 工程师”，又没有决心和毅力去走更难的路，还在心里嘲笑那些在这条更难的路上努力前行的人。

工作时间越长，我越发现，真正阻碍部分技术人成长的，正是这种“既要、又要、还要”的纠结心态。

而且，我也曾在这种心态中沉沦过一段时间。

它让你既无法安心享受当前的成就，又缺乏勇气去追求更高的目标，最终把精力都耗费在自我消耗和无效的评判上。

想清楚自己想去哪里，然后坦然地、专注地走你自己的路。

对你未选择的路保持尊重，对你选择的路负起全责。

最重要的是，回头再看时，不要用“假设”来美化你未曾走过的那条路。

好了，以上就是我个人的一些主观思考。