支付系统

本文是 通道服务的框架设计演化 续篇，上文中主要介绍了支付系统中通道服务的框架的设计演化过程，笔者最终给出了一版实现。最终选择了 服务收口 + 泛型 + 服务插件 + 工厂模式的设计。

由于支付系统需要一些三方的证书做密钥的签名以及对账系统中常用的文件上传，所以搭建我们的FTP文件服务用来保存这些文件就显得很有必要。因此，本文主要介绍如何搭建在云服务器上搭建FTP文件服务。 在使用FTP时，如果客户端机器和FTP服务器双方之间的所有端口都是开放的，那连接不存在…

本篇分享一些关于数据库分库分表的内容，是对现有知识的总结，希望对你有所帮助。 一句话，解决数据扩容以及高并发的问题。 在业务初期，没有多少数据量，单库单表即可满足业务场景。 图中的open-api-web是对外提供的站点层，外部商户使用HTTP协议进行通讯。若不是对外的直接提供…

一般业务中对时间不敏感的离线任务使用诸如Quartz类的定时任务框架即可处理。若遇到如下场景则会比较棘手： 这类场景的的共性是，需要等待一定时间或者到达某个指定的时间点再触发指定的业务逻辑，并且对时间的精准性要求很高。有一种优雅的解决方案延迟消息正是为此量身定做。本文即是对此项…

经常和前端联调的时候，需要提供文档（就很烦）。如果是自己新写的接口还好，怕就怕是之前的老接口，各种返回值的逻辑都不太清楚了，找原来的文档又找不到，找到了还一定是最新的。此时，我就在想能不能搞个东西让它自动生成文档。解决一下这个文档不跟着代码走的老大难问题。 好在是，优秀的人总是…

这篇文章主要分享笔者在Java应用程序中做参数验证时经常使用的方法，希望能帮助大家做一些代码上的优化，同时减少一些丑陋的代码片段。 这种是在一些代码风格要求不高的工程中出现频率最高的做法。常见的代码片段如下： 这种代码站在功能的角度来看，一点毛病也没有，甚至还很简单易懂。但是随…

在笔者从业的多年时间内，参与设计了很多系统。从满足业务需要的角度出发，能快速支撑业务发展都能称之为「好」的系统。毕竟，创造价值的是业务，如果没有业务驱动，工程师掌握屠龙之技没有龙也是相当苦闷之事。做为一名卓越的程序员，相信大家都希望自己开发的系统易维护，更健壮。 当然这只是一种…

支付系统-搭建FTP文件服务

本文是对支付系统中平台流水号的生成进行探讨。一般情况下，我们希望生成的字段值满足我们某种期望的，尽量不去使用完全没有规律的值。假设，我们支付系统中平台流水号的值是 20200627130743000001。这个数字前 14 位代表时间戳，表示该笔交易是 2020 年 6 月 2…

大家都知道，和三方系统进行交互，往往会因为三方接口的设计对我们系统造成一定的侵入。这种侵入指的是，三方接口升级/三方接口设计不合理，导致的自身系统不兼容。遇到这种情况，系统会逐渐演变为打补丁的形态。随着补丁数的增多，原先的很多设计都被掩盖，代码中充斥着大量的 If else 到…

根据我们之前的整体介绍，和业务方交互我们使用的是 HTTP 协议。我们称提供 WEB 接口支持的服务为开放平台（其实每家公司都有自己的叫法，领会精神）。开放平台的职责为支付平台化后，系统内部接口不可对外，所有的外部系统交互统一与开放平台交互，完成服务收口。 由于这些接口都是提供…

在不同的公司，由于接入的通道和应用的差别，所以对模型的抽象有所不同。这里综合支付场景和业务，抽象出如下几大概念。当遇到新的通道对接时，灵活的进行分类，就能够轻松的组合出想要的产品。 微信、支付宝、易宝支付、拉卡拉、翼支付、PayPal等。 如：微信支付、支付宝支付、网银支付、快…

本文先从一个宏观的视角，介绍支付平台整体设计，希望读者在阅读完本篇幅后，能对支付平台有个整体的认知。以下将从三个方面入手： 京东支付的设计算是中规中矩没有什么与众不同之处，这张图来自互联网公开资料，内部实现和图中的出入我们无从得知。但是，大部分的系统设计都是通过借鉴别人分享的内…