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

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

问题见解

总所周知线上项目的代码,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关于代码容灾能力的浅析见解

版权声明:玥玥 发表于 2021-03-11 11:55:40。
转载请注明:关于代码容灾能力的浅析见解 | 女黑客导航