本文是 浅谈软件架构设计实践之业务核心与配置分离 的后续。
最近,一位同事和我分享了他们遇到的一则生产事故:
他们有一个面向消费者的前端及若干后端,同时也有一个管理后台供运营人员配置营销活动参数
某新活动上线后,消费者前端感受到延迟激增,不多时管理后台崩溃,活动中断
营销活动前端开发人员误将管理后台的API当做营销活动后端的API使用,后者是有缓存保护的,而前者为了方便运营人员配置是没有缓存的
我们共同的看法是,这是一个低级失误,但通过性能测试应该是可以发现的。可惜的是,由于各种原因,这个性能测试并没有发生。如果性能测试的设计场景和实际生产场景不匹配或是性能测试覆盖不全呢,有没有一种架构设计上的防呆机制,即使漏掉了性能测试也能避免这样的低级失误呢?
既然在项目中,已经实施了“业务运行域与配置域的分离”,那么说不定可以在此基础上再进一步,将两者间的 业务运行域=>配置域
反转为 业务运行域<=配置域
。
即由:
通过这个依赖反转,我们可能还能收获两个有益的副作用: