eBay 账务系统 FAS（Financial Accounting System）为 eBay 管理支付平台提供记账服务，是所有卖家余额和支付交易等信息的 Source of Truth。由于这类信息是高度敏感的核心金融数据，它们必须被存放在一个具有很高安全性的生产环境。

传统 IT 方案采用计算存储分离的架构，逻辑层为一组轻量级的无状态服务，存储层为数据库。系统的正确性、可靠性和高吞吐等特性都是通过数据库来保证。

eBay 安全部门对目前主流的分布式关系型数据库做了评估，发现在安全性上并没有完全满足要求。于是我们另辟蹊径，以 Append-Only Log 作为底层存储介质，采用 Raft 共识算法将 Log 实时复制到异地数据中心，上层采用领域驱动的设计思想（Domain Driven Design）对业务进行建模，用事件溯源（Event Sourcing）的方式处理消息并将结果写入到 Log 中。通过这种非主流计算存储结合的方式，我们做出了一个在核心链路上没有数据库的完整账务系统。

该系统自去年 3 月上线以来，已经帮助全球千万卖家处理交易总计超百亿笔，日均实时处理线上过亿支付流量，每日 payout 金额过亿美元。系统上线至今稳定运行，并成功做到“三无”：无一次数据丢失，无一次转账错误，无一次整体宕机。系统后台仅由 5 台计算机组成，对硬件资源要求低，且几乎无需运维。本次分享想通过介绍该系统背后的架构演进，为大家解决同类问题提供一种不一样的思路。

演讲提纲：

1. 背景介绍
   • 业务简介
   • 为何不采用主流基于数据库的计算存储分离架构
2. 当前成果
   • 数据可靠性
   • 服务可用性
   • 系统性能
   • 数据可审查性
   • 实现成本
3. 架构演进
   • 架构 1.0  - 使用 DDD 和 Event Sourcing 对业务建模
   • 架构 2.0 - 解决数据不丢失问题
     • 使用 Raft 共识算法实现异地实时备份
     • 上层业务正确性挑战
   • 架构 3.0 - 提升服务可用性
     • 通过自研的“双主合一”的设计方案，在保证正确性的同时提高了服务的可用性
     • 进一步讨论：如何在 Raft 换主的情况下保证上层业务主的自动切换
     • 带来的新挑战：吞吐率太低、换主后数据恢复慢
   • 架构 4.0 - 提高系统吞吐量和加快数据恢复速度
     • 利用批处理方式提高吞吐量
     • 采用 RocksDB 和内存的两层存储结构加快数据恢复速度并减少内存使用
   • 架构 5.0 - 安全和完善的数据生命周期管理
     • Log 包含了最核心的支付数据，具有很高的安全级别
     • 监管要求保留所有 Log，但硬盘空间有限，放不下所有 Log，如何两者兼顾？
   • 自研的测试框架
     • 如何证明上面做的一切都能按照预期工作？
     • 使用 chaos engineering，证明系统在底层硬件和网络极不稳定的情况下依然能对外提供“三无”服务
4. 架构适用场景
5. 未来工作
   • Scale Up
   • Scale Out
   • 读模块
   • 开源

你将获得：

1. 了解如何从零打造一个不需要数据库的金融级账务系统
2. 了解经过反复验证的测试该类系统正确性和性能的实战经验
3. 了解核心金融数据生命周期的管理方案