第三方支付相关知识结构

我就是我 2022-07-12 08:10 206阅读 0赞

# 1、综述 #

作者：梁川  
链接：https://www.zhihu.com/question/54247561/answer/138579226

技术内容：  
1、**事务处理**：包括关系数据库的ACID、分布式事务（2阶段、3阶段、TCC、补偿性事务、可靠事件、Sagas长事务等）。先结合Spring AOP之类框架，把数据库事务处理机制深入研究一下。  
2、**服务化及服务化治理**：交易导向系统一般都较为复杂，一般主流平台构建都采用SoA或类SoA架构，服务化及服务化治理成为关键，由此引申出消息中间件、zookeeper、redis、dubbo、spring boot、spring cloud等之类框架及技术  
3、**差错处理机制**：由于偏互联网化的第三方支付、交易系统，系统间接口调用存在诸多的不稳定因素，例如支付结果通知时候，或者网络中断、或者对端服务器down掉等，导致结果通知未收到，最终影响对账、支付确认。因此整个系统的异常处理机制、补偿机制极为重要（例如异步通知、补单、主动查询）  
4、安全：包括安全编码规范及习惯，避免SQL注入、各种Web安全漏洞攻击等常见攻击手段；各种数据加密算法及安全体系，例如PKI体系、TLS/SSL；  
5、网络通讯及可靠接口调用设计  
6、数据库性能及扩展性：交易系统一些关键表可能很难通过常用的NOSQL缓存、分库、分表、分库等机制来扩展，可能成为整个系统的性能瓶颈，例如账户表。良好的数据库表设计能力、SQL调优常识至关重要  
以上内容，并非说偏内容导向的程序员不需要关注，交易导向的系统更需要强调这些，作为程序员，第一步先夯实以上技术基础。

与偏内容导向的程序员不同，第三方支付等交易系统一般还涉及较多的业务常识，包括：  
1、**会计学基础知识**：账户系统是第三方支付的核心，而账户系统的原理来源于会计学原理  
2、金融基础知识：包括银行、基金、保险、信托等的知识  
3、电子商务知识  
4、**第三方支付的知识**

以上业务常识，涉及面很广，不可能一下全了解，可以根据公司业务及个人方向来重点了解相关领域的业务常识。  
可以说，只有真正了解业务，才可能设计、开发出好的系统。程序员一定要技术能力+业务能力并重，由此延展开还包括产品能力。虽然是技术，但一定要有意识培养自己的产品规划、产品设计、产品管理、产品运营的意识和能力，产品能力本身与技术设计和架构能力是相通的。

**市面上关于第三方支付的图书较少，有几类偏技术的文档值得推荐：**  
1、强烈建议可以仔细研读一下一些**第三方支付公司的商户接入接口规范文档**，一方面了解业务，更重要的是学习好的接口设计及差错处理机制；  
2、**第三方支付申请牌照的认证规范**，基本上涵盖了一个支付系统的技术规范、业务规范，很值得好好研读  
3、**银联相关的规范文档、接口文档**，基本上涵盖了POS收单、清结算等的相关知识，比较成体系

**资源：**

支付大讲堂  [ http://wenku.baidu.com/link?url=f3B2CcmgR\_piOfqKKDUGTI43L7CHzPsUcJC2vW71tFA53udM-xX3uWVeShMoST0wZ49vO\_7Cu8T-E\_Qohu5CPzBqkWcdppkw9HUZje0f1Ta][http_wenku.baidu.com_link_url_f3B2CcmgR_piOfqKKDUGTI43L7CHzPsUcJC2vW71tFA53udM-xX3uWVeShMoST0wZ49vO_7Cu8T-E_Qohu5CPzBqkWcdppkw9HUZje0f1Ta]

支付大讲堂---中国支付清算协会培训课程精选系列  中国金融出版社出版

人人都是产品经理  [ http://www.woshipm.com/][http_www.woshipm.com]

# 2、如何设计一个完整的订单系统 #

转：[https://www.zhihu.com/question/54662446][https_www.zhihu.com_question_54662446]

作者：梁川  
链接：https://www.zhihu.com/question/54662446/answer/140793441  
来源：知乎  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

说一下一些关键设计点供参考。  
以下设计点，可以归为 "幂等设计"、"CQRS/Event Sourcing"、补偿机制等一些设计原则的体现。  
1、请求/响应方都要维护自己平台的请求号/响应号，并保证请求号/响应号的唯一性。  
设计上不能假定对方能够保证唯一性，应当保证请求方的序号+响应方的序号是唯一的。

2、原始请求/响应报文的所有内容都要本地持久化存储，便于请求/响应的过程回溯，有助于审计、排查、定位问题。

3、对订单状态定义要遵循MECE(Mutually Exclusive Collectively Exhaustive)原则，同时对状态机的迁移要做完整记录

4、消息同步返回+异步通知+主动查询结合 的补偿机制  
由于互联网通信的不可靠性，例如双方网络、服务器、应用等因素的影响，不管是同步返回、异步通知、主动查询报文都可能出现超时无响应、报文丢失等情况，所以像支付业务，对结果的通知一般采用几种方案结合的补偿机制，不能完全依赖某一种机制。  
例如一个支付结果的通知，一方面会在支付页面跳转时候返回支付结果（一般只用作前端展示使用，非最终状态），同时会采用后台异步通知机制（有前台、后台通知的，以后台异步通知结果为准），但由于前台跳转、后台结果通知都可能失效，因此还以定时补单+请求方主动查询接口作为辅助手段。  
常见的补单操作，任务调度策略一般设定30秒、60秒、3分钟、6分钟、10分钟调度多次（以自己业务需要），如果调度接收到响应确认报文，补单成功，则中止对应订单的调度任务；如果超过补单上限次数，则停止补单，避免无谓的资源浪费。请求端随时可以发起请求报文查询对应订单的状态。

5、对重复报文的判重机制，这对诸如支付、代付等场景至关重要，避免出现重复支付、重复付款。

6、采用不同的事务处理机制（按照支付宝的说法叫柔性事务）来满足不同的业务场景需求。例如对支付账户余额更新，采用标准的ACID事务（两阶段、三阶段）；对虚拟账户账户的会计分录采用补偿型事务（异步确保型）；对支付结果通知，采用补偿型事务机制（最大努力通知）；

# 3、总结 #

技术方面主要可以借鉴淘宝相关的分享，包括SOA、事务方面。业务方面可以银行、电信、淘宝相关的业务，大体上流程类同

[http_wenku.baidu.com_link_url_f3B2CcmgR_piOfqKKDUGTI43L7CHzPsUcJC2vW71tFA53udM-xX3uWVeShMoST0wZ49vO_7Cu8T-E_Qohu5CPzBqkWcdppkw9HUZje0f1Ta]: http://wenku.baidu.com/link?url=f3B2CcmgR_piOfqKKDUGTI43L7CHzPsUcJC2vW71tFA53udM-xX3uWVeShMoST0wZ49vO_7Cu8T-E_Qohu5CPzBqkWcdppkw9HUZje0f1Ta
[http_www.woshipm.com]: http://www.woshipm.com/
[https_www.zhihu.com_question_54662446]: https://www.zhihu.com/question/54662446