浮生_半日闲
码龄8年
求更新 关注
提问 私信
  • 博客：62,214
    社区：2
    62,216
    总访问量
  • 52
    原创
  • 199
    粉丝
  • 116
    关注
IP属地以运营商信息为准，境内显示到省（区、市），境外显示到国家（地区）
IP 属地：上海市
加入CSDN时间： 2017-05-26

个人简介：菜鸟也是鸟呀...

博客简介：

qq_38940885的博客

博客描述：
qwe
查看详细资料
个人成就
  • 获得34次点赞
  • 内容获得36次评论
  • 获得121次收藏
  • 代码片获得307次分享
创作历程
  • 35篇
    2023年
  • 9篇
    2022年
  • 8篇
    2021年
成就勋章
TA的专栏
  • 支付路由系统设计
    付费
    6篇
  • 支付系统设计
    付费
    47篇
  • Java基础
    3篇
  • spring-boot
    1篇

TA关注的专栏 4

TA关注的收藏夹 0

TA关注的社区 2

TA参与的活动 0

兴趣领域 设置
  • 开发工具
    eclipsegithub
  • 大数据
    mysql
  • 后端
    rabbitmq分布式中间件spring cloud
创作活动更多

新星杯·14天创作挑战营·第9期

这是一个以写作博客为目的的创作活动，旨在鼓励大学生博主们挖掘自己的创作潜能，展现自己的写作才华。如果你是一位热爱写作的、想要展现自己创作才华的小伙伴，那么，快来参加吧！我们一起发掘写作的魅力，书写出属于我们的故事。我们诚挚邀请你们参加为期14天的创作挑战赛！ 注： 1、参赛者可以进入活动群进行交流、分享创作心得，互相鼓励与支持（开卷），答疑及活动群请见 https://bbs.csdn.net/topics/619626357 2、文章质量分查询：https://www.csdn.net/qc

475人参与 去参加
  • 最近
  • 文章
  • 专栏
  • 代码仓
  • 资源
  • 收藏
  • 关注/订阅/互动
更多

  • 最近

  • 文章

  • 专栏

  • 代码仓

  • 资源

  • 收藏

  • 关注/订阅/互动

  • 社区

  • 帖子

  • 问答

  • 课程

  • 视频

搜索 取消

支付系统设计四：支付核心设计03-快捷短信确认（失败转代扣）

在上篇文章中《支付系统设计四：支付核心设计03-快捷发送短信（失败转代扣）》主要讲解了，在快捷支付发送验证码环节，如果发送验证码失败，或者没有业务线没有接入快捷通道，为了不中断支付，系统内部转化支付方式（快捷–>代扣），本来由支付渠道发送短信，转为短信中心发送验证短信，本篇将讲解验证短信环节。整体脉络还是比较简单的，处理一些细节上还是有很多地方需要注意的。
原创
发布博客 2023.06.02 ·
1094 阅读 ·
0 点赞 ·
1 评论 ·
1 收藏

支付系统设计四：支付核心设计03-快捷发送短信（失败转代扣）

本篇将讲解银行卡快捷支付的实现，正常银行卡快捷支付流程过于简单，没什么好讲的，本篇将讲解如何在银行卡快捷失败后，可以顺滑的不中断内部进行支付方式转换（快捷–>代扣），以提高用户体验和支付成功率，如果觉得失败就失败，没必要想办法提高用户体验和支付成功率，那本篇请忽略，因为在你眼里这些设计都是没必要的。同时本篇设计实现也可以当做将代扣包装为快捷对外提供。本篇先讲解银行卡快捷发送短信环节流程实现。一种实现，仅做参考。
原创
发布博客 2023.05.26 ·
1645 阅读 ·
0 点赞 ·
0 评论 ·
1 收藏

支付系统设计五：对账系统设计01-总览

从《支付系统设计一：支付系统产品化》系列中支付网关系统设计我们知道，在对接支付渠道的时候只需要产品经理进行后台渠道相关信息的配置，以及开发人员编写的模板、脚本就能够完成支付渠道的对接了，同样的，通过此模式也可以完成支付系统和支付渠道的对账。后文详细展开具体实现。
原创
发布博客 2023.05.17 ·
1498 阅读 ·
0 点赞 ·
1 评论 ·
3 收藏

支付系统设计三：支付网关设计09-总结

从《支付系统设计三：渠道网关设计01-总览》—>《支付系统设计三：渠道网关设计08-结果响应》几篇文章主要讲解了支付网关系统为了实现在线对接支付渠道的实现脉络。本篇对支付网关的实现大致过程进行总结了下，主要是高度配置化、解析脚本、模板引擎的使用。
原创
发布博客 2023.05.15 ·
1306 阅读 ·
0 点赞 ·
1 评论 ·
1 收藏

支付系统设计四：支付核心设计01-总览

