模块化单体比普通单体更复杂 - Oliver


下图来自于Redhat的比较微服务的分布式事务模式
Y轴是可扩展性、可伸缩性
X轴式一致性,从强一致性到最终一致性
红色箭头线节点分别是:单体模块、两段事务、Saga编曲(无中央协调点)、Saga编舞(有协调点)、并行管道

模块化单体Modulith的设计是:一个事务跨越所有模块,这是一个有缺陷/错误的假设。在模块化单体Modulith中,事务不因此能脱离逻辑模块。你就又回到了一个纠缠不清的模块化单体Monolith。

但是在实践中,某些框架,如OSGI,和基于Apache Camel的模块,使得编制一个模块和其他模块的协调交易事务变得非常容易。
不过,这种模块之间的协调步骤暗示着模块必须严格的按部就班的执行,其假设前提是:总是预想只有其中一个参与者出了问题,而其他参与者一切都很完美。(万一这个假设前提不满足,后面的逻辑基本全部被推翻,例如实际运行中,不可能只是一个事务参与者出现问题,有可能两三个同时出现问题,虽然概率很低。)

这种共享事务是模块化单体的一个共同特征,也被认为是一大优势,您不必像在微服务场景中那样寻找复杂的解决方案。但是它更是一种很容易让你陷进去的陷阱。
在这个事务共享链中,任何一个切入事务链的功能都可能会导致你的主要功能回滚。也就是说,一个模块的隔离度比它本来的要低。这已经破坏了模块本身的含义和定义。
毫无疑问,这是否是你想要的?以及你是否想为它支付额外的复杂性?这是一个问题。

此外,由于复杂性,模块化单体比 "经典 "单体还要糟糕。