关于如何做好业务代码开放、扩展的技术架构设计和相关想法。接上次如何做扩展

相关机制总结

发布订阅机制的扩展
- 特点：
  - 简单明了，逻辑通过消息解耦，扩展方按需订阅，并做相关扩展
  - 一般用于非主体性修改，可有可无，扩展不影响主体逻辑（如：编辑体验）
- 缺点：
  - 原有业务代码本身需要做「事件化」改造，成本较高
基于生命周期的扩展
- 特点：
  - 规定明确的扩展时机，对特定的生命周期，扩展方可直接做非常强的干预
- 缺点：
  - 除固定的扩展时机外，无法对生命周期本身做灵活的扩展
基于协议的扩展
- 特点：
  - 约定协议，扩展方按协议来做相关实现，多用于继承实现、多环境的复用和扩展
- 缺点
  - 扩展方和主体方需要约定协议，扩展方按协议规定做实现，对主体方本身的干预能力较差
  - 干预方的插件实现，一般仅有单个实现，较少出现多个实现或多个插件一起用的情况

从以上方案中，可以总结出相关特点：

方案	改造成本	开放性（干预能力）	扩展性（灵活性）
发布订阅	高	中	高
生命周期扩展	中	高	低
协议扩展	高	低	高

开放&扩展的最佳实践

看到上述方案，看似干预能力和灵活性不可兼得，但其实是出于不同场景的目的考虑的。

如果从业务代码的技术架构出发，由于其快速迭代的特性，有着千奇百怪的开放、扩展需求，所以，对其都提出了较高的要求。

这里，都可以举一个业务实践中，对开放、扩展做得最好的一个设计，就是 servlet 的 filter 机制。

Filter 机制，是面向 http 协议的一套 request、response 的拦截机制：