第三方支付架构原则

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

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

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

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

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