进行系统设计时，这4点一定要注意！_系统业务设计安全注意事项(1)

本文链接：https://blog.csdn.net/2401_84715732/article/details/138830852

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

服务的健壮性跟系统设计有很大关系，前期设计时考虑多一些处理逻辑，可以避免后期出现问题带来的损失以及修复问题的成本。在前期讨论设计方案时测试同学也需要参与，而不只是埋头设计用例和测试，开发同学可能因为思维局限或者思考疲劳，不一定能想到异常处理，测试同学可以利用自身优势多给一些建议。如果等测试评审时再跟开发同学强调这些设计，或者是到测试中才发现这类问题，可能就有点迟了，因为越到后期改动代码的影响范围越大，改动的风险也越高。

1 补偿机制

补偿机制业务中有一个功能，用户提交申请后要将数据回调给某个第二方系统或者是第三方系统，这时候你要考虑，如果请求失败了怎么办。重要事件的处理要记录请求情况，特别是异步请求，虽然不影响主流程，但是如果失败了又没有记录就不方便回溯，想重新发起请求也没有入口。不管是通过HTTP通信还是通过MQ进行通信，都是可以记录请求状态的：前一步成功后将状态置为待推送，推送前置为推送中（为什么先置为推送中，因为有可能结果更快回来），推送后再置为成功/失败，然后针对待推送、推送失败的记录要做定时任务来进行重试。

2 功能特性开关

功能特性开关假设原本交互逻辑是A直接请求B系统，后来新增了C系统作为中间处理系统，A不直接请求B了，或者是原本A请求B的方式由MQ改成了HTTP，接到这样的需求要第一时间想到做开关，即某个配置确定了业务是走方式1还是方式2的逻辑。对旧功能的大逻辑修改最好做特性开关，新功能要能兼容开关的两种方式都能正常运行。上线后，当有需求时再开启使用，功能下架时也可以直接将开关关闭，最重要的是，如果上线后出现问题不需要回滚代码，直接将开关关闭即可。这样出现问题后改动的成本和影响范围是最小的，修复问题花费的时间也是最少的。

3 请求内部系统失败

请求内部系统失败如果外部请求进来网关时，网关要先请求内部系统A，然后处理完再返回最终结果，比如外部发起注册请求，而网关要先请求信用系统判断用户资质，这时候要考虑请求信用系统失败的处理。如果将请求失败和信用系统返回失败一样处理，返回拒绝的结果给外部系统，那是不合理的，因为这属于内部系统的错误，并不是业务处理的结果。这时候应该要返回请求失败给外部系统，让外部系统自己重新发起请求进行重试。从系统的角度说，请求A系统时失败，相当于并没有进行处理，那么返回失败十分合理；从业务的角度说，虽然是我们自己的服务挂了，但是我们不能就这样把用户拒绝，我们都希望做到收益最大化，那么最好的方式当然是能把用户留住，而不是直接就把用户拒绝。