核心交易系统的重要原理、模型及细节运用.pdf

核心交易系统的重要原理、模型及细节运用  分布式应用的本质  无处无时不在的故障和昂贵的多sql 事务  基于“人肉的性能”场景的分析让“最终一致性正确性”可接受  昂贵的维护性、工程性和分布式事务、都是成本接受问题  批处理、长流程、“幂等、redo 、有序状态”  支付模型( 虚实资金流，瀑布流模型，支付指令引擎)  水渠  网游宝物交易形态、P2P 众贷转让交易形态  钱、物、服务的关系( 升华)  清算、高速交易/ 撮合交易，dao 编程模型与MVCC 次要内容或标题  持久化是昂贵和复杂的，2 和多比1 复杂，  2 和多比1 可靠。进程外的持久化  只能靠共同概念和封装把复杂性和成本降下来，通过工程性 让维护性靠谱，可以损失性能，不能损失靠谱  实事求是，忌画蛇添足的不完美防御代码和抹平缺陷数据  最终一致性，读写分离和人肉场景  定时检查和补偿，幂等id+ 状态(command/api= 希望状态 转变)  COD 和合同账期  同步/ 同一线程、spring 事务和dao  现时dao/ 交互编程模型有损mvcc 性能 本文说明、内容和顺序说明 由于是内部交流，本文行文严谨性比较直接和简约化。 “ 由于时间关系和准备时间不足”： 技术细节和场景细节本来是作者最想说明和探讨的，这是思路来源和思路正确的源泉，由 于准备时间不足，这时刻的本文只是列出了要讨论的标题，以及“原理、模型、细节运 用”中“模型”的主要内容和图示，因为原理、细节运用在业界一流团队和爱彩核心交易团 队都已掌握的知识和技巧，爱彩内部交流也已进行多次和几年前有多个PPT ，因此未能 在本文整理和按所想标题重构一遍。 本文本应按自然原理的规律按前两页目录所定顺序说明，由于本次交流不是科普层次的交 流，因此把最容易图示又貌似高大上的“模型”内容放在前面 ，“ 原理和细节运用” 的内容放 在后面 ，时间内能完成多少就多少。 恰如其分的架构：风险驱动设计 just enough software architecture:Risk-Driven “ 多看阅读” app 上有本书《恰如其分的软件架构》，里面说到“恰如其分”和按自然原理 和经验所考虑到的风险来思考/ 设计架构，确保质 ，有效管理复杂性和成本，是同义 的。 同样 ，新浪爱彩内部不将架构管理工作行政化/ 官僚化/ 形式化，也是本着期望恰如其分 的效果 ，到达“团队成长第一，保障核心质 和安全 ，技术支撑业务多样面孔和热闹红火” 通过让核心交易团队成长和自发的实践经历/ 规模考验 ，让团队成员掌握技术细节/ 抉择 的原因/ 细节来由思路，从产生问题本源处解决来降低成本，培养团队力 ，才能让架构 管理和设计工作抓大放小、关注风险、恰如其分。 人性化的bug 是不可避免的 怎样减少风险 怎样封装成稳定的代码然后对其百般测试使 可靠，如有更清晰/ 正确的“概念和模型”的总结 ，更能有效管理复杂性和成本。只有具备 细节缘由的概念和模型总结 ，才不是人云亦云的概念和空对空导弹气场。 一图胜千言 ，曾经的“降水循环气候图示”和“池塘食物链生态图示”是很清晰有效的。 好的模型和架构，必定符合信息系统硬件底层的自然规律和原理，符合事实实际发生 ，才 能顺利顺畅地核检和实现复杂的业务场景和靠谱的可用性。 软件开发模型的种类和层面有：项目流程，架构设计的关注点和合适的工作 成本难关成 本，业务建模，事务技术模型，设计时代码模型，分布式拓扑架构模型。 本文现只提供了：“支付模块核心引擎的模型探讨”、“非单点式长流程故障检测和通知的 实现模型( 通过wal/redo/ 幂等/ 有序而非quorum ) 和编程模型”、“资金相关软件系统的 一些形态探讨”。 支付宝创造的内外业务流/ 内外资金流模型图示 外业务流 未完成支付 ( 行业伙伴)