第三方支付架构原则

时隔两年决定重拾博客，对自己经验及感悟做一下记录，并不想教导什么，只想一方面可以沉淀自己的经验，另一方面如果能帮助别人就再好不过了。

前段时间有一大型电商客户在检查目前已有支付系统不足时描述到，目前系统依赖混乱，职责错位，应用间还存在交叉访问数据库，单表数据量大，效率低下，测试资源竞争严重等。

针对这样的现状，只有从整体架构的角度来审视，回复观点如下

从网络硬件架构角度

1. 动静分离，静态资源缓存；
2.  内外网络分离，提高内部应用访问安全性
3.  web应用、业务应用、核心应用、数据库网段分离，提高安全性、稳定性及可扩展性；
4. 用户网络与银行机构网络分离，提高安全性和稳定性
5.  数据库读写分离，对只读类操作如（报表相关可从只读库即可完成，避免对生产服务器产生资源危机）
6. 数据库表进行分区、分表，避免随着时间及业务量的持续增长而导致瓶颈

从业务架构角度

1. 分离业务入口与出口，将变化集中在轻量的端对端交互层面
2. 分离B2C交易、充值、提现等，做到不相关业务分离；
3. 分离不同职能的运营服务，如资金管理、风控管理、客户管理等；
4. 抽取核心服务，如会员账户、支付引擎、清结算、资金渠道管理等；
5. 抽取基础支撑服务，如算费、流量、限额限次等；
6. 建立会计核算机制，保证资金入账准确性；
7. 建立原始凭证复核机制，保障凭证流的完整性和一致性。

从系统架构角度

1.  以业务架构为基础，做到服务分层，如入口层（web应用、收单网关、会员网关）等；业务应用层；核心服务层；出口层（资金渠道、对外沟通），服务依赖之上而下；
2.  根据服务规模，抽离公共服务和公共组件。公共服务包括：统一缓存、统一文件、统一消息、统一日志等；公共组件包括：字符串、金额等一些基础编码工具；
3.  规范框架标准，避免不同成员使用不同的技术而带来的额外学习维护成本；
4. 缩短同步链，非高同步要求的都可以采用异步可靠消息队列完成整体业务链路，以提高吞吐率及相应时间；
5. 减少事务块，以减少数据库链接占用时间和锁时间；
6.  对于竞争频繁的资源需要结合业务角度，采用缓冲队列模式，减少竞争，而不是光从技术角度解决并发；
7. 服务与服务之间采用接口方式调用，提高服务可见度及变化封装性。