IT乱象面面观

数据库管理-第356期 IT的那些"迷之操作"（20250811）

30efd366624530ae0b59caeac2b6a15a.jpg

不知不觉，写系列文章超过350期了，也从最早单纯的写Oracle到写了很多数据库，也从软件写到了硬件，中间还穿插了一些和业务应用有关的内容。偶尔还会吐吐槽、骂骂人，但是似乎好久没有写吐槽文了，看着王总写了好几篇“针砭时弊”的文章，我也开始躁动了，没错，这又是吐槽的一篇，对一些现象发表一些自己的看法。

业务架构越来越复杂

这几年我主要服务的客户，由于是传统行业，所以IT发展总比互联网行业慢了大半拍。明明行业特性、业务模式都大不相同，却好像不管这些架构、技术是否真的适用，中台、微服务、容器化、大数据这些概念，都要一股脑儿强行跟进。 于是就看到了各种 “奇观”：一个业务规模远不及头部互联网公司的企业，搭起的Hadoop集群规模却堪比好几个互联网公司的总和；数据中台、能力中台、AI中台轮番上马，看似 “交相辉映”，实则各自为战、互不相通；更别说那些为了 “显得先进” 硬凑出来的架构组合——虚拟化平台叠容器平台，再套上微服务框架，活生生造出一套 “大型综合反骨型业务架构”。 后续的麻烦就更具体了：一个微小的故障可能引发连锁反应，牵连好几个业务模块，排查时得翻遍 N 个系统配置、日志，甚至要动全局操作才能解决；负载均衡策略和数据库连接池配置交叉混乱，明明是独立模块却总出现 “牵一发而动全身” 的依赖问题；接口之间时不时冒出些说不清道不明的异常，今天能通明天就断，查来查去发现是某个隐藏的依赖没处理好；更别说 CI/CD 流程形同虚设，灰度发布更是奢望，哪怕改一行代码，都可能要重启几十上百个服务，光准备停机窗口就得协调很久。 不可否认，复杂的业务架构看起来确实 “高大上”，说不定还能靠着这些概念评上几个行业标杆、技术奖项。但在我看来，对绝大多数传统行业来说，业务架构真的不是越复杂越好，原因其实很简单：

• 业务特性决定了 “不需要”：传统行业的业务模式相对稳定，不像互联网公司需要靠极速迭代、高频上新抢占市场。它们更需要的是 “平滑”——稳定支撑现有业务流程，而非为了追 “潮流” 强行让架构跟着技术概念跑。复杂架构的核心价值是支持快速试错、弹性扩展，可传统行业既不需要频繁试错，也用不上那么强的扩展能力，纯属 “为复杂而复杂”。
• 投入上限撑不起 “复杂度”：传统行业对IT的投入往往有明确上限，硬件资源不会像互联网公司那样 “按需扩容”，IT 团队的规模和专业度也很难维持 —— 毕竟互联网公司能养得起专门的架构师、运维专家、性能优化工程师，传统行业往往是 “一个人干三个人的活”。但复杂架构对软硬件的要求极高，比如微服务需要精准的服务治理，容器化需要完善的监控告警，这些都需要持续投入，一旦跟不上，架构就会从 “助力” 变成 “拖累”。
• 核心诉求是 “稳定优先”：传统行业的 IT 系统大多是业务的 “支撑者”，而非直接的 “利润创造者”。银行的核心系统、工厂的生产管理系统、商超的收银系统，这些系统的第一要求是 “不出错”，而非 “功能多”。复杂架构意味着更多的节点、更多的依赖、更多的潜在风险，反而会威胁稳定性——有时候，一个简单、可靠的单体架构，比一堆 “时髦但脆弱” 的复杂模块更实用。

说到底，技术和架构终究是为业务服务的。不同的业务需求应当用不同且适合的技术架构去实现。

数据离计算越来越远

在基础设施架构演进中，特别是云原生架构中，底层存储系统的设计正越来越多地围绕三大核心目标展开：高可用性（通过多副本、跨地域冗余抵御故障）、弹性伸缩（按需扩容以匹配业务波动）、成本适配（根据数据冷热分层选择存储介质）。但这一趋势也带来了一个显著变化：数据存储与CPU的物理距离和逻辑链路正不断拉长，由此引发的延迟问题，在数据库这类对性能极度敏感的场景中显得尤为突出。 具体来看，传统存储架构与新型网络存储架构的延迟差异，本质上源于数据传输路径的复杂度：

