聊定律｜不专业，但有态度

最近一个定律出来了，我看到是毁誉参半

• 在科技圈引发了不少讨论，但绝大多数人都说不清这个新定律的核心本质到底是什么。半导体不是我专业，不知道这最后真实情况如何
• 结合我们现状来类比一下。
• 其实抛开晦涩的专业术语，不用复杂的物理、技术理论去解读，结合数据库领域的行业现状，就能通俗看透熵定律的底层逻辑。
• 也能看懂当下很多技术改造、国产化替代的普遍误区。

从字面上讲，是另辟蹊径。绕道解决问题。

• 这让我想到数据库行业的技术变迁：从 “极简高效” 到 “复杂堆砌”
• 早年的 IOE 时代，企业数据库架构非常简单高效。一台小型机，就能承载整套业务的算力、存储和稳定需求，架构单一、运维简单、故障率极低，整体系统高度有序。
• 后来随着技术进步以及其他诸多因素大家使用x86服务。组成了独立一堆数据库或者服务器集群搭建的分布式数据库。
• 单纯从数据层面来看，一堆 X86 服务器堆叠起来，确实可以实现和早年小型机相近、甚至更高的算力，性能指标也能做到基本持平。是不是有点这个意思。既然单机无法抗衡，拿一堆来齐头并进。单兵能力不行，那么就是集团作战。
• 但所有人都忽略了一个核心问题：算力可以靠数量堆砌，系统的稳定性、有序性、运维可控性，只会持续下降。机器数量成倍增加后，最直接的变化就是系统熵增加剧：整体架构复杂度暴涨，设计难度、开发工作量、日常维护工作量、故障排查成本全部翻倍提升。原本单一稳定的系统，变得庞大、杂乱、不可控，这就是技术迭代中最典型的熵增现象。

真实行业案例：堆机器换来的稳定，终究是昂贵的假象

• 行业里有一个非常经典、真实的数据库改造案例，完美印证了熵增的弊端。
• 有企业原本使用 Oracle 数据库，系统常年稳定运行，几乎没有重大故障，业务运转井然有序。
• 后续为了适配行业趋势、做架构升级，企业将成熟的 Oracle 系统，替换成了多节点 MySQL 集群架构。
• 改造完成后，算力看似提升了，但系统稳定性彻底崩塌：频繁出现卡顿、宕机、数据异常、并发报错等各类问题，故障层出不穷，业务严重受影响。
• 无奈之下，企业高薪外聘了一位资深技术总监。这位总监具备极强的架构设计和治理能力，通过精细化的架构优化、参数调优、流程治理，硬生生把混乱不稳定的 MySQL 集群系统调至平稳运行状态。
• 系统稳定后，企业却发现整体运维成本不降反升。看似换掉了昂贵的商用数据库、节省了软件授权成本，但支撑系统稳定的核心，是高薪总监的个人技术能力，人力成本、技术治理成本远超之前的支出。
• 更讽刺的是，后续企业为了压缩开支，辞退了这位高薪总监。
• 总监离职后，没有人能承接复杂的系统治理工作，原本被稳住的混乱架构彻底失控，各类故障卷土重来，系统再次陷入瘫痪。
• 这个案例道破了技术圈的一个真相：当产品本身的质量、架构本身的合理性无法解决问题时，单纯靠数量堆砌，不仅解决不了根本问题，还会带来极高的隐性成本和不可控风险。 靠人力、靠机器数量、靠集群堆叠补出来的稳定，从来都不是真正的稳定，只是暂时掩盖混乱的 “伪稳定”。
• 当然这里也看到了，如果有专业的人还是可以这样做的。大言不惭的说，我就是这种人。

结合两者做通俗比喻：技术堆砌的尴尬，百件短袖抵不过一件棉衣

• 用一个通俗的生活比喻，就能彻底理解这种概念：
• 如果我们没有制作棉衣的技术和工具，没办法造出一件保暖、合身、靠谱的棉衣。于是就选择走捷径，穿上一百件短袖，试图用数量堆叠的方式，达到和一件棉衣一样的御寒效果。 从结果来看，极端情况下，一百件短袖或许真的能勉强实现御寒的效果，功能上勉强达标。
• 但这种方式的弊端无比明显：
• 第一，极度不规整、不优雅，架构臃肿杂乱；
• 第二，成本更高、损耗更大、负担更重；
• 第三，极度脆弱，一旦出现一点问题，整体瞬间崩塌。
• 这和当下数据库、国产化技术改造的现状如出一辙。
• 当然知道怎么去做也行。比如你就是把篮框换成方的，乔丹照样扣篮。其实说到数据库替换主要就是应用适配，那么怎么来适配这是有讲究的。

从半导体到数据库 所谓卡脖子的遇到的问题都应该差不多

• 国产化替代的普遍误区：只换硬件，无视生态与适配
• 如今各行各业都在推进国产数据库替代，很多项目打着 “零改动、无缝替换” 的旗号。
• 但落地实操中根本做不到真正的无缝替代。为了完成替代目标，有时候往往只是简单堆叠大量国产服务器、数据库节点，用机器数量弥补技术差距。以至于有用户的开发部门说，我们本来是数据库的使用部门，现在变成数据库的基建部门了。机房都不够用了。
• 还需要对原有业务代码、架构逻辑进行隐性改动，工作量、运维难度、系统熵增全部大幅增加。
• 这就让我想到了数据库领域，芯片行业可能也是同样的逻辑。
• 例如X86 架构和 ARM 架构底层逻辑完全不同，生态、指令集、适配软件互不兼容。
• 很多项目只关注芯片硬件的替换，却完全不提后续的软件适配问题。
• 硬件架构切换完成后，原有大量配套应用软件、业务系统全部无法正常使用，需要大规模重构、改写、适配。都是CPU，但是有的软件就是不能用。
• 那么现在这种新定律，要不要面对这些问题？我不专业，不知道。但是数据库上确实是遇到了。
• 还有就是这样成本是不是增加了以及稳定性是不是下降了。这和数据库领域遇到的问题几乎一模一样。
• 每一次无底层技术突破的堆叠式升级，都是一次系统熵增，都是用复杂度、成本、稳定性，换取表面的技术迭代。

人和人的差距很大，但是优秀的人和优秀的人差距没那么大

• 我们想到这个别人是不是也有过？为什么没做？一定有其道理。
• 技术迭代的终极目标，是降熵、提效、维稳，让系统更简单、更稳定、更低成本。
• 真正的技术进步，从不是 “越多越好”，而是 “越精越稳”。