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

系列文章目录

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

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

--------------------渠道网关设计---------------------------
支付系统设计三：渠道网关设计01-总览
支付系统设计三：渠道网关设计02-客户端报文解析
支付系统设计三：渠道网关设计03-参数验证
支付系统设计三：渠道网关设计04-渠道数据补全
支付系统设计三：渠道网关设计05-交易持久化
支付系统设计三：渠道网关设计06-业务处理
支付系统设计三：渠道网关设计07-后置处理
支付系统设计三：渠道网关设计08-结果响应
支付系统设计三：渠道网关设计09-总结

补充：
支付系统设计三：渠道网关设计10-报文组装详解
支付系统设计三：渠道网关设计11-渠道流量控制
支付系统设计之证书管理设计一：整体实现概览
支付系统设计之证书管理设计二：加/解密器适配实现
支付系统设计之证书管理设计三：自定义Classloader装载sdk

--------------------支付核心设计---------------------------
支付系统设计四：支付核心设计01-总览
支付系统设计四：支付核心设计02-组合支付
支付系统设计四：支付核心设计03-快捷发送短信（失败转代扣）
支付系统设计四：支付核心设计03-快捷短信确认（失败转代扣）
支付系统设计四：轮询扣款设计04-整体设计
支付系统设计四：轮询扣款设计04-详解

-----------------------对账设计------------------------------
支付系统设计五：对账系统设计01-总览
支付系统设计五：对账系统设计02-对账任务生成
支付系统设计五：对账系统设计03-对账任务执行

--------------------批处理系统设计---------------------------
支付系统设计六：批量代发
支付系统设计六：批量代扣

--------------------元数据管理设计---------------------------
支付系统设计：元数据管理设计一
支付系统设计：元数据管理设计二

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

--------------------支付路由设计---------------------------
支付路由系统设计一：实现效果展示
支付路由系统设计二：核心流程
支付路由系统设计三：命中-1
支付路由系统设计三：命中-2
支付路由系统设计三：命中-3
支付路由系统设计三：命中-4
支付路由系统设计三：命中-总结
支付路由系统设计四：优先级排序
支付路由系统设计五：可用性判断
支付路由系统设计六：成本计算
支付路由系统设计七：权重分流
支付路由系统设计八：总结

--------------------调度中心设计---------------------------

--------------------监控平台设计---------------------------

---

---

前言

如果你已将组织的服务转变为现成的解决方案，那么你就已经准备或正在进行“产品化”工作了。这些解决方案经过标准化处理满足目标市场的需求。产品化背后的哲学是产品和服务的交付是可重复的，因此，你可以（并且应该）开发预配置的方法来交付它们，而不必每次都重新开始。

本系列文章将讲解整个支付系统的产品化设计实现思路，最大限度的构建一个可以为不同支付公司或者需要支付环节的公司提供基础通用功能的支付系统。

---

一、产品化概述

1.1 产品化解释

软件产品化是从开发基于客户的定制软件到可重复使用的标准产品的过程，这是指开发或更改思想、流程、技能或服务以使其可以向公众规模出售的过程。产品化涉及采用内部使用的技能或服务，并发展成为标准的、经过全面测试、包装和销售的产品。

1.2 产品化现状

如果按照客户要求来做，基本上和做项目没啥区别；
如果按照产品方式来做，在客户要求的时间要求上，基本上不可能。
由于项目压力，只好先做出来再说。
所谓产品化，只好先扔在一边。
毕竟公司考核你的是能否完成客户的项目，大家的绩效奖金和此息息相关。
阳春白雪（产品化）虽然好，但关系到切身利益，下里巴人（顾自己腰包）才是实实在在的。

1.3 如何产品化

软件产品化是一件相当困难的事情，企业在各个方面都将面临挑战，并必须作出相应的改变。
首先，企业需要转变经营理念和思路。其实不管是项目化还是产品化，都要坚持客户导向，但是就客户导向的内涵和实现方式上，很多企业往往是被动地满足客户需求，甚至迁就客户五花八门的需求。我们到底选择什么样的客户？这是企业成长中必须作出的回答。即便已经明确了这个问题，对客户各种需求也不是不加区别的满足，而是需要抓住目标客户的核心需求和偏好，并认识到客户只要在核心利益上得到足够的满足，他们愿意牺牲一些个性化的特性——这正是产品化的前提假设。
如果不是通用产品或者系统软件，做某个行业软件想零成本实施不太可能，产品所提供的功能永远无法满足客户的业务要求。

1）找到合适的项目和合适的客户，多做项目；

2）在某一个领域积累行业经验，建立样板工程和成功案例，并将项目产品化；

3）提炼管理理念，并将理念和成功案例结合，整理实施方法论；

4）找到下一个项目，在项目开发过程中将原系统重构。

二、支付系统产品化

1. 应用架构

1.1 应用架构1.0

1.2 应用架构2.0

应用架构2.0是基于1.0做的业务拆分，按照出入金签约鉴权进行系统拆分，代码核心逻辑未变，本系列文章基于1.0架构进行分析拆解介绍。

2. 业务架构

3. 分层支撑机制

初衷：希望通过业务场景，丰富平台能力，同时保证内核干净。

我们选择各种框架、进行各种组织设计，核心是为了提高生产效率。但如果业务逻辑都是case by case地进行实现、缺少复用，那么研发成本是非常高的、投入周期也会非常长。

为了增加复用、缩短业务的落地时间，就需要很多通用的能力、产品。在我们的交付过程中，主要有两个层次：

基础能力：相对原子的能力是基础（域）能力，这个可以较好地支持业务定制。由于比较基础，表达的产品能力范围也是很大的。
payGw系统作为基础能力系统:

1.统一支付出口，提供丰富的支付工具原子能力（代扣、批扣、代付、批付、快捷支付、网关支付、鉴权、银行卡签约等）；
2.与业务场景解耦，业务场景的多变特点不会体现在Paygw系统中 ；
3.屏蔽各支付渠道的接入差异（通讯方式差异、加密方式差异、业务报文差异）；
4. 快速接入支付渠道的能力（可以达到不停机接入）；

平台产品：基础能力的通用性，意味着缺少对场景的理解，缺少了进一步提升生产效率的“基因”。所以在交付的时候，会基于一些高频场景进行抽象，形成平台的产品能力，争取做到“拆箱即用”。业务基于“平台产品”这层进行定制的时候，理解成本会大大减少。
payCore系统作为平台产品系统:

1. 为公司各业务线提供丰富的且涵盖公司特有业务（如：快捷转代扣，轮询扣款，轮询鉴权）的支付工具
2. 封装paygw的各原子交易接口，降低业务线对接支付的难度

参考

---

总结

未完，待续…