• 本地盘（如NVMe SSD）通过PCIe总线直接与CPU互联，数据无需经过复杂的网络协议栈或中间转发节点，延迟可低至微秒级，随机IOPS 能轻松突破几十万，是 “离计算最近” 的存储形态；
• 基于SAN的块存储（如FC SAN、iSCSI SAN）虽依赖专用网络传输，但通过精简协议栈（如FC协议）和硬件加速（如阵列卡缓存），能将延迟控制在毫秒级低位，且支持低抖动的稳定 IO，足以支撑企业级数据库的高频交易需求。

相比之下，依托网络的分布式存储架构（如云块存储、分布式文件存储等）的延迟则面临“数量级提升”的挑战。这类架构为实现弹性和冗余，数据需经过虚拟化层、分布式元数据节点、跨节点网络转发等多重环节，延迟也往往在10-100毫秒级（视架构复杂度而定）。更关键的是，网络抖动、节点负载不均等问题可能导致延迟波动增大——而数据库（尤其是OLTP数据库）对延迟的 “稳定性” 要求甚至高于 “绝对值”，一次突发的延迟飙升就可能引发事务超时、锁等待堆积等连锁反应。 当然，网络存储的延迟问题并非无解，通过NVMe over Fabrics（NVMeoF）协议优化、RDMA技术、本地缓存加速（如使用PMEM、DRAM或SSD作为二级缓存）、智能数据分片（将热点数据调度至离计算更近的节点）等技术，可显著缩小与传统存储的差距。但这也意味着额外的架构复杂度和成本投入。 因此，对于数据库场景而言，网络存储的 “弹性与可用性优势” 并非总能覆盖 “延迟劣势”：若缺乏针对性优化，其数据存取性能可能难以满足核心交易库、高频查询库的需求。这也提醒我们，存储架构的选择需在业务目标（可用性、弹性）与技术约束（延迟、成本）之间找到精准平衡，而非盲目追随 “分布式”“网络化” 的趋势。

另一个场景则依然是源于数据层架构，因为数据模态的不同，需要使用不同的数据库，比如MySQL/PG存储关系型数据、MongoDB存储JSON数据、Neo4j存放图数据、Milvus存放向量数据、Redis存放KV数据、ElasticSearch存放全文检索数据等等，不同的数据库之间并不相通，无法关联使用，因此每种数据库只能完成自己存放模态数据的计算工作，而多模态是的关联操作则需要通过应用层实现，这就造成了数据没有直接在数据库中完成计算，到实际计算需要比较长的链路。另一个原因则是国产化，由于现在许多国产数据库的性能与功能并没有达到国外主流商业数据库的高度，因此在数据库国产化过程中出现了简化数据库使用，而将繁杂计算上移之应用层的方案。当然随着多模数据库的快速兴起以及国产数据库的奋起直追，这些问题都在被逐步改善。

开源即万能？

前段时间，一个朋友突然找我，说有个项目需要能深入掌握MySQL源码的人，问我能不能接。我当时就坦诚回复：“这我真没这个能力。” 后来跟几位深耕数据库领域的行业大佬聊起这事，大家的共识很一致：想要真正吃透一个开源数据库的源码，远比想象中复杂。这绝不是简单 “读代码” 就能搞定的事，里面藏着好几个明显的能力层级，彼此之间的差距可能比外行人想的要大得多。 比如，最基础的是 “能看”—— 对着源码文件能顺下来大致的函数调用链路，知道某段逻辑在哪个模块里；再往上是 “看懂”—— 不仅能理清流程，还能理解设计意图，比如InnoDB的事务隔离机制是怎么通过锁和日志实现的，SQL解析器的语法树生成逻辑为什么要这么设计；更高一层是 “能改”——遇到具体问题时，知道在哪块源码动手，比如优化某个查询算子的执行效率，或者修复一个特定场景的死锁问题；而最顶尖的则是 “改得有效”——改动不仅能解决问题，还能兼顾性能、兼容性和稳定性，甚至能在原有架构上做合理扩展，比如为存储引擎新增一个适配业务的索引类型，同时不破坏底层的事务一致性。 这几层台阶，每往上走一步都需要对数据库的底层原理（比如存储引擎、事务机制、优化器逻辑）、工程实践（比如并发控制、内存管理）甚至硬件特性（比如IO调度、缓存策略）有更深的理解，绝非朝夕之功。由此可见想要完全理解一个复杂的开源项目不是那么简单的，这也让我想起了王总文章中的一段内容：

image.png

通过一些个人渠道，我了解到这事有可能是真实的，从信息来看是一个基于开源数据库的分布式数据库，如果真有类似的问题，到底是开源本来的问题，还是基于其研发过程中出现的问题，我把这些关键字甩进了AI，给了我下面这段话，仅供大家娱乐一下：

总结

本期我又吐槽了，希望大家喜欢。 老规矩，不知道写了些啥。