您的位置:首页 > 汽车 > 时评 > M功能-支付平台(三)

M功能-支付平台(三)

2024/12/26 10:34:00 来源:https://blog.csdn.net/w172087242/article/details/139198929  浏览:    关键词:M功能-支付平台(三)

target:离开柬埔寨倒计时-221day

前言

今天周六,但是在柬埔寨还是工作日,想着国内的朋友开始休周末就羡慕呀,记不清在这边过了多少个周六了,多到我已经习惯了。而且今天技术部还停电了,真的是热的受不了呀,我感觉我写完这篇博客汗水可能会浸湿衣服呀。

接手M功能时的窘迫

2023年4月初,具体几号已经记不得了

boss:M功能还是要上演示版的,这个上了我们才好回去

我: 计划什么时候演示呢?

boss:20号左右吧,大概还有2周时间

我:…

boss:资源这边我看能不能帮你找到,你大概需要多少人呢?

我:两周时间的话,熟悉M功能的后端人员至少要3个吧,如果不熟悉的那至少要5个,前端还需要2个

boss:后端我去帮你找找看,前端你可以再想想办法

我:可以,前端我找个兼职的来帮我吧

boss:可以呀,先评估功能再报个价吧

我:好的

@@@@@@@@@@@@@@@@@@@@@ 2小时后 @@@@@@@@@@@@@@@@@@@@@

boss:后端我帮你找了4个人,他们可都是高级或架构哟

我:好的,那我先跟他们聊聊M业务吧,20号的时间我只能说尽力

boss:20号还是必须要完成的,难道你不想早点回国吗

我(内心想):我当然想早点回国呀,谁愿意呆在这鸟不拉屎的地方呀,但那么多功能,我还不知道这几个后端好不好用呢

我:想早点回呀,我先跟他们(4个后端)讨论一下吧,再确认一下,他们做我的事情的时候不会被其他事情干扰吧

boss:不会,放心吧!

实际上不仅会被干扰,还TM最后放弃让我一个人弄。

人虽然有了,但是需要改变的功能还是比较恶心的:

  • 虽然我有全套的M功能代码,但是为了贴合支付平台,需要改造的地方还是很多的,特别是用户底层账户和平台币种管理
  • 之前我负责做的M功能主要为APP和WEB,这次的改动需要支撑H5嵌入支付APP中
  • 最大的一个改造就是M功能要做成saas,但是对不同公司主体又只需要做数据隔离,带宽、服务器资源、数据库都是集成在一起,也就是不同主体的数据是用逻辑标志来区分的
  • saas对撮合引擎的影响:我之前设计的M的撮合引擎是基于交易对建立内存的,现在不同公司可以建立相同交易对,如A公司和B公司都开放交易对USD/CNY,要保证A公司的订单不能和B公司订单进行成交,那么就需要在之前的数据内存之上再做一层逻辑隔离

首次和金边这边的技术合作

当时boss给我的时间仅仅2周,并且这个功能做完,进入演示阶段我就可以回国一趟,所以当时虽然非常痛苦,但想到可以回国还是咬牙在坚持呀

金边后端技术

我们做的这个系统是这边一个银行的拓展支付软件,所以我们的办公场地一直是在银行的技术部,因为我这边做M功能需要人力资源,所以最终我的boss协调了4个银行技术后端给我使用,人虽然有了,但是他们对M功能一无所知,而且还有一个问题就是不得不说的题外话了,那就是直接到柬埔寨这边来的技术能力真的一言难尽。

前端资源

金边这边虽然给了我后端资源,但是我还缺少前端资源,于是我又找到之前跟我一起做M功能的前端同事,让他以兼职的形式来帮我做H5和简单版的后台管理系统,他同意后我这边的基础人员相当于就就位了。

克服异地异点调试

因为后端是金边这边的技术在做,前端是国内前同事在做,而国内前同事又每天下班回家之后才有时间,而我又是其中的唯一枢纽,并且我也需要确保他们提供的接口质量,所以前后端调试的事情我一直都在跟进,所有调试中遇到的问题我也会记录以及处理。特别是里M功能deadline的最后几天,这边的后端直接奔溃放弃,只能我一个人处理,我突然感慨,国内说的卷真的太对了,我TM都卷到柬埔寨来了。所以客服异地异点调试的方式就是我每天加班到很晚很晚,当时第一次萌生了离职的想法,这个在我写内心戏的时候肯定会重点描述几次萌生离职想法以及为什么内心如何建设、最后留下来的。

这里可以提一嘴我们来之后,银行这边技术的变化,还记得我们刚到银行技术部办公的时候,他们都是每天到点就下班,每天到6点以后,整层楼就只剩下我们来这边的几个人,随着时间的推移,银行的技术也开始了加班,也是常常干到很晚。扯远了,这些具体内容在生活篇来记录吧。

M功能撮合流程

M功能最主要的就是下单、撤单、撮合,而撮合流程相对复杂一点

在这里插入图片描述

为什么锁使用mysql

首先锁是用交易对来作为关键key的,其次是撮合是一个持续的过程,那就意味着这个锁在程序没有出现异常时要一直存在的

最开始的时候我们的锁使用的是redisson,因为redisson的锁写好了续命逻辑,可以一直保持着锁的存在,但是这个续命逻辑有一个致命的问题,在普通场景可能不容易出现,但是在撮合这里超长时间持有锁就可能会出现,因为redisson的锁续命机制是一个递归的过程,也就是说当前续命成功,才会有下一次续命的机会,而如果正好在锁续命的时候出现网络抖动或者其他一些异常问题,那么续命任务就会终止,那么那个锁到期就会自动释放了

后面会抽时间补技术的文章,就包括这里的redisson分布式锁续命问题,关于分布式锁就不单独写了,因为网上一搜一大片

综上所述,我最后还是写了个mysql的锁来支持撮合,当时时间也很仓促,可能还能更优化,但是先放上去用着再说,主要是要保证程序不出问题,这个解锁其实还有一个逻辑,就是撮合引擎重启的时候会去释放掉所有该进程ip上的所有锁,这个逻辑在k8s动态ip下就非常的不友好,当然还是有另外的解决方案

在这里插入图片描述

后记

今天公司是真的太热了,我能坚持写完这篇文章也是不容易呀,外面还有每天打“沙滩排球”的柬埔寨本地人,真的佩服他们,有时候也感觉他们活的很快乐

在这里插入图片描述

加油吧littlehow

金边时间:2024-05-25 15:21

北京时间:2024-05-25 16:21

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com