奈薪颓忻我还特意按照播放量排序了一下准备先找个播放量高点的视频随随便巴拉几下。排名第一的视频播放量只有 6.3w。说实话在搜索之前我潜意识里觉得这种这个话题头部视频最次最次也得有个 10w 的播放吧而实际情况是前四的视频播放量满打满算加起来18w。这个数字让我瞬间把共识算法抛在脑后冒出了另一个念头要不看看微服务这个关键词的播放量你猜一下这个用“微服务”这个关键词在 B 站搜索然后按照播放量排序播放量第一有多少前四加起来又有多少......不要太保守往大了猜。......用“微服务”做关键词播放量第一 462w前四加起来 1600w就这我还抹掉了 5w 的“零头”。这个鲜明的对比确实引发了我的一点思考。从“共识算法”的 18w 到“微服务”的 1600w近 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 工程师”又下不了决心、没有足够的毅力往难走的路上走还在心里嘲讽正在这条更难的路上努力往前的人。其实工作的越久我越发现又是真正阻碍一部分技术人成长的正是这种“既要、又要、还要”的拧巴心态。而且我也曾经在这种心态中沉沦过一段时间。它让你既无法安心享受当下的成就又缺乏魄力去追寻更高的目标最终把精力都耗在了自我消耗和无效的评判上。想清楚自己想去哪儿然后坦然地、专注地走你自己的路。对你没选择的路保持尊重对你选择的路负起全责。最重要的是回头再看的时候不要用“假设”来美化你没走过的那条路。好了以上就是我个人的一些主观思考。