"一个框架搞定两种不同需求"的一劳永逸倾向，经常被证明是错的

Lambda架构衍生出Kappa架构、Spark既能做流处理又能自然扩展到批处理这些技术演进，共同引出一个值得警惕的架构设计心理倾向：工程师普遍偏爱”用一个统一的框架/系统同时搞定两种性质不同的需求”，追求这种大而全、一劳永逸的设计，因为它看起来更优雅、维护成本似乎更低。但现实经验反复表明，这种追求往往会付出代价，甚至最终被证明是错误的方向——Lambda架构最初正是试图用”批处理+实时处理+合并”这套统一框架去同时满足离线全量计算和实时增量计算两类需求，结果却在实践中暴露出双倍算法实现、跨系统一致性维护这些切实的成本，逼着社区又反过来去找Kappa架构这类新的统一化方案来解决Lambda自己制造的问题。这提示了一条值得在做架构决策时反复自我提醒的原则：当面对”能不能用一套方案同时覆盖两类看起来相关但实际诉求不同的需求”这个诱人的想法时，不要被”统一、简洁”的表面吸引力直接说服，而要认真审视这两类需求在底层假设、性能特性、演进节奏上到底有多大差异——如果差异足够大，强行用一套方案覆盖，往往意味着要么某一类需求被迫做出妥协，要么这套”统一方案”本身的复杂度会因为要兼顾两头而急剧膨胀，反而比维护两套各自简单、专注的方案付出更大的整体代价。