在《支付系统设计一：支付系统产品化》文章中，我们知道支付核心对应于平台产品为公司各业务线提供丰富的且涵盖公司特有业务（如：快捷转代扣，轮询扣款，轮询鉴权）的支付工具封装paygw的各原子交易接口，降低业务线对接支付的难度在《支付系统设计二：统一开发框架》文章中，我们对整个项目系统定了统一的开发框架，在此基础上完成支付核心的设计开发工作。未完，待续…
原创
发布博客 2023.05.14 ·
889 阅读 ·
0 点赞 ·
0 评论 ·
0 收藏

支付系统设计一：支付系统产品化

如果你已将组织的服务转变为现成的解决方案，那么你就已经准备或正在进行“产品化”工作了。这些解决方案经过标准化处理满足目标市场的需求。产品化背后的哲学是产品和服务的交付是可重复的，因此，你可以（并且应该）开发预配置的方法来交付它们，而不必每次都重新开始。本系列文章将讲解整个支付系统的产品化设计实现思路，最大限度的构建一个可以为不同支付公司或者需要支付环节提供基础通用功能的支付系统。
原创
发布博客 2023.05.14 ·
2050 阅读 ·
2 点赞 ·
5 评论 ·
9 收藏

支付系统设计三：渠道网关设计08-结果响应

本篇将继后置处理《支付系统设计三：渠道网关设计07-后置处理到此完成了支付网关paygw整个系统的大概设计处理流程了，设计目标是可以不停机在线对接支付渠道，一周之内可以完成一个支付渠道的对接包括工作：交易、签约、退款、对账等，大大降低了对接支付渠道的周期和人力成本，具体细节还有很多需要补充处理的地方，欢迎交流改进整个系统的设计。
原创
发布博客 2023.05.14 ·
385 阅读 ·
0 点赞 ·
0 评论 ·
0 收藏

支付系统设计三：渠道网关设计03-参数验证

在《支付系统设计三：渠道网关设计02-客户端报文解析》之后需要对上送参数进行校验、交易幂等校验。本篇将讲解paygw对渠道（内部渠道paycore）请求参数的校验，即MessageDescription中datas值的校验。即如何对Map中的值进行校验：是否存在某值，即是否存在某key，对应的值是否合法，即value值长度、类型等是否合法。
原创
发布博客 2023.05.14 ·
806 阅读 ·
0 点赞 ·
0 评论 ·
0 收藏

支付系统设计三：渠道网关设计07-后置处理

本篇将继业务处理之后的后置处理逻辑进行介绍，在请求过支付渠道并将支付渠道响应的报文通过解析脚本转化为系统所需的统一对象了，接下来就是订单数据更新、订单入队（配置限流）和结果通知（同步/异步标识）流程了。本篇简略介绍了订单数据更新、订单入队和结果通知实现流程。
原创
发布博客 2023.05.14 ·
924 阅读 ·
0 点赞 ·
0 评论 ·
0 收藏

支付系统设计三：渠道网关设计06-业务处理

前面做了那么多工作，上送报文解析、参数校验、服务端渠道获取、参数补全、持久化工作等，下面开始请求支付渠道了，本篇将继续分解业务处理部分的逻辑实现。本篇主要介绍了paygw和支付渠道的通讯，在通讯之前先判断是否进行流量控制，如果配置了限流则不再和支付渠道进行通讯，等待后续处理入队走异步处理。如果未配置流量控制，则根据通讯配置构建通讯客户端，进行通讯，并将渠道响应报文进行解析，转化为系统统一格式对象，然后对渠道响应码进行转换。后续处理就是交易表数据更新，构建客户端渠道响应报文，具体实现见后文。
原创
发布博客 2023.05.14 ·
1103 阅读 ·
2 点赞 ·
1 评论 ·
2 收藏

支付系统设计三：渠道网关设计05-交易持久化

本篇将解析交易信息入库，即对上送的参数，在进行校验和一些列补全后，需要进行订单的落地了。本篇对交易持久化实现做了详细的介绍，大概实现思路根据上送报文的transCode从领域模型持久化服务工厂获取到领域模型持久化服务，然后进行交易数据入库工作。
原创
发布博客 2023.05.13 ·
885 阅读 ·
0 点赞 ·
0 评论 ·
0 收藏

支付系统设计三：渠道网关设计04-渠道数据补全

在《支付系统设计三：渠道网关设计03-参数验证》之后需要进行交易信息准备、路由处理、支付渠道数据补全操作。主要介绍了对交易上下文MessageDescription属性的数据补全。
原创
发布博客 2023.05.13 ·
964 阅读 ·
0 点赞 ·
0 评论 ·
0 收藏

支付系统设计三：渠道网关设计02-客户端报文解析

本篇将讲解paygw对渠道请求报文接收以及解析为系统所需格式参数的部分。注：此处的渠道包含paycore/支付渠道，也将paycore抽象为渠道，可以理解为内部渠道，对于paygw来说，调用方都属于渠道。对应于如下的1、3部分：在支付下单时：paycore调用paygw，对于paygw来说paycore是属于客户端；在结果回调时：支付渠道调用paygw，对于paygw来说支付渠道是属于客户端；所以对于如上两种情况，在后台管理系统进行通讯配置时候都将是作为客户端通信进行配置。
原创
发布博客 2023.05.13 ·
1787 阅读 ·
2 点赞 ·
0 评论 ·
0 收藏

