当前位置：首页 > news >正文

做网站有用nodejs广州卓天跨境电商网站

news 2025/12/27 18:37:51

做网站有用nodejs,广州卓天跨境电商网站,阿里邮箱企业版登录入口,wordpress重新安装博客怎么搬家架构设计图整个支付链路上的功能支付系统应该有#xff1a;账户管理、渠道管理、支付管理、对账管理、清算管理、结算管理一笔支付订单#xff0c;在支付系统侧就是要记录清楚#xff0c;谁发起的、对哪个商品进行支付、通过哪个渠道支付、支付时间、支付结果等… 架构设计图整个支付链路上的功能支付系统应该有账户管理、渠道管理、支付管理、对账管理、清算管理、结算管理一笔支付订单在支付系统侧就是要记录清楚谁发起的、对哪个商品进行支付、通过哪个渠道支付、支付时间、支付结果等消金系统分层架构展示 SS IQP 流程APS TDL TDC TC CORE FA MM RMS/IRISK/RMFP 核心AMS CIS 基础SSP OPR ODX PMS 全局域划分架构交互层业务串联层核心能力层公共服务层数据存储层消金两大场景提现消费需要清楚账户系统的额度的变更也就是通过中间的过程系统TDL/TDC消金侧告知银行你可以对该笔请求进行放款此时银行才去真正的执行给客户打款金钱流转动作额度发起方一定是银行这个都不用想一切放款行为都是银行触发的消金前置流程是控制用户有没有用这笔钱的资格后置的流程是为了把银行的钱和消金的账户做一个绑定。前置流程就是TDL调AMS看额度够不够用后置流程就是银行本次给用户打了多少钱消金的账户额度对应的是要加还是减多少额度核算系统要生成多少钱的账单从这个角度来看AMS和风控系统都一样都只是前置流程中的一个校验AMS是检验额度够不够风控系统是校验该笔放款是否合规信贷三步贷前主要是用户授信、实名注册的一个过程这个过程顺利通过后用户看到自己的授信额度才到后面的动支行为贷中就是控制用户当前能不能使用额度也就是提现/交易的整个过程贷后对账、账单、还款业务流程定价授信对账消费二维码展示用户打开消金app支付二维码界面前端系统发起生成二维码的请求请求给到TDCTDC将二类户卡号等用户信息等给到银行银行返回字符串二维码TDC侧将字符串专为真正的二维码从而给到前端展示原来最开始没进行域划分之前功能很混乱所有当时和前端展示有点沾边的功能都丢在SS系统中的比如支付二维码的生成扫码支付商户扫码枪扫描客户的消金app二维码支付页面从而发起对银行的扣款请求银行将扣款请求给到消金的支付网关TCTC给到TDCTDC走风控、额度扣减那套逻辑额度扣减成功后返回TCTC将SUCCESS告知银行此时银行才从消金在上海银行的公户中扣款打给商家的银行卡商家扫描客户的支付二维码时就会客户信息、消费金额信息商家信息一起给到银行疑问上海银行怎么知道每个商户的银行卡号因为是商家拿着自己在支付宝注册过的扫码枪扫描的用户从上海银行生成的二维码商家肯定是提前在支付宝上注册填写过收款卡号的或者说直接收到支付宝的余额中去如果银行接收到了消金侧返回的SUCCESS但是扣款失败或者接收消金侧响应超时就会实时发起冲正提现提现一定是银行管控整个流程额度扣减都是后置处理都是银行先把钱放出去后银行才通知消金侧扣减额度的用户能不能提取到这笔钱、能提取到多少钱这个是和TDL和消金有关系的而真金白银放款的流程其实和TDL关系不大TDL只是一个结果的记录比如银行把钱放出去了放了多少钱TDL调用AMS扣一下额度提现流程一定要分清楚放款到底是以文件形式还是文件形式就是说别人放别人的别人放成功后再用文件通知你你这边是需要有额度调整的。此时就说明管控方是在别人那边如果消金侧主动调用银行的打款接口则管控方就是消金自己自有业务占用是放款中的一个过程是一个中间状态表示该笔额度被占住了不能用于其他场景了是AMS为了保证同一时间这笔额度只能用在同一个地方防止额度用超银行侧实际放款成功或失败才通知AMS这边动用额度还是恢复额度占用用户输入借款金额发起请求到银行银行调占用接口到TDLTDL内调风控通过后调AMS额度占用额度中间态占用成功后通知银行允许该笔请求提现从而银行给用户的提现卡号内打钱动用银行调用消金的动用接口TDL通知AMS扣额度通知core记账单通知大数据等说是占用动用两个接口实际上在数据库中只对应了提现主表里状态节点的9个状态扭转助贷接入了平安普惠、支付宝、度小满、字节等占用比如客户在度小满发起借款请求通过度小满的流控某一次流控走到了消金侧进入TDL开始风控、额度占用成功后回调度小满的放款结果通知接收接口告知度小满我消金侧认可你这笔请求你可以开始后续给客户打款的流程了。但是度小满的动用文件第二天才到为了到第二天这期间不让用户额度用超消金需要控制额度所以引入了额度占用的逻辑如果是平安普惠的优质资产助贷则是TDL先调AMS占用占用成功后TDL调用支付渠道网关TCTC又调平安付开始给客户打钱。TC打钱成功后回调通知TDL放款成功然后TDL调AMS动用如果没有占用而是直接动用2w那么客户就会看到数据不一致的中间态用户查看额度少了2w但是用户银行卡2w又还没有到账美团要求10分钟返回度小满要求2个小时返回借呗要求2秒所以借呗是单独一套流程没有走MQ 如果是消金侧来控制打钱则消金侧产出对账文件如果是外部侧比如度小满控制打钱则度小满来产出对账文件消金侧来解析结账文件对账外部调消金的uwg转发网关进行统一加解密、金额单位转换结束后调用支付渠道网关TC开始给客户打钱动用 T1日动用文件通知来扣额度之类的常用比较好追溯T日调接口注意动用文件与银行的对账文件的区别消金内部系统公共服务综合查询平台 IQP 主要是运营人员使用的共享支持平台SSP 单证合成电子签名/印章微服务网关openApi 助贷时支付宝调用消金的系统时首先就得通过微服务网关业务网关 SS 统一外网的各种各样的参数风格转换成消金内部统一的参数比如消金内部统一的成功响应码是0000失败是9999 这个系统慢慢的被分解被微服务网关openApi和各个业务系统瓜分了产品域产品管理系统PMS 主要功能产品配置、定价配置每个用户针对每个产品都有一个唯一的userId公司内部的不同产品不同系统之间通用的就是userId 定价查询接口返回的是一个很大的json由于在AMS侧需要比较定价是否超话而直接比较大json不太方便所以每个大json都会带一个摘要比如md5值每次只用比较md5值就知道该定价信息是否变化过营销域营销管理系统 MM 曾经做过一个宜家消费满800返80的活动还有全家消费30返回10块不过都有名额限制需要去抢名额后来这个抢名额的逻辑被我放在了异步流程中了异步流程中有调MM拿中奖名额有发MQ给Core通知放款电商平台下的营销系统主要是发优惠券搞促销活动千万级别的全量用户发券如果想争取在一两个小时内发完就需要用分布式任务调度平台xxl-job配合rocketmq来实现分片执行削峰填谷支付域简单理解就是真正和外界交互进行打钱的系统交易渠道网关 TC 定位报盘回盘辅助对账接一个渠道就是一个xxx-getway 渠道建行工行平安普惠和建行等直连成本低其他的有手续费。就是从其他的快捷支付啥的有手续费成本高了后来就直接和银行直连了省钱就相当于抢了支付宝/微信的一部分生意可以将建行、工行的银行卡绑定在平安消金的app上然后通过平安消金的app来完成二维码支付类似于微信支付的余额界面财务域财务系统 FA 大数据域大数据系统 ODX 可以理解成为数据中台功能就是负责拉取TDC这边的支付数据然后大屏幕准实时的展示每小时的交易笔数交易额度的变化情情况风控域风控系统 IRISK 二类户交易流程上每笔交易流程都会调用IRISK来决定是否放行该笔交易 irisk主要是看是不是常用登陆地之类的监控风控管理系统 RMS 风控规则客户评级评分有客户的评级信息一开始是ABCDE五个评级每个评级的用户对应享受到的放款额度放款利率都是不一样的。后来重构过一次重构成L1到L1010个等级了授信出额调额根据后台分析如果准备给用户提升额度比如提升2w但是提升额度这2w只能用于消费那么就去调用AMS的调额接口AMS就把小橙花二级账户的授信额度加2w并同时把三级消费资金账户的可用额度也加2w但是三级提现资金账户的可用额度额度不变用户征信、是否逾期等的一些风控规则风控系统 RMFP 会员域客户信息系统 CIS 负责登陆、注册、注销、实名认证等的逻辑串联客户号cust_no 实名服务比如身份证信息、手机号信息家庭住址等卡服务一个人可能会在消金App上绑定多张银行卡后面有绑建行的卡直接使用消金app扫码支付不用通过支付宝微信就可以完成扫码支付存用户身份信息比如身份证、地址之类的。存消金内部自然人唯一编号 userId供消金内部所有系统共用方便问题追溯存手机号比如说后面办什么促销活动就可以通过手机号给用户发通知短信从技术的角度而言所有的核心业务未必就适合于放在一个系统中处理如贷款的账务处理和贷款的授信、审批以及贷后管理就不适合放在一个系统中因为账务处理力求稳定和高效而贷款的流程管理力求灵活多变不同的功能需求更适合在不同的系统中处理。这也说明核心业务系统未必就是一个系统而可能是一个系统群。银行核心系统设计目标以客户为中心的设计集中的客户信息能够对客户层次的所有账目和交易进行汇总。一些银行目前使用的核心业务系统正从传统的以账户为中心向以客户为中心转变表现在客户的基础信息资料都必须在核心系统做维护(这里说的基础信息资料指能为多个系统所公用的信息如名称、地址、身份证号码、组织机构代码等)某些系统专用的信息可以在专业的业务系统存储。分散在各个外围业务系统的客户基础信息资料均需以核心系统客户资料为准核心系统统一为客户分配客户号各业务系统对客户的引用均以核心系统客户号为准。尽量避免一户多号的情况以客户号为线索可以查询出该客户在本行的存款、贷款、结算、理财产品购买等业务情况。针对不同的客户提供有针对性的服务对不同的细分客户群和层次在服务档次和服务定价上有所区别。好的核心系统应该能帮助用户对客户进行细分根据客户对本行的综合贡献度以及信用等级提供相应的服务使银行有能力把更多的资源投入能给本行带来更多利润的客户上客户号cust_no全局唯一user_id是一个产品一个多个user_id对应同一个cust_no 进件域进件系统 APS 负责贷前鉴权鉴别是否是本人流程如下生成流水、客户信息跳转到第三方页面客户输入卡号、手机号等鉴权完成返回信息给我们负责授信、出额、开户流程这整个流程是以APS作为主导来串流程二类户交易是AMS/TDC来串流程授信业务分为公司授信业务对公司法人国际贸易授信业务个人授信业务对个人自然人房类、汽车类、经营类、消费类、教育类等授信几个阶段调查、审查、审批、放款、贷后工作把客户的所有情况了解清楚后了解了客户的征信情况评估好所有的风险出一份调查报告放款是资金出银行的最后一道关口信贷审批和审批授权信贷审批是指银行或金融机构对借款人提出的贷款申请进行审查、评估并决定是否批准贷款的过程。这包括了对借款人的信用状况、还款能力、贷款用途、担保措施等多方面的综合考量。审批授权是指银行或金融机构在办理信贷业务时对各级管理人员和业务经办人员授予一定范围内的信贷业务审批权限。这种授权是基于职责分工和内部控制的需要旨在明确各岗位的权限范围、审批程序和相应责任。授信审批大致可分为集中管理模式、分级管理模式和垂直管理模式三种模式。用户进来注册授信时请求通过前端打到SS再打到APS然后开始人脸之类的最后是前面的很多校验都通过后才到AMS来调开户接口调AMS来开户时如果是新用户那就是3层账户表一起开授信开户一定是针对产品开户的不同的产品开不同的二级产品账户账户域账户管理系统 AMS 账户系统的5大核心功能额度账户状态授信开户定价发票 AMS三大业务闭环账户开户、销户账户状态冻结、解冻账户额度扣减、恢复域划分前 AMS很庞大AMS的业务是不清晰的说白了就是不够“瘦”负责交易、账单、还款对账整个公司内部各系统职责边界都划分的不清不楚造成了很多因边界问题而起的矛盾域划分后 AMS作为账户域只作为核心能力层不负责流程的串联不负责是否应该额度变更包括额度扣减、额度恢复的判断逻辑所有的额度变更的发起都由外部系统发生。比如支付就由TDC向AMS发起扣减额度请求还款就由CORE向AMS发生账户还款请求 AMS账户额度管控模块只提供额度变更接口给别的系统调至于是什么业务导致的额度变更AMS就不去关心了。AMS账户状态管控模块也是一样因为什么原因导致的账户冻结解冻AMS都不关心一切都由外部触发消费定价更新定时任务定时从PMS刷新每个人的定价因为如果PMS侧定价更新以后AMS侧每个人的定价当月不能变化需要等到下个月才能更新重构交易的过程重构前交易流程结构混乱最关键的问题是串交易流程的核心逻辑不在一个类中而是一个类串着下一个类这样代码结构不直观三级账户表结构一级账户表主账户表AMS侧对应的主账户号是account_no客户信息系统那边对应是cust_no 二级账户表授信账户表也叫产品账户表记录小橙花等不同的产品AMS侧对应的授信账户号是pro_credit_no字段全公司内部通用的则是每个产品对应不同的user_id字段三级账户表当前现状是有两张消费额度管理表提现额度管理表有一个核心字段已用额度消费时是增加已用额度还款时是降低已用额度实际情况三级资金账户表不需要两张表只需要一张表然后弄一个额度类型字段提现和消费各对应一个额度类型就好用一张三级资金账户表提供一个amt_type额度类型字段amt_type是CON消费资金账户、另一个amt_type是CASH提现、amt_type是ALL资金总账户额度也就是产品账户额度这样二级产品账户账户中就可以不放产品额度字段了三级账户表AMS侧每个三级账户对应唯一的资金账户号loan_acct_no额度类型amt_type总额度total_amt已用额度used_amt占用额度occupied_amt账户乐观锁版本号data_version 二级账户表可能有以下三种典型情况小橙花有10w的产品授信额度其中消费和提现各5w对应在三级资金账户表下同一个小橙花产品下有两个资金账户一个amt_type是CON消费总额度是5w、另一个amt_type是CASH提现总额度也是5w 理想情况就是消费和提现各种独立出额互相不耦合度小满属于助贷有5w的产品授信额度且只能用于提现5w对应在三级资金账户表下同一个度小满产品下就只有一个资金账户amt_type是CASH提现总额度也是5w 借呗属于助贷有2w的产品授信额度且只能用于提现2w对应在三级资金账户表下同一个借呗产品下就只有一个资金账户amt_type是CASH提现总额度也是2w 还有一个单笔单批健康的情况下就是额度分开管理也就是数据分开管理单一职责至于业务怎么用这些数据业务需要用这些数据时会加上哪些限制条件这个是业务的事情和数据存储的本身一定要区分开不要揉在一起理想的情况是消费和提现各种独立出额各自都有5w额度互相不耦合使用消费时就只动三级表中消费账户哪条记录使用提现时就只动三级表中提现账户的那条记录产品下不同的额度分开管理互不影响这样我们就只需要给三级表加一个账户乐观锁版本号data_version字段来保证某一条三级账户表记录自身的安全性从而实现同一时刻针对这同一天三级账户表记录只能有一笔额度变更流程。额度变更流程就包括对同一账户因为重复请求等原因而同时发起了两次提现/消费或者对某个三级账户进行提现/消费时另外有一个流程在对这同一个三级账户记录进行还款而当前消金小橙花比如如果有10w的产品授信额度其中消费消费10w提现5w对应在三级资金账户表下同一个小橙花产品下有两个资金账户一个amt_type是CON消费总额度是10w、另一个amt_type是CASH提现总额度也是5w 此时就已经把业务和数据揉在一起了根据消金自己定的消费和提现占比1比0.5的业务需求导致了上面的数据存储方式导致用户消费6w后还会影响到提现的额度只有4w了但用户一直没有提现过而当前还能最多提现却从5w变成了4w但是三级提现账户表中的授信额度还是5w 这个时候就需要额度引擎上场了额度引擎是公司业务规则的一个包装因为现在消金是把业务和数据揉在一起的大量消费可能会影响提现额度为了避免对小橙花的三级消费账户消费的同时有另一个线程对该用户的三级提现账户进行提现超出该用户小橙花产品的授信总额度所以无论是小橙花提现还是小橙花消费时都需要先拿一把以二级产品授信账户号为key的分布式锁。这都是因为业务的原因导致了需要这些复杂的逻辑实际上就应该把提现和消费额度分开两者之间互不影响只需要三级表各自的版本号乐观锁来保证各自数据的安全即可单笔单批授信等于动支附加额度、临时额度所有临时额度、附加额度、红包额度都用单独的附加额度管理表来保存区分不同的额度用途字段附加额度管理表也有起止有效期字段这张表相当于另一张三级资金账户表既然是三级资金账户表一定是要依附于某一个产品下的比如我们当前的实现是依附于小橙花产品下的扣额度时就要在where条件中既判断额度用途又判断额度有效期等条件都满足时才允许扣额度每个用户针对每个产品都有一个唯一的userId公司内部的不同产品不同系统之间通用的就是userId。比如如果RMS根据一些风控规则需要对某个客户的小橙花产品额度进行调额就需要拿着该用户的小橙花userId来AMS修改该用户对应的二级账户的授信额度同时还会去修改三级账户表的现金额度字段值吗按照业务情况需要有额度变动的明细表的。我举的例子搞分布式也就明细表加个状态字段而已账户与额度的关系账户讨论状态额度讨论有效期这两个概念一定要区分开账户被冻结了其实额度是没有被冻结的这是两个概念。也可能是额度有效期过了但是账户状态是正常的。如果额度过期后想让账户冻结也要靠定时任务去刷正常开的小橙花二级产品账户对应的额度也是有有效期的如果过了有效期则需要调用AMS的账户激活接口来更新小橙花产品额度的有效期账户状态管控身份证过期可能会导致账户冻结、风控系统检测到用户有高危行为也会来AMS调用账户冻结接口账户状态管控一定是需要的因为消金需要控制哪些用户能用钱哪些用户不能用钱账户模型三层表每层都有一个账户状态字段从而精细化的控制每一层的账户状态账户额度管控额度讨论有效期一般情况下循环额度的有效期都是控制产品额度的有效期所以在二级产品表放有效期字段一般不太会控制到三级资金额度的有效期的粒度如果只过期提现资金账户额度而不过期消费资金账户那么就需要在三级资金账户中加入额度有效期字段。所以我们要看情况来看你的业务兼容到哪一层账户额度变更一定要有一张额度变更明细表所有的额度变更都要在这里留痕做到快速可追溯也就是这个入口一定要把控住额度引擎就是识别出当前正在使用哪个产品并适配出当前正在使用该产品下的哪个资金账户根据该资金账户的额度使用情况来判断当前用户能不能在当前资金账户下使用额度至于怎么实现的就是三层账户结构比如当前用户开了三个产品三家机构的额度是怎么做到互不影响的围绕着三级账户来答三个产品对应三个产品账户每个产品账户下又有各自的分开管理的消费和提现资金账户互相独立互不影响如果想针对某个产品加一个红包功能怎么加你们是怎么管理消费和提现消费和提现过程中如何保证额度不超限小橙花产品对应有两个三级资金账户一个是消费资金账户另一个是提现资金账户两个资金账户分开管理然后两个资金账户有一个总的产品额度上限小橙花产品有5w额度如果是消费能用3w提现能用2w对应消费资金账户额度3w提现资金账户2w两个额度分开管理互不影响小橙花产品有5w额度如果是消费能用5w提现能用2w对应消费资金账户额度5w提现资金账户2w两个额度耦合在了一起互相牵制。针对两个资金账户额度耦合在一起的情况就需要加锁可以加分布式锁同时锁住两个资金账户也就是对提现和消费统一加一把分布式锁保证同一个产品下提现和消费只有一个在途。也可以使用两个资金账户的版本号一起整体组成一个乐观锁从而保证小橙花额度使用不超过5w如果不加锁控制最大就可能5w的消费也出去了2w的提现也出去了就导致整个小橙花产品一共出去了7w但该用户的小橙花产品额度却只有5w 三级账户表目前的现状关键是授信额度字段这里关键就是三个账户号加上三个额度字段现金额度、已用现金额度、占用现金额度交易域信贷放款系统 TDL 助贷当时做过对接度小满、平安普惠也就是说平安消金作为借贷的资金方度小满和平安普惠是作为客户触达方对接度小满金融时是度小满将客户在度小满界面发起的借贷请求流控到平安消金这端平安消金这端经过一系列的检验比如额度检验风控检验等检验通过后调用AMS进行额度占用占用成功后带上该笔放款单号回调度小满的回调接口通知度小满该笔通过然后度小满自己调用真正的打款接口给用户预留的收款银行卡打款。也就是这里打款的控制者是度小满度小满给客户打款成功后就可以通过调TDL接口或者以文件的形式通知TDL去AMS进行额度动用对接平安普惠时打款的控制者就是平安消金自身而不是平安普惠。依然是客户的触达方将客户发起的放款请求给到平安消金比如额度检验风控检验等检验通过后有三个重要的步骤步骤一直接调用AMS进行额度动用、步骤二是带上该笔放款单号回平安普惠的回调接口告知该笔放款成功步骤二是调用TC的接口TC再调用平安付的渠道进行给客户真正的打款动作步骤二和三调用失败TDL侧会发起重试注说到这里就要提一个生产问题当时一个外包同事负责步骤三结果调用平安付超时了没有拿到响应实际该笔平安付那边已经执行成功放款5w的动作了然后外包同事就进行了重试重试时他竟然换了一个放款单号没有用原来的单号结果就给客户又打了5w的钱造成了二次放款的严重生产问题整个TDL就是一个大异步流程异步里面又用MQ进行了二次异步又因为一条MQ有消费超时时间整个放款流程网络请求过多可能会让单条MQ消费超时所以采用的自己发送自己消费的模式每发送接收一次MQ只处理一个放款流程七八个业务节点中的一个放款主表trade_loan_mgr有一个流程状态扭转与回退的状态字段每执行成功一个节点流程状态就更新一步外部支付调用异步化在外部支付中经常需要服务方与第三方支付交互获取预支付凭证如上图所示。这种同步调用的情况下由于需要跨外部网络响应的 RT 会非常长可能会出现跨秒的情况。由于是同步调用会阻塞整个支付链路。一旦 RT 很长且 QPS 比较大的情况下服务会整体 hold 住甚至会出现拒绝服务的情况因此可以拆分获取凭证的操作通过独立网关渠道前置服务将获取的方式异步化从前置网关获取内部凭证然后由前置网关去异步调用第三方如上 2三方支付收单可以采用异步回调的方式让三方支付系统返回一个受理凭证三方支付系统完成真正的支付动作后异步回调渠道网关的回调接口当前TDL就是采用的这种回调的方式实时交易系统 TDC 四大功能交易、退款、冲正、对账主要有二类户交易好医生商城交易二类户交易内部又有两个分支普通二类户交易〔非分期〕、商户分期交易普通二类户交易CON走普通的定价逻辑。商户分期因为每家商户给定的利率都不一样所以走商户分期时需要每次交易都实时去查PMS定价系统商户分期一般是3 6 12三期三种选择支付路由商户分期POS是针对和消金合作的商户而言的。是有一个预申请的概念客户在勾选比如宜家的某个商品后决定购买前如果决定使用商户分期客户需要自己选择是3 6 12期三种选择选择好分多少期后就可以生成对应的二维码此时就会在APS预先生成交易信息合作商家扫描二维码后开始真正的交易逻辑交易请求到达TDC 交易流程每次需要先去APS查询是否有预申请信息如果有则走商户分期流程否则走普通非分商户分期交易普通交易流程用户展示付款码或者用户扫描商家机器展示的二维码注意这个二维码都是银行生成的交易信息落表、留痕支付路由确定是商户分期交易还是普通交易来决定怎么查定价普通交易的定价查本地商户分期的因为每个商户的定价不一样所以要传商户给PMS来查询当前交易的定价查CIS查询是否为公司员工从而采用固定定价检验账户状态检验、幂等检验、交易是否存在检验、各种限额检验、irisk反欺诈检验、rms用途管控检验、黑白名单检验、额度检验检验都通过后调AMS扣额度扣额度成功后更改交易状态然后开始异步流程调core核算系统计利息、调MM营销系统撞满800返80的活动、调大数据同步交易数据支付流程图技术点当时用过分布式锁用过幂等用过延时消息用过最终一致性用过乐观锁版本号延时消息最开始的版本二类户交易上行的交易请求发来后如果在600ms内没有收到消金的响应就会立马发冲正过来但是AMS的交易流程走完至少要两三秒所以就把很多步骤放在异步流程里了这其中就包括AMS扣减额度成功后通知core开始进行针对该笔交易的记息还有后续账单的展示有一次上行的冲正请求过来后core给返回了一个没有该笔交易记录但是core团队又在他们的数据库中发现了这笔交易总结起来就是上行的冲正请求达到core的时间比交易异步流程中通知到core的时间要快直观的解决方案就是让冲正请求来得慢一点然后我就在AMS里把上行的冲正请求一进来就丢进MQ了延时1min然后自己搞了个消费者消费它才继续走后面的冲正流程交易流程全部同步的跑完可能需要两三秒中所以把一大堆操作挪到异步流程中了同步流程中就只有必要的数据获取、风控校验、每月/每日的限额校验额度扣减等核心步骤了分布式锁每月/每日的消费额度限制当时做过一个需求限制客户每日在某个门店的消费额度限制客户每个月的消费总额度以主账户号商户号为key当日消费金额为value 因为没有使用lua脚本通过账户号商户号为key查询到当日消费金额value判断额度还没有超过当日5000的限额就以主账户号商户号为key当日消费金额当前该笔交易金额amt为新的value写入redis这两个步骤无法保证原子性所以就给这两个步骤一起加了个redis分布式锁版本号乐观锁账户表加了一个版本号字段TDC先查出账户额度和当前的版本号m然后做后续的校验逻辑这段逻辑可能耗费几百毫秒然后真正调用AMS扣减额度时把版本号m传递给AMS让AMS自己去比对库中目前的版本号是否与版本号m是否一致核心交易逻辑二类户交易的流程当时的交易流程是接口一进来立马把所有的请求参数存一遍交易主表trade_disburse_contract_mgr和交易事务表trade_transaction_detail 交易主表trade_manager每比交易进来都立马先记录一条记录交易主表有个状态字段trade_status初始化支付成功支付失败最开始搞了个大字段把整个交易请求报文一股脑全丢进去用来追溯问题的后来被DBA劝退下架了后来提出申请几台MongoDB专门存这种大json的非结构化数据很合适不过又被部门长拍死了交易事务表trade_transaction_detail交易/退款/撤销/冲正等都要在这个表中添加一条记录这个表有个关键字段 transaction_type用来表示是TRADE REFUND REVERSED REVOKED 交易的错误码错误码一定要明细0000是成功其余的都是失败但是失败的原因各异可能是额度不够失败可能是风控校验不通过失败可能是每日限额失败等等不同的失败都要有各自不同的码值这样才能实现精细化管理问题的定位也会更清晰二类户交易流程黑白名单检验是不是可以使用余弦向量比较法好医生商城交易背景平安好医生有自己的商城在平安好医生商城购物可以使用平安消金的消费额度实现整个实现采用流行的异步化的实现好医生商城下订单的信息是给到了APS保存所以APS维护了订单的状态信息。下单成功后好医生商城侧发生支付请求支付请求经TC转入AMS/TDC。AMS/TDC接收到支付交易请求时立马先完整的保存一遍交易信息并在交易主表中记录支付状态为初始化状态然后AMS/TDC用异步线程开启内部的后续支付处理逻辑同时同步流程直接给好医生返回了 3秒后消金自己的前端会发生轮训通过支付单号来AMS/TDC查询该笔交易的支付情况支付回调的逻辑除了等第三方回调还会提供主动查询结果的功能这种是经典的分布式最终一致性解决方案整个支付操作流程是客户在好医生商城侧成功下订单后点击开始支付会首先弹出内嵌于好医生商城app执行的消金支付流程界面客户在消金前端页面上发起真正的支付请求此时的支付请求才会打到AMS/TDC来。也就是说此时的消金前端是能拿到好医生商城传过来的外部交易单号的 22年3月交易迁移到TDC 23年2月账户再次重构重构逻辑未知关于交易流程的最终一致性解决方案蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点每个功能点都可以有多个实现具体的实现之间有组合/互斥关系。把各个功能点按照一定流程串起来就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢比如锁定优惠券服务调用超时了不能确定到底有没有锁券成功该如何处理再比如锁券成功了但是扣减库存失败了该如何处理方案选型服务依赖过多会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务9 个都执行成功了最后一个执行失败了那么是不是前面 9 个都要回滚掉这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下对于非实时、非强一致性的关联业务写入在本地事务执行成功后我们选择发消息通知、关联事务异步化执行的方案消息通知往往不能保证 100% 成功且消息通知后接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦通过订阅方消费 MQ 消息时的 ACK 机制保证消息一定消费成功达到最终一致性。由于消息可能会被重发消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致乍一看必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升解决方案为在电商领域绝对的强一致是过于理想化的我们可以选择准实时的最终一致性。我们在交易创建流程中首先创建一个不可见订单然后在同步调用锁券和扣减库存时针对调用异常失败或者超时发出废单消息到MQ如果废单消息发送失败本地会做时间阶梯式的异步重试优惠券系统和库存系统收到消息后会进行判断是否需要做业务回滚这样就准实时地保证了多个本地事务的最终一致性总结这里就是MQ的一个应用场景天然的重试机制当然都需要配合幂等消费措施蘑菇街的这个最终一致性解决方案消金自己的交易流程可以作为参考总结起来很多最终一致性解决方案的根本原理是类似的也就是将分布式事务转换为多个本地事务然后依靠重试等方式达到最终一致性参考链接https://www.cnblogs.com/Vincent-yuan/p/16074577.html 转账案例的最终一致性拿a转账b举起例子。a操作生成一个账户金额变更记录这个记录添加一个state标记记录未完成事务提交然后发送消息到b那边系统 a这边系统支持幂等等待下一步b回调通知转账结果完成。而a在操作其他业务其能操作的金额是过滤掉这个未完成记录后的金额部分。这种就是我说的语义锁好像有一部分金额被锁住了也就是冻结一个中间状态账单域核算系统 CORE #贷款核心核算# 规划和实现贷款整个生命周期的现金流动。包括贷款发放、利息计算、利率调整、还款计划生成、贷款偿还或处置等覆盖贷款的整个生命周期核算根本要求:准算得准并且记得准每一笔钱不允许出现精度要求范围内的差额一分钱不能多一分钱不能少每一笔帐不允许出现漏记、错记的现象核算系统负责贷后的相关逻辑借据管理是基础能力。核心系统的主要职责是借据信息的存储和管理、分期计划和息费计算及交易流水管理。比如每日跑批算利息、比如还款还款试算、比如账单管理包括账单查询账单分期 ①借据。借据是用来标识客户的一次借款每个借据都有全局唯一的借据号。借据包含各项息费金额、借款日、借据状态等基础信息。 ②分期计划。借据会根据产品规则包含多个分期计划如 3 期、6 期、 12 期、24 期、36 期等。每个分期计划都有各自息费对应的应还、已还以及分期状态等信息。 ③交易流水。交易流水用来唯一标识客户的一次交易行为如放款、还款、退款等。每一种交易行为对应一个交易码。同时交易行为对应的息费金额等信息的变化过程都会被系统记录和保留借据借款申请对应借款单借据借款审批对应审批单据额度扣减对应额度扣减记录签署合同对应签约记录生成还款计划对应账单放款对应支付单上述内容参考DDD在有赞信贷核心系统中的实践 (qq.com) 分发路由系统信贷放款需要资金支持目前的信贷业务除了使用自营资金承接外更多的资金来源需要依靠合作金融机构的资金池。每家平台都会接入几家甚至几十家的合作金融机构。分发路由系统在设计时需要....... 有的公司支付系统每天千万级交易需要尽快的收集到大数据平台参与计算就需要用到kafka来把每笔交易数据给到风控系统大数据风控系统每天都会计算产生一些结果比如白名单、黑名单等如果计算得出张三进入了黑名单那就要在支付系统APP内给张三发一条站内信这种黑名单的通知的量是比较小的但是对可靠性要求比较高这时就不需要用kafka就可以选择RabbitMQ或者RocketMQ RocketMQ天生就克服了kafka、RabbitMQ的缺点又综合了他俩的优点RocketMQ的一个小的缺点是RocketMQ的客户端只支持Java

查看全文

http://www.w-s-a.com/news/945841/