qq_38940885的博客

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

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

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

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

从《支付系统设计三：渠道网关设计01-总览》—>《支付系统设计三：渠道网关设计08-结果响应》几篇文章主要讲解了支付网关系统为了实现在线对接支付渠道的实现脉络。本篇对支付网关的实现大致过程进行总结了下，主要是高度配置化、解析脚本、模板引擎的使用。

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

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

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

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

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

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

在《支付系统设计三：渠道网关设计03-参数验证》之后需要进行交易信息准备、路由处理、支付渠道数据补全操作。主要介绍了对交易上下文MessageDescription属性的数据补全。

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

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

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

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

本篇将讲解下单以及拉起收银台加载收银台页面时的代码实现（1/4/5/7/8/9步骤），本篇偏向代码实现。

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

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

轮询扣款算是支付系统中比较复杂的一块，不论是系统设计上还是落地到编码上，要求还是很高的，**本文将讲解从不持之轮询到支持轮询的一个改造过程**。每个公司系统由于技术差异所实现方案也不尽相同，所以仅供参考吧。

如何封装一套服务自身业务开箱即用的重试组件？是个值得思考的问题！在开发支付系统过程中，我们经常会遇到这样的业务场景：调用下游系统、回调上游系统，由于网络原因或者当时对方系统不可用导致调用失败，那么调用失败就失败了么？当然肯定不是，一般都要有重试机制。这种重试机制实现有很多方式，但是万万不可依赖其他系统的重试机制去重试你要重试调用的系统，这个原因下面分析。本篇文章就重试场景给出一个个人觉得还不错的解决方案，也是作者所在用的解决方案，如有更好的解决方案欢迎交流。