支付系统设计三：渠道网关设计01-总览

统一支付出口，提供丰富的支付工具原子能力（代扣、批扣、代付、批付、快捷支付、网关支付、鉴权、银行卡签约等）；与业务场景解耦，业务场景的多变特点不会体现在Paygw系统中；屏蔽各支付渠道的接入差异（通讯方式差异、加密方式差异、业务报文差异）；快速接入支付渠道的能力（可以达到不停机接入）；在《支付系统设计二：统一开发框架》文章中，我们对整个项目系统定了统一的开发框架，在此基础上完成渠道网关的设计开发工作。本篇将讲解其具体实现，在以不停机接入支付渠道为目标做了哪些设计，仅供参考。
原创
发布博客 2023.05.11 ·
1359 阅读 ·
1 点赞 ·
0 评论 ·
4 收藏

支付系统设计二：统一开发框架

在开始一个新项目建设，进入开发环节之前，容易忽略一项非常重要的环节统一开发框架。对于代码的编写，是开发人员各展拳脚还是制定约束规范，前置的结果是项目个子系统代码风格各异，开发人员个人能力直接体现到了项目代码中，能力稍微差的项目代码惨不忍睹，后期的维护扩展令人担忧，这种结果是我们都不愿看到的。对于后者书面的约定规范真的起作用么，也不尽然，就像马路中间树立着禁止穿越马路警示，很多人还是当做没看到，所以最直接的办法就是加栅栏，强制限制，当然翻越栅栏的也不再少数，但是我们已经阻止了多数违规。
原创
发布博客 2023.05.10 ·
1047 阅读 ·
1 点赞 ·
1 评论 ·
2 收藏

DDD领域驱动设计：支付系统中的应用一

DDD作为一种优秀的设计思想，为复杂业务治理带来了曙光。然而又因为DDD本身难以掌握，很容易造成DDD从理论到工程落地之间出现巨大的鸿沟。就像电影里面的桥段，只谈DDD理论姿势很优美，一旦工程落地就跪了。所以DDD的项目，工程落地很重要，否则很容易变成“懂得了很多道理，却依然过不好这一生”。DDD的学习过程好像是”大海捞针“的过程。即使能够捞到点东西，使用起来，还是会有种“东施效颦”的感觉，并不是很自然。为什么学习DDD那么困难呢？叔孙武叔语大夫于朝曰：“子贡贤于仲尼。
原创
发布博客 2023.04.23 ·
1036 阅读 ·
0 点赞 ·
0 评论 ·
1 收藏

支付系统设计：收银台设计二

本篇将讲解下单以及拉起收银台加载收银台页面时的代码实现（1/4/5/7/8/9步骤），本篇偏向代码实现。
原创
发布博客 2023.04.16 ·
1004 阅读 ·
1 点赞 ·
0 评论 ·
1 收藏

支付系统设计：收银台设计一

收银台即用户日常付款前选择支付方式的页面，是支付平台提供的基本功能之一，主要职责是协助业务平台完成支付交易，向用户提供一致的交易体验。一般情况下，根据不同终端类型定制标准化的收银台给到外部进行调用，保证各终端体验一致且针对各端特定需求、场景来展现不同的支付方式。公司内部往往有多条业务线，凡是商业活动一定涉及收款，支付系统扮演平台的角色，为多条业务线提供收款能力，接入的业务线我们称之为商户。支付平台向商户提供C端支付产品和B端商户平台两种类型的支付产品。
原创
发布博客 2023.04.13 ·
2415 阅读 ·
0 点赞 ·
1 评论 ·
1 收藏

支付系统设计四：轮询扣款设计04-详解

在上篇文章（支付系统设计：轮询扣款设计一）中我们大概介绍了下未改造前系统代扣流程，存在的问题是请求支付路由系统返回的最优支付渠道失败后就失败了，然而这种处理机制业务方是不能接受的，对于一些公司的业务可能存在客户逾期的风险，为了满足业务方需求需求并增强系统功能对原来代扣流程进行改造，使之支持轮询扣款功能，当最优支付渠道失败后进行其他渠道重试。本篇将进一步详细分析设计。
原创
发布博客 2023.04.05 ·
1064 阅读 ·
0 点赞 ·
1 评论 ·
2 收藏

支付系统设计四：轮询扣款设计04-整体设计

轮询扣款算是支付系统中比较复杂的一块，不论是系统设计上还是落地到编码上，要求还是很高的，**本文将讲解从不持之轮询到支持轮询的一个改造过程**。每个公司系统由于技术差异所实现方案也不尽相同，所以仅供参考吧。
原创
发布博客 2023.04.03 ·
1340 阅读 ·
0 点赞 ·
0 评论 ·
1 收藏
加载更多