关于代码容灾能力的浅析见解

问题见解

总所周知线上项目的代码，bug肯定是会存在的，想要完全健全的代码肯定是不可能的，目前了解大企业都有一套推送机制，但是实际都是小作坊代码懂得都懂，这里主要针对涉及money部分做下见解。

使用场景

1.类金融系统中转账汇款的操作(包含背书)
业务场景

	1)流程图示例:

这里的业务难道在于实际业务的处理，因为涉及金额较大，且业务复杂，真就存在公司前辈写错的实例，所辛客户好说话也是公司老人，成功自离跑路，为了避免这情况，就考虑了容灾机制，本次就容灾做下方案说明：
因票交所，cfca，金蝶只管金额和安全，不管实际的业务部分，故要对每一次操作进行留痕，并重做了crm，代码就不贴了，其实就是对金额强行限额操作，在基础的签发人背书人的rcba基础上添加金额权限，filter对涉及到money的接口(api)做操作，锁肯定用的是msql Inodb的行级锁，金额小软key就行，金额大就要软key硬key一起上，并且用cfca接口推送短信or邮件(smtp)至金额审批人，确保到账金额的准确，单据分为加急和普通单，区别在于通知手段不一样毕竟接口按次收费,这可以规避代码写错导致的金额错误问题。
2.线上商城红包及卷的发放

• 业务场景

   1)流程图示例:
  

  
  这里的苦活累活全在服务端，这里要说业务点就有点深了，本次就容灾做下方案说明：

1.Maven白嫖Junit.jar,使用@Test编写单测，一般使用场景Swagger够用了，但是涉及到money的东西，需要Mock来确保链路准确无误，这部分需要写单测自测(自救)，具体单测教程查看别的日志

• 知识点补充:

   Mock
  

  Mock:Mockito-core.jar,Junit的好兄弟，实际使用建议Junit、Mock、H2一起搭配。这能够模拟各种请求数据，而且能够避免类和类之间的依赖关系，当第三方服务挂掉或不支持测试环境时可以自造数据，说白了就是集中重心只测试核心业务链路避免外部类的干扰。写法如下：
  

  H2

  H2:h2-x（版本）.jar，嵌入式数据库，持久化可开可关，关了持久化就是给单测使用，避免数据库存在脏数据每一次执行完用例能够恢复初始状态，数据都没了肯定初始化了,打开了持久化可以做缓存，类似redis，但是和redis功能比起来有区别就拿典型的雪崩和穿透举例，毕竟h2就一个jar包，容灾能力有限，但是优点也是maven一下这jar包就能直接用，满足热开发的实际需求，配置写法如下:
  

2.drm信息推送机制,说白了就是写两套代码方案，一套当日常使用方案，一套当日常使用出现问题时的版本来做切换，甚至可以做到当某个连续的时间点，项目连续报错时自动切换版本，drm机制的好处在于容灾的稳定性，一般代码发生问题都是进行版本回滚然后发布后者紧急维护，这样做体验怕是不可能好,关于drm信息推送机制请看此流程图: