本文是浅谈软件架构设计实践之业务核心与配置分离的后续。

一则事故引发的思考

最近，一位同事和我分享了他们遇到的一则生产事故：

背景

他们有一个面向消费者的前端及若干后端，同时也有一个管理后台供运营人员配置营销活动参数

事故

某新活动上线后，消费者前端感受到延迟激增，不多时管理后台崩溃，活动中断

原因

营销活动前端开发人员误将管理后台的API当做营销活动后端的API使用，后者是有缓存保护的，而前者为了方便运营人员配置是没有缓存的

我们共同的看法是，这是一个低级失误，但通过性能测试应该是可以发现的。可惜的是，由于各种原因，这个性能测试并没有发生。如果性能测试的设计场景和实际生产场景不匹配或是性能测试覆盖不全呢，有没有一种架构设计上的防呆机制，即使漏掉了性能测试也能避免这样的低级失误呢？

或许反转业务运行域与配置域间的依赖是一种值得尝试的防呆机制

既然在项目中，已经实施了“业务运行域与配置域的分离”，那么说不定可以在此基础上再进一步，将两者间的业务运行域=>配置域反转为业务运行域<=配置域。

即由：

1. 业务运行域开放更新配置的API（Rest API或消息队列）
2. 配置域通过“发布”的方式将配置推送给业务运行域
3. 通过网络隔离，限制业务运行域对配置域的直接访问

通过这个依赖反转，我们可能还能收获两个有益的副作用：

1. 可能降低了安全风险。因为面向消费者的应用和面向内部运营的应用，一般会处在不同的网络分区中。面向消费者的应用由于需要对外开放，一般来说安全风险更高。通过这个依赖反转，切断了高风险分区向低风险分区的访问。
2. 可能进一步强化业务运行域与配置域的分离意识。因为如果由业务运行域开放更新配置的API，出于本位思考，其API会更贴合运行域的要求，更关注与What（我需要什么信息）而不是How（我如何管理这些信息）。这可能会使业务运行域的建模更干净可靠。

comments powered by Disqus