【资损】资损防控的系统规范-内部接口类设计

📫 作者简介：小明java问道之路，专注于研究 Java/ Liunx内核/ C++及汇编/计算机底层原理/源码，就职于大型金融公司后端高级工程师，擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。

📫 热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。

🏆 InfoQ签约作者、CSDN专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO专家 🏆

🔥 如果此文还不错的话，还请👍关注 、点赞 、收藏三连支持👍一下博主~

本文目录

本文导读

一、 资损防控系统设计资损防控规范

二、服务接口类设计概述

三、内部接口类服务常见资损风险

四、内部服务接口设计规范

1、接口定义需要完整、清晰、规范

2、接口中的金额参数使用忽（*1000000）为单位

3、幂等参数

4、对关键性且有时效性的业务不要只使用消息来进行通讯

5、不设置默认重发

6、接口的兼容性处理

7、返回码（错误码）的处理

8、接口中涉及文件及批量场景的处理

总结

本文导读

大型互联网金融公司是如何保证资金万无一失的？本文从系统架构层面整体的资损防控的规范，详细介绍内部服务类资损防控需要的注意事项。

一、 资损防控系统设计资损防控规范

从系统架构层面整体来看，支付公司的系统可以抽象为如下结构:

一、对外部商户提供收单服务类的系统

二、连通支付公司与各金融渠道的网关类系统

三、支付公司的内部业务处理系统

四、消息、调度等中间件系统

五、数据库、缓存等存储平台

​

从系统架构与业务架构上来讲，各个结构连接的地方最容易出现资损。因此我们将从接口服务层面与系统设计层面对资损进行分析并总结相关规范。

二、服务接口类设计概述

按照上述系统抽象架构所示，支付公司接口服务可以分为三类服务：

1、渠道网关类服务

2、收单类服务

3、内部系统接口服务结果。

下面按照各类服务风险又高到底进行分类介绍。

三、内部接口类服务常见资损风险

系统间默认使用微服务，使用 DUBBO 或 Spring Cloud作为分布式服务框架，进行系统间的RPC或HTTP接口调用。

1、服务接口中，各参数类型、长度等相关约定不清楚，会导致数据库超长、被截断等隐藏问题，严重时候会导致资损。

2、服务接口提供方在应用层面，对服务的被使用情况不清楚，导致服务调用方使用错误的接口或组装错误的逻辑。

3、服务接口中，幂等性参数未说明或未正确设置，导致同一笔业务重复调用被服务方重复执行成功，可能导致资损。

4、服务接口中，金额参数单位未按照规范进行使用，造成金额被扩大或缩小100倍或1000000倍，造成资损。（常见分转换元，或者元转换为分）

5、返回码对于重复、超时、异常等结果说明不清晰，请求方错误判定业务状态导致错误的业务逻辑处理，或者更换幂等参数后错误的对同一笔业务进行重复调用。（幂等控制等等）

6、关键性且有时效性的业务处理，只依赖于关联系统的消息通知且无其他的补救措施。由于消息的异步性，到达时间是不可靠的， 会影响业务的处理。

7、服务接口设计的过程中，没有考虑向前、向后的兼容，以及版本发布过程中的兼容性处理问题。如服务使用方使用老服务落单，发布后使用了新服务支付，新老服务不兼容，有可能使应有的校 验失效，导致资损。

8、服务接口需要序列化的对象子类和父类具有共同属性的时候（Dubbo 使用Hessian做序列化与反序列化），会导致属性值丢失。

9、对于涉及文件处理与批量处理的服务接口，缺乏相关明细数据的说明及相关的校验机制。由于内部系统均使用NAS等进行共，接口中传递的只是文件路径；没有进行过相关的加密，没有文件正确性校验功能，可能会导致数据丢失。

四、内部服务接口设计规范

1、接口定义需要完整、清晰、规范

1、接口里面需要详细的定义好出入参的类型、长度选必填以及相关取值等约定
2、服务使用方在使用前需要对输入 做好相关校验 3、服务提供方接口里需要详细描述接口的功能以及对业务和其他接口的影响，涉及资金流向的关键的接口还需要提供资金流向说明。
3、服务使用方使用接口前需要判断接口是否符合需求（功能、信息流、资金流等）、以及自身如何利用服务方接口完成自身的业务处理。
4、由于序列化问题，facade接口中的对象规避子类和父类具有共同属性问题。

2、接口中的金额参数使用忽（*1000000）为单位

内部系统的金额参数不要被更新，如果有更新等需求，使用新的字段。计算的时候使用Money类。对于金融产品，有时候有收益的计算（对收益的计算处理方式不尽相同，如“四舍五入”）：那么该产品收益计算的需求首先要明确，并根据需求进行代码开发，并且重点关注临界值的计算。

3、幂等参数

接口描述必须对幂等参数做着重说明，服务提供方需要使用服务使用方的幂等参数来做幂等控制

4、对关键性且有时效性的业务不要只使用消息来进行通讯

原消息的生产者可以使用RPC对消费者进行调用以获取明确的响应，消费者异步进行任务处理；必须用消息解耦的时候，需要增加监控以及手工触发相关运维功能以保证业务的处理。

5、不设置默认重发

内部接口涉及交易处理的，服务端不管有无幂等控制，不设置默认重发。

6、接口的兼容性处理

1、接口在设计过程中，要避免无兼容性设计
2、在非破坏性变更的时候，既需要保证向前向后的兼容性也需要保证发布过程中的兼容性（包括接口    字段和各种业务处理）。

7、返回码（错误码）的处理

1、要明确每种返回的结果码的含义和场景，包括成功失败、系统超时、系统异常、重复请求等重要场景；
2、需要明确返回结果成功的的含义，是操作成功，还是业务成功，还是双成功；
3、返回的错误编码要包含三位的内部系统编码，且要约定好每种错误场景的业务处理。

8、接口中涉及文件及批量场景的处理

1、内部系统间接口中如果有文件内容的传递接口说明中明确相关文件内容，并需要对关键信息进行校验，防止文件内容不完整或者错误（可以在接口中约定传递文件的MD5值）。
2、文件和批量的明细内容需要对没条数据做清楚的说明：包括是否每笔有自己的唯一流水、是否用其做幂等控制；对文件和批量的整体需要说明是否存在接受部分成功、部分失败的情况。

总结

大型互联网金融公司是如何保证资金万无一失的？本文从系统架构层面整体的资损防控的规范，详细介绍内部服务类资损防控需要的注意事项。