微内核、管道-过滤器与微服务架构的脆弱性

三种以”拆分/解耦”为核心思路的架构，脆弱性都出在拆分之后的协调代价上。微内核架构（可参照[[平台/插件风格与层次消息总线风格]]理解其结构）的核心态只保留最基本的系统操作，插件化裁剪掉不需要的特性（如远程访问、消息、Cache功能）以换取性能，但这种拆分带来两个问题：一是难以进行良好的整体优化——内核以外的外部程序彼此独立运行，系统缺少一个可以统筹全局的视角；二是进程间通信开销比单一内核系统大得多，把系统拆成小功能块虽然降低了设计难度、便于维护修改，但通信损失是这种拆分方式绕不开的代价，好在当前硬件条件下微内核在效率上的损失通常小于其在结构上获得的收益。[[管道-过滤器风格]]架构的脆弱性有两点，且都源于”过滤器职责单一、通过输入输出衔接”这个结构本身：一是安全性风险——每个过滤器的输入输出是独立且低耦合的，但正因为如此，攻击者只要摸清某个过滤器的输入输出格式，就有可能反推出这个过滤器的具体功能，这是一种通过接口暴露反推内部实现的攻击面；二是稳定性风险——一个过滤器的输出直接构成下一个过滤器的输入，一旦某个过滤器出错，错误会顺着这条链条被逐级放大，而不会被限制在局部。微服务架构的脆弱性来自”用众多独立服务换取独立部署能力”这个选择本身：开发人员必须直接面对分布式系统固有的复杂性；服务之间的通信机制需要专门设计和编码来处理消息传递过慢或服务不可用这类局部失效场景，这些问题在单体架构里根本不存在；生产环境里要同时管理多个独立部署的服务实例，这种服务管理的复杂性要求开发团队具备全局统筹的能力——微服务把”单点故障”换成了”局部失效的常态化处理成本”，这个代价必须被显式设计而不能忽略。