在上篇中（支付系统设计：元数据管理设计一），我们的应用对元数据管理已经演进到这步了，接下来我们再接着满足使用方需求。使用方系统如何将自身特有元数据也融入托管到这套缓存管理中；使用方系统不想为了处理缓存而添加MQ依赖，并且担心万一有节点消息丢失了，多节点本地缓存不一致了！同时依旧还是什么都不想做；本篇将就这两个问题展开，继续我们的元数据管理设计。/*** @Description: 缓存管理。

如上是一个最简单的支付与通知流程了，做过支付的都知道发出交易报文和接收到结果通知报文需要对报文进行加签、验签，加签验签需要对应的私钥、公钥；同时有时候还需要一些渠道信息、配置信息等，即多个系统使用同一份数据，这类数据我们统一称为支付元数据，那么这些配置信息应该怎么管理呢？我相信多数系统设计对这块东西的管理就是瞎扭，不是系统间乱调用，就是同一份数据保存在多个地方。下面尝试设计给出一个比较好的管理方式，以供大家在设计系统时候作为参考，也欢迎交流更好的处理方式。努力做一个有思想的猿，拙技蒙斧正，不胜雀跃。

前面几篇我们已经讲解了基于Velocity模板引擎Drools规则引擎实现以支付交易类型为维度的命中设计，使用模板引擎预定义规则模板，生成规则引擎所需要的drl格式的规则文件，那么是不是就可以愉快的使用了？如果不关注效率的话那确实按照网上一些入门程序可以使用了，但是做为企业级别项目，网上给的入门案例毕竟只是demo级别，本文将讲解池化技术对网上给的demo级别的代码进行优化，做到企业级使用。

在上篇文章中我们分析并实现了，使用Velocity模板引擎将条件表（rule_condition）中的数据转换成Drools规则引擎所需drl文件的 LHS 部分，将规则（router_rule）转换到 RHS 部分。但是在生成的drl文件中内嵌这很多自定义函数，本篇讲解这些函数的作用。本篇中主要解析了我们生成的drl规则文件中的几个核心方法。

上篇我们对基于交易类型维度规则的命中设计，进行了简要分析，分析了常规设计下的问题，以及提出了纵向扩展的方式。where条件不仅仅是简单的“=”了，更强大的条件判断规则，如“=、!=、in、!in、>、=、

支付渠道支付成本计价方式管理设计

Classloader是找工作面试的高频问题，不管是应届生身份还是工作多年。记得以前面试一家公司，人力好心提醒我说要懂java的类加载器，人力…不懂技术的都知道！然而不幸的是一般工作中真的极少极少用到，我们从本来一个毫无关联的问题引入到了此技术，还不赶紧收藏了，到时候和面试官吹下。

上篇博文（支付系统设计之证书管理设计一：整体实现概览）我们分析了需求背景以及浮于页面的实现展示，本篇将进行简要分析后端代码的编写设计。还是以上篇文章最后的给的支付系统的架构图为背景。本篇主要是讲解加解密器的定义，并构建包含证书相关以及加解密器的实体并构建绑定关系存储到本地进程中。通过certCode–>获取到CertificateEntity–>获取到加解密器Crypt–>获取到加解密加验签方法(encrypt/decrypt/sign/verify)。

国内的金融支付公司，在安全方面做的很差，为什么说差呢？商户的秘钥证书在一个公司里不知道多少职位的人知道如运营、开发、产品、运维等等，人员之间传过来传过去，有的公司秘钥明文更是赤裸裸的躺在配置中心，好歹给别有用心的人设置点门槛。对于证书的管理是混乱不堪，对于证书的可接触人员的管理控制没有边界，本篇我们是围绕商户证书来说的，所以只谈了此方面的安全问题。所以我们本篇博文打算设计实现一个对证书的管理配置功能。对各个环节需要的秘钥证书进行统一管理，降低监守自盗的风险。

对账是支付系统必不可少的一部分，可以及时发现交易环节存在的交易差异，运营人员可以及时修订交易差异，最重要的是可以发现支付系统存在的问题。一般对账主要分两部分，渠道对账、商户对账，渠道对账是支付平台交易数据和对接的各个支付机构数据进行比对，商户对账是给使用此交易平台的商户生成特定格式的交易账单文件，商户获取然后自己去核对。本篇文章我们将探究如何设计一个能够支撑日交易量百万级的对账系统，并给出核心代码实现，仅供参考。

本篇我们设计实现整个监控系统中最核心的部分–监控模块（自定义告警功能），我们的目标是做一个“简陋、轻便、实用”的监控告警系统 ，毕竟我们不是专门做监控系统的，监控系统里东西还是很多的，只是有时候，公司没有监控，或者公司监控做的东西太难用了，各种复杂的接入流程，所以就自己搞一套符合自己实际业务系统的监控告警系统。

告警通道发送企业微信群告警

RabbitMQ消费方控制

本篇文章我们基于Alibaba的开源组件Canal进行搭建一套数据同步系统，将分表数据进行聚合。

支付网关系统设计

支付系统监控系统

提示：本篇使用Canal 完成数据同步功能文章目录前言 一、pandas是什么？ 二、使用步骤 1.引入库 2.读入数据 总结前言提示：这里可以添加本文要记录的大概内容：例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人都开启了学习机器学习，本文就介绍了机器学习的基础内容。提示：以下是本篇文章正文内容，下面案例可供参考一、pandas是什么？示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任.

前言提示：本篇内容是基于数据库方式生成唯一Id代码案例，通过自定义starter，组件式开发，引入直接使用，避免重复造轮通过实例代码你能学到什么：基于数据库生成唯一Id(号段模式)自定义start包Spring后置处理器的扩展CAS无锁机制日常工作中，使用Mysql时候，数据表主键我们通常使用数据库自增方式，但是当我们使用sharding-jdbc或Mycat等方式分表后如何保证多个表主键的唯一性？实现方式有很多，最长用的有雪花算法（你不觉得这个生成的主键太长了吗？主键一般和业务无关，有

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统能处理的容量；而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀）、写服务（下单），因此需有一种手段来限制这些场景的并发/请求量，即限流。限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求量进行限速来保护系统，一旦达到限制链接数、速率则可以拒绝服务、排队等。高并发系统常见的限流主要有：限制并发数