知识卡片
事件驱动架构、MVC架构与黑板模式架构的脆弱性
内容
[[事件驱动风格]]架构的脆弱性根源是”失去掌控”:组件触发一个事件后,并不确定哪些组件会响应、以及它们的执行顺序,这意味着组件对系统整体行为的控制能力被削弱了;数据量大时事件间的参数传递效率成问题;多组件间的逻辑关系因异步交互变得复杂难以追踪;编程逻辑处理不当容易触发死循环;高并发事件处理虽然能提高CPU利用率,但也容易导致数据不正确、丢失数据等一致性问题;而且可响应的处理流程通常是固定编排好的,一旦操作不当就容易引发安全问题——这些问题共同指向一点:事件驱动用”发布者不需要知道订阅者是谁”换来了松耦合和高扩展性,但代价就是系统行为的可预测性和可控性大幅下降。[[MVC风格]]架构的脆弱性主要体现在两方面:一是缺少对调用者的安全验证机制,二是数据传输不够安全;具体不足还包括——严格分离模型、视图、控制器会增加结构复杂性并可能产生过多更新操作、降低效率(对简单界面尤其不划算);视图与控制器名义上分离但实际联系紧密,脱离控制器视图应用价值有限,这妨碍了两者的独立重用;视图对模型数据的访问依赖模型操作接口设计,可能需要多次调用才能拿到完整显示数据,对未变化数据的重复访问也会拖累性能——这些结构性不足正是MVC容易招致攻击的主要原因。黑板模式架构的脆弱性集中在”多知识源协作求解”这个核心机制本身:由于问题的解是通过控制机构中的调度程序挑选多个知识源逐步求出的,如果知识源选择不恰当就可能导致错误或有误差的结果,无法确保得到期望结果;求解过程需要不断修改黑板状态、多个知识源排队执行,效率比较低;而且不支持并行——知识源要先进调度队列排队,多个知识源共享黑板还需要同步,因为每次状态改变都可能影响下一次状态改变,这种强耦合的状态依赖天然排斥并行执行。
参考来源
- 位置:《软件架构理论与实践》第21章《软件架构脆弱性》"21.3.4 事件驱动架构"、"21.3.5 MVC架构"、"21.3.8 黑板模式架构"节(源文件:_epub-src/OEBPS/text00178.html)
- 结论依据:原文分别说明事件驱动架构"组件削弱了自身对系统的控制能力"、MVC架构"缺少对调用者进行安全验证的方式,二是数据传输不够安全"、黑板模式"如果知识源选择得不够恰当,可能会导致错误或者有误差的结果",直接支撑本卡片对三种架构脆弱性机制的概括。
- 原始内容:一个组件触发事件时,并不能确定响应该事件的其他组件及各组件的执行顺序……视图与控制器是相互分离但确实联系紧密的部件,没有控制器的存在,视图应用是很有限的……多个知识源共享黑板需要同步,因为它们通过黑板进行通信,每个状态的改变可能会影响下一个状态的改变。