写在前面的话
我们总是在谈论，高可用、高并发的架构设计，有各种指导各种言论在定义着一些规范，输出着一些成熟的方案，供我们学习及实践。
架构设计是没有银弹的，我们必须结合业务来选择合适的设计。并且每种设计都有其优点和缺点，各个场景的偏重点各有不同，选择也不同。脱离业务场景谈设计，是纸上谈兵，结果可能是解决不了实际问题，也可能是过度设计，浪费资源。
最近正好有空，我想整理一下近几年工作中遇到的一些问题，做下总结，复盘一下当时的方案，也重新考虑下，是否有更优解。
当然，以第三方支付的支付平台建设这个我熟悉的领域作为大舞台，更方便我来表述。部分业务场景特性我会简单解释，尽量做到不影响不了解支付业务的读者的感官。
丑话说在前头，讨论的过程、及方案设计，对于诸位大神来说，可能显low，还请不吝赐教。
第三方支付概念理解
所谓第三方，指的是除买卖双方之外的角色。科技在发展，互联网融入普通百姓的生活之后，买卖双方一手交钱一手交货的交易模式已经不复存在，现金支付已经转变为更为便捷的刷卡支付、手机支付等。
第三方支付，是由第三方业者居中于买卖家之间进行收付款作业的交易方式。
现金面对面交易的时候，钱从买家到卖家；采用第三方支付，钱从买家的银行卡，最终到卖家的银行卡，只是中间多了一些步骤。
拿生活中支付宝做扫码支付来讲解，买家要使用支付宝，需要先注册支付宝并绑定银行卡；卖家需要注册支付宝；交易完成后，支付宝扣减了买家银行卡里的金额，卖家支付宝的余额增加；卖家需要提现的时候，把支付宝的余额转到自己的银行卡，当然也要绑定银行卡。
支付宝就是一个第三方支付平台。
我们看到，支付宝能扣减买家银行卡里的金额！他这个本事好强大！——这是银行才有的能力。所以支付宝肯定调用了银行的接口。其实就是银行组织银联/网联提供的能力。
扣减买家银行卡金额的同时，卖家支付宝余额新增了金额，这个支付宝余额，就是支付宝自己记录的账务信息。
所以大白话讲第三方支付，简单而笼统的理解，就是第三方支付公司，使用银行组织的能力，减/增银行卡的金额，同时增/减第三方账务金额。
第三方支付常规设计
根据以上业务分析，第三方支付平台，主要是依赖外部银行组织的能力，我们构建通道系统与之对接，再构建一套账务系统，以这两个服务基础，构建出一套支付服务，就可以对外提供第三方支付能力了。太简单了。
支付业务流程图如下：
该流程图(实际其实更复杂，这里先以最简单的来)，如我们之前了解的一样，商户即收款方也就是卖家，发起支付，请求到达第三方支付平台后，进行一系列校验之后，由外部通道(银行组织如银联/网联等)完成买家的银行卡扣款，扣款结果如果成功，则在商户对应的账户上增加一笔金额，商户后续可以在第三方支付平台的账户余额中看到这笔钱，并能提现到自己的银行卡。
细心的小伙伴可能发现存在问题：
1、买家的银行卡中扣款完成，银行系统中的金额是不是会一直变少？
2、卖家能在第三方支付平台的余额中看到钱，并从这里提现到自己的银行卡，是不是第三方平台自己出钱了？
实际上，银行在完成买家的银行卡扣款的同时，会往第三方支付公司在银行开的“银行卡”里入款；卖家从第三方支付平台的余额中提现时，是从第三方支付公司的“银行卡”转转账到卖家的银行卡。
资金走向为：买家银行卡--->第三方支付公司银行卡--->卖家银行卡。
系统架构图如下：
该架构图省略了风控、稽核、计费、对账、服务控台等多个支付相关的系统模块，大家有兴趣可以另外查证了解。我们把重心放在支付服务如何演进即可。
最后，也是开始
就这样，一个满足基本支付能力的支付平台设计好了。我们可以用一种简单的技术方案先实现它，先让整个平台运行起来。
就是这样：
这是一个典型的单体系统设计，这个实现方案有哪些特点呢？
优点：
1、设计简单：所有的服务集中在一个应用，相互调用直接在内部完成；
2、便于测试：业务集中，无需考虑过多的依赖；
3、部署及扩容简单：单应用部署，直接横向扩容；
4、维护成本低：只用关注一个系统。
缺点：
1、业务耦合：某个模块出现问题，影响其他业务；
2、接口集中：一个应用中所有接口共用一个http请求入口，请求吞吐量受影响；
3、无法精准扩容：不同服务的请求量不同，要扩容只能整体扩容，资源浪费；
4、协同难度大：不同模块的设计、开发、上线计划相互干扰；
5、数据存储耦合：不同类型的业务数据存在一起，难以扩展；
单体系统设计一定不好吗？并不！
如果这个设计，满足了当前业务需求，能够支持后续业务发展，中间也没出过什么问题，那就是OK的。不要觉得这种简单的设计low，在投入有限时，能满足需求且能让我们忽略其短板的设计方案，就是好的设计方案。
但是，在业务高速发展的推动下，我们必须考虑，现有设计的缺点，可能会带来什么问题，我们需要怎么改善，去避免未来可能发生的问题。即便，改造也可能带来新的问题。
那么，面对这些问题，我们开始来改造它吧。
