- 博客(52)
- 收藏
- 关注
RSS订阅
原创 支付系统设计一：支付系统产品化
如果你已将组织的服务转变为现成的解决方案，那么你就已经准备或正在进行“产品化”工作了。这些解决方案经过标准化处理满足目标市场的需求。产品化背后的哲学是产品和服务的交付是可重复的，因此，你可以（并且应该）开发预配置的方法来交付它们，而不必每次都重新开始。本系列文章将讲解整个支付系统的产品化设计实现思路，最大限度的构建一个可以为不同支付公司或者需要支付环节提供基础通用功能的支付系统。
2023-05-14 19:29:01
2108
5
原创 支付系统设计四：支付核心设计03-快捷短信确认（失败转代扣）
在上篇文章中《支付系统设计四：支付核心设计03-快捷发送短信（失败转代扣）》主要讲解了，在快捷支付发送验证码环节，如果发送验证码失败，或者没有业务线没有接入快捷通道，为了不中断支付，系统内部转化支付方式（快捷–>代扣），本来由支付渠道发送短信，转为短信中心发送验证短信，本篇将讲解验证短信环节。整体脉络还是比较简单的，处理一些细节上还是有很多地方需要注意的。
2023-06-02 22:57:23
1101
1
原创 支付系统设计四：支付核心设计03-快捷发送短信（失败转代扣）
本篇将讲解银行卡快捷支付的实现，正常银行卡快捷支付流程过于简单，没什么好讲的，本篇将讲解如何在银行卡快捷失败后，可以顺滑的不中断内部进行支付方式转换（快捷–>代扣），以提高用户体验和支付成功率，如果觉得失败就失败，没必要想办法提高用户体验和支付成功率，那本篇请忽略，因为在你眼里这些设计都是没必要的。同时本篇设计实现也可以当做将代扣包装为快捷对外提供。本篇先讲解银行卡快捷发送短信环节流程实现。一种实现，仅做参考。
2023-05-26 00:02:26
1660
原创 支付系统设计五：对账系统设计01-总览
从《支付系统设计一：支付系统产品化》系列中支付网关系统设计我们知道，在对接支付渠道的时候只需要产品经理进行后台渠道相关信息的配置，以及开发人员编写的模板、脚本就能够完成支付渠道的对接了，同样的，通过此模式也可以完成支付系统和支付渠道的对账。后文详细展开具体实现。
2023-05-17 23:51:04
1516
1
原创 支付系统设计三：支付网关设计09-总结
从《支付系统设计三：渠道网关设计01-总览》—>《支付系统设计三：渠道网关设计08-结果响应》几篇文章主要讲解了支付网关系统为了实现在线对接支付渠道的实现脉络。本篇对支付网关的实现大致过程进行总结了下，主要是高度配置化、解析脚本、模板引擎的使用。
2023-05-15 23:23:13
1338
1
原创 支付系统设计四：支付核心设计01-总览
在《支付系统设计一：支付系统产品化》文章中，我们知道支付核心对应于平台产品为公司各业务线提供丰富的且涵盖公司特有业务（如：快捷转代扣，轮询扣款，轮询鉴权）的支付工具封装paygw的各原子交易接口，降低业务线对接支付的难度在《支付系统设计二：统一开发框架》文章中，我们对整个项目系统定了统一的开发框架，在此基础上完成支付核心的设计开发工作。未完，待续…
2023-05-14 23:34:37
904
原创 支付系统设计三：渠道网关设计08-结果响应
本篇将继后置处理《支付系统设计三：渠道网关设计07-后置处理到此完成了支付网关paygw整个系统的大概设计处理流程了，设计目标是可以不停机在线对接支付渠道，一周之内可以完成一个支付渠道的对接包括工作：交易、签约、退款、对账等，大大降低了对接支付渠道的周期和人力成本，具体细节还有很多需要补充处理的地方，欢迎交流改进整个系统的设计。
2023-05-14 15:39:30
396
原创 支付系统设计三：渠道网关设计03-参数验证
在《支付系统设计三：渠道网关设计02-客户端报文解析》之后需要对上送参数进行校验、交易幂等校验。本篇将讲解paygw对渠道（内部渠道paycore）请求参数的校验，即MessageDescription中datas值的校验。即如何对Map中的值进行校验：是否存在某值，即是否存在某key，对应的值是否合法，即value值长度、类型等是否合法。
2023-05-14 14:32:15
816
原创 支付系统设计三：渠道网关设计07-后置处理
本篇将继业务处理之后的后置处理逻辑进行介绍，在请求过支付渠道并将支付渠道响应的报文通过解析脚本转化为系统所需的统一对象了，接下来就是订单数据更新、订单入队（配置限流）和结果通知（同步/异步标识）流程了。本篇简略介绍了订单数据更新、订单入队和结果通知实现流程。
2023-05-14 01:13:28
935
原创 支付系统设计三：渠道网关设计06-业务处理
前面做了那么多工作，上送报文解析、参数校验、服务端渠道获取、参数补全、持久化工作等，下面开始请求支付渠道了，本篇将继续分解业务处理部分的逻辑实现。本篇主要介绍了paygw和支付渠道的通讯，在通讯之前先判断是否进行流量控制，如果配置了限流则不再和支付渠道进行通讯，等待后续处理入队走异步处理。如果未配置流量控制，则根据通讯配置构建通讯客户端，进行通讯，并将渠道响应报文进行解析，转化为系统统一格式对象，然后对渠道响应码进行转换。后续处理就是交易表数据更新，构建客户端渠道响应报文，具体实现见后文。
2023-05-14 00:22:02
1114
1
原创 支付系统设计三：渠道网关设计05-交易持久化
本篇将解析交易信息入库，即对上送的参数，在进行校验和一些列补全后，需要进行订单的落地了。本篇对交易持久化实现做了详细的介绍，大概实现思路根据上送报文的transCode从领域模型持久化服务工厂获取到领域模型持久化服务，然后进行交易数据入库工作。
2023-05-13 15:35:03
893
原创 支付系统设计三：渠道网关设计04-渠道数据补全
在《支付系统设计三：渠道网关设计03-参数验证》之后需要进行交易信息准备、路由处理、支付渠道数据补全操作。主要介绍了对交易上下文MessageDescription属性的数据补全。
2023-05-13 14:17:18
976
原创 支付系统设计三：渠道网关设计02-客户端报文解析
本篇将讲解paygw对渠道请求报文接收以及解析为系统所需格式参数的部分。注：此处的渠道包含paycore/支付渠道，也将paycore抽象为渠道，可以理解为内部渠道，对于paygw来说，调用方都属于渠道。对应于如下的1、3部分：在支付下单时：paycore调用paygw，对于paygw来说paycore是属于客户端；在结果回调时：支付渠道调用paygw，对于paygw来说支付渠道是属于客户端；所以对于如上两种情况，在后台管理系统进行通讯配置时候都将是作为客户端通信进行配置。
2023-05-13 02:53:32
1807
原创 支付系统设计三：渠道网关设计01-总览
统一支付出口，提供丰富的支付工具原子能力（代扣、批扣、代付、批付、快捷支付、网关支付、鉴权、银行卡签约等）；与业务场景解耦，业务场景的多变特点不会体现在Paygw系统中；屏蔽各支付渠道的接入差异（通讯方式差异、加密方式差异、业务报文差异）；快速接入支付渠道的能力（可以达到不停机接入）；在《支付系统设计二：统一开发框架》文章中，我们对整个项目系统定了统一的开发框架，在此基础上完成渠道网关的设计开发工作。本篇将讲解其具体实现，在以不停机接入支付渠道为目标做了哪些设计，仅供参考。
2023-05-11 23:37:04
1390
原创 支付系统设计二：统一开发框架
在开始一个新项目建设，进入开发环节之前，容易忽略一项非常重要的环节统一开发框架。对于代码的编写，是开发人员各展拳脚还是制定约束规范，前置的结果是项目个子系统代码风格各异，开发人员个人能力直接体现到了项目代码中，能力稍微差的项目代码惨不忍睹，后期的维护扩展令人担忧，这种结果是我们都不愿看到的。对于后者书面的约定规范真的起作用么，也不尽然，就像马路中间树立着禁止穿越马路警示，很多人还是当做没看到，所以最直接的办法就是加栅栏，强制限制，当然翻越栅栏的也不再少数，但是我们已经阻止了多数违规。
2023-05-10 23:33:12
1077
1
原创 DDD领域驱动设计：支付系统中的应用一
DDD作为一种优秀的设计思想，为复杂业务治理带来了曙光。然而又因为DDD本身难以掌握，很容易造成DDD从理论到工程落地之间出现巨大的鸿沟。就像电影里面的桥段，只谈DDD理论姿势很优美，一旦工程落地就跪了。所以DDD的项目，工程落地很重要，否则很容易变成“懂得了很多道理，却依然过不好这一生”。DDD的学习过程好像是”大海捞针“的过程。即使能够捞到点东西，使用起来，还是会有种“东施效颦”的感觉，并不是很自然。为什么学习DDD那么困难呢？叔孙武叔语大夫于朝曰：“子贡贤于仲尼。
2023-04-23 01:24:08
1071
原创 支付系统设计：收银台设计一
收银台即用户日常付款前选择支付方式的页面，是支付平台提供的基本功能之一，主要职责是协助业务平台完成支付交易，向用户提供一致的交易体验。一般情况下，根据不同终端类型定制标准化的收银台给到外部进行调用，保证各终端体验一致且针对各端特定需求、场景来展现不同的支付方式。公司内部往往有多条业务线，凡是商业活动一定涉及收款，支付系统扮演平台的角色，为多条业务线提供收款能力，接入的业务线我们称之为商户。支付平台向商户提供C端支付产品和B端商户平台两种类型的支付产品。
2023-04-13 01:34:00
2472
1
原创 支付系统设计四：轮询扣款设计04-详解
在上篇文章（支付系统设计：轮询扣款设计一）中我们大概介绍了下未改造前系统代扣流程，存在的问题是请求支付路由系统返回的最优支付渠道失败后就失败了，然而这种处理机制业务方是不能接受的，对于一些公司的业务可能存在客户逾期的风险，为了满足业务方需求需求并增强系统功能对原来代扣流程进行改造，使之支持轮询扣款功能，当最优支付渠道失败后进行其他渠道重试。本篇将进一步详细分析设计。
2023-04-05 17:07:38
1079
1
原创 支付系统设计四：轮询扣款设计04-整体设计
轮询扣款算是支付系统中比较复杂的一块，不论是系统设计上还是落地到编码上，要求还是很高的，**本文将讲解从不持之轮询到支持轮询的一个改造过程**。每个公司系统由于技术差异所实现方案也不尽相同，所以仅供参考吧。
2023-04-03 23:53:59
1383
原创 ThreadPool线程池源码解析
如何实现线程复用的？先提交的任务一定会先执行吗？线程池中的线程如何做到空闲一定时间退出的？没有任务时候超过最大存活时间被销毁的是非核心线程？在调用shutdown方法关闭线程池的时候，如何判断线程有没有在执行任务？shutdown和shutdownNow两个方法区别？如何处理执行失败的任务？本觉得自己已经懂线程池了，看到以上几个问题能否都能答上来，还是又觉得自己不懂了，一脸懵逼？如果你能回答上来那么你可以绕过了。
2023-03-19 22:23:14
2349
3
原创 支付系统设计：消息重试组件封装
如何封装一套服务自身业务开箱即用的重试组件？是个值得思考的问题！在开发支付系统过程中，我们经常会遇到这样的业务场景：调用下游系统、回调上游系统，由于网络原因或者当时对方系统不可用导致调用失败，那么调用失败就失败了么？当然肯定不是，一般都要有重试机制。这种重试机制实现有很多方式，但是万万不可依赖其他系统的重试机制去重试你要重试调用的系统，这个原因下面分析。本篇文章就重试场景给出一个个人觉得还不错的解决方案，也是作者所在用的解决方案，如有更好的解决方案欢迎交流。
2023-03-14 21:58:29
1150
原创 支付系统设计：元数据管理设计二
在上篇中（支付系统设计：元数据管理设计一），我们的应用对元数据管理已经演进到这步了，接下来我们再接着满足使用方需求。使用方系统如何将自身特有元数据也融入托管到这套缓存管理中；使用方系统不想为了处理缓存而添加MQ依赖，并且担心万一有节点消息丢失了，多节点本地缓存不一致了！同时依旧还是什么都不想做；本篇将就这两个问题展开，继续我们的元数据管理设计。/*** @Description: 缓存管理。
2023-03-12 21:51:53
489
原创 支付系统设计：元数据管理设计一
如上是一个最简单的支付与通知流程了，做过支付的都知道发出交易报文和接收到结果通知报文需要对报文进行加签、验签，加签验签需要对应的私钥、公钥；同时有时候还需要一些渠道信息、配置信息等，即多个系统使用同一份数据，这类数据我们统一称为支付元数据，那么这些配置信息应该怎么管理呢？我相信多数系统设计对这块东西的管理就是瞎扭，不是系统间乱调用，就是同一份数据保存在多个地方。下面尝试设计给出一个比较好的管理方式，以供大家在设计系统时候作为参考，也欢迎交流更好的处理方式。努力做一个有思想的猿，拙技蒙斧正，不胜雀跃。
2023-03-11 22:56:52
700
原创 支付路由系统设计三：命中-4
前面几篇我们已经讲解了基于Velocity模板引擎Drools规则引擎实现以支付交易类型为维度的命中设计，使用模板引擎预定义规则模板，生成规则引擎所需要的drl格式的规则文件，那么是不是就可以愉快的使用了？如果不关注效率的话那确实按照网上一些入门程序可以使用了，但是做为企业级别项目，网上给的入门案例毕竟只是demo级别，本文将讲解池化技术对网上给的demo级别的代码进行优化，做到企业级使用。
2023-03-11 14:24:18
481
原创 支付路由系统设计三：命中-3
在上篇文章中我们分析并实现了，使用Velocity模板引擎将条件表（rule_condition）中的数据转换成Drools规则引擎所需drl文件的 LHS 部分，将规则（router_rule）转换到 RHS 部分。但是在生成的drl文件中内嵌这很多自定义函数，本篇讲解这些函数的作用。本篇中主要解析了我们生成的drl规则文件中的几个核心方法。
2023-03-07 23:41:36
587
2
原创 支付路由系统设计一：实现效果展示
支付系统中很重要的一个功能模块–路由系统，本篇只是做个成品展示，具体实现分析见后文！本篇只是泛泛的介绍了下支付路由后台的配置操作的部分步骤，具体怎么实现的见后文分析。
2023-03-04 22:28:54
1063
1
原创 支付路由系统设计三：命中-2
上篇我们对基于交易类型维度规则的命中设计，进行了简要分析，分析了常规设计下的问题，以及提出了纵向扩展的方式。where条件不仅仅是简单的“=”了，更强大的条件判断规则，如“=、!=、in、!in、>、=、
2023-03-04 19:44:03
758
3
原创 Springboot源码分析(一)：环境准备
结合源码探究Spring Boot 的启动机制、自动装配的原理以及内嵌 Tomcat 的实现原理等，本次先把 Spring Boot 源码环境给搭建起来，在2.2.9之前是用maven搭建的，之后用的gradle搭建的，为了方便阅读，所以我们这里选择的2.2.9版本进行下载。JDK1.8Maven3.5以上拙技蒙斧正，不胜雀跃。
2023-02-26 23:49:25
435
原创 JAVA基础：动态代理cglib原理（二）Fastclass 机制分析
JDK动态代理的拦截对象是通过反射的机制来调用被拦截方法的，反射的效率比较低，所以CGLIB采用了FastClass的机制来实现对被拦截方法的调用。
2023-02-25 00:18:42
1790
1
原创 JAVA基础：动态代理cglib原理（一）源码准备
CGLIB是一个强大、高性能的字节码生成库。使用CGLib实现动态代理，完全不受代理类必须实现接口的限制，而且CGLib底层采用ASM字节码生成框架，使用字节码技术生成代理类，比使用Java反射效率要高。需要注意的是，CGLib不能对声明为final的方法进行代理，因为CGLib原理是动态生成被代理类的子类。概念性的东西就不多贴了，总之作为SpringBoot AOP实现底层原理其重要性不言而喻了。然鹅，在工作中发现，工作好多年的都不知道怎么阅读源码，让人着实很惊讶，大佬可以移步了。
2023-02-21 00:27:45
433
原创 支付系统设计之证书管理设计三：自定义Classloader装载sdk
Classloader是找工作面试的高频问题，不管是应届生身份还是工作多年。记得以前面试一家公司，人力好心提醒我说要懂java的类加载器，人力…不懂技术的都知道！然而不幸的是一般工作中真的极少极少用到，我们从本来一个毫无关联的问题引入到了此技术，还不赶紧收藏了，到时候和面试官吹下。
2023-01-08 16:43:13
473
1
原创 支付系统设计之证书管理设计二：加/解密器适配实现
上篇博文（支付系统设计之证书管理设计一：整体实现概览）我们分析了需求背景以及浮于页面的实现展示，本篇将进行简要分析后端代码的编写设计。还是以上篇文章最后的给的支付系统的架构图为背景。本篇主要是讲解加解密器的定义，并构建包含证书相关以及加解密器的实体并构建绑定关系存储到本地进程中。通过certCode–>获取到CertificateEntity–>获取到加解密器Crypt–>获取到加解密加验签方法(encrypt/decrypt/sign/verify)。
2023-01-07 15:33:23
593
原创 支付系统设计之证书管理设计一：整体实现概览
国内的金融支付公司，在安全方面做的很差，为什么说差呢？商户的秘钥证书在一个公司里不知道多少职位的人知道如运营、开发、产品、运维等等，人员之间传过来传过去，有的公司秘钥明文更是赤裸裸的躺在配置中心，好歹给别有用心的人设置点门槛。对于证书的管理是混乱不堪，对于证书的可接触人员的管理控制没有边界，本篇我们是围绕商户证书来说的，所以只谈了此方面的安全问题。所以我们本篇博文打算设计实现一个对证书的管理配置功能。对各个环节需要的秘钥证书进行统一管理，降低监守自盗的风险。
2023-01-03 02:00:00
792
原创 对账系统设计~百万级数据秒级对账
对账是支付系统必不可少的一部分，可以及时发现交易环节存在的交易差异，运营人员可以及时修订交易差异，最重要的是可以发现支付系统存在的问题。一般对账主要分两部分，渠道对账、商户对账，渠道对账是支付平台交易数据和对接的各个支付机构数据进行比对，商户对账是给使用此交易平台的商户生成特定格式的交易账单文件，商户获取然后自己去核对。本篇文章我们将探究如何设计一个能够支撑日交易量百万级的对账系统，并给出核心代码实现，仅供参考。
2022-12-23 21:50:53
3976
8
原创 监控系统-3.1自定义告警
本篇我们设计实现整个监控系统中最核心的部分–监控模块（自定义告警功能），我们的目标是做一个“简陋、轻便、实用”的监控告警系统 ，毕竟我们不是专门做监控系统的，监控系统里东西还是很多的，只是有时候，公司没有监控，或者公司监控做的东西太难用了，各种复杂的接入流程，所以就自己搞一套符合自己实际业务系统的监控告警系统。
2022-12-21 23:12:46
275
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人