时隔两年决定重拾博客，对自己经验及感悟做一下记录，并不想教导什么，只想一方面可以沉淀自己的经验，另一方面如果能帮助别人就再好不过了。
前段时间有一大型电商客户在检查目前已有支付系统不足时描述到，目前系统依赖混乱，职责错位，应用间还存在交叉访问数据库，单表数据量大，效率低下，测试资源竞争严重等。
针对这样的现状，只有从整体架构的角度来审视，回复观点如下
从网络硬件架构角度
- 动静分离，静态资源缓存；
- 内外网络分离，提高内部应用访问安全性
- web应用、业务应用、核心应用、数据库网段分离，提高安全性、稳定性及可扩展性；
- 用户网络与银行机构网络分离，提高安全性和稳定性
- 数据库读写分离，对只读类操作如（报表相关可从只读库即可完成，避免对生产服务器产生资源危机）
- 数据库表进行分区、分表，避免随着时间及业务量的持续增长而导致瓶颈
从业务架构角度
- 分离业务入口与出口，将变化集中在轻量的端对端交互层面
- 分离B2C交易、充值、提现等，做到不相关业务分离；
- 分离不同职能的运营服务，如资金管理、风控管理、客户管理等；
- 抽取核心服务，如会员账户、支付引擎、清结算、资金渠道管理等；
- 抽取基础支撑服务，如算费、流量、限额限次等；
- 建立会计核算机制，保证资金入账准确性；
- 建立原始凭证复核机制，保障凭证流的完整性和一致性。
从系统架构角度
- 以业务架构为基础，做到服务分层，如入口层（web应用、收单网关、会员网关）等；业务应用层；核心服务层；出口层（资金渠道、对外沟通），服务依赖之上而下；
- 根据服务规模，抽离公共服务和公共组件。公共服务包括：统一缓存、统一文件、统一消息、统一日志等；公共组件包括：字符串、金额等一些基础编码工具；
- 规范框架标准，避免不同成员使用不同的技术而带来的额外学习维护成本；
- 缩短同步链，非高同步要求的都可以采用异步可靠消息队列完成整体业务链路，以提高吞吐率及相应时间；
- 减少事务块，以减少数据库链接占用时间和锁时间；
- 对于竞争频繁的资源需要结合业务角度，采用缓冲队列模式，减少竞争，而不是光从技术角度解决并发；
- 服务与服务之间采用接口方式调用，提高服务可见度及变化封装性。