Internal · 内部策略材料 · LBank 专项

AWS 竞争优势与策略

LBank 阿里云迁移竞争应对 · 四层胜负手方针 · Aeron 独家能力 · 行业生态 · CEX 与 DEX 全栈经验 · 性能数据
← → 键翻页 · 共 10 页
核心方针

我们的四层胜负手

① 机构在东京（做市商都在 AWS）② Aeron 专长超乎想象（底层调优/迁移 15→5 月）③ 行业总观效应（前 50 所一手信息）④ AI 引领（最强模型+行业实践）
我们的胜负手 · 四层方针 打动 LBank 的四层核心逻辑：从「留下的理由」到「引领的想象」　·　① → ④ 气势渐强 1 机构就在东京 “留在 AWS，就是留在流动性的中心。” 核心客户是机构与做市商 —— Jump Trading、Wintermute、DWF Labs、Flow Traders，绝大多数聚集在 AWS 东京区域。 留在 AWS ＝ 就近接入流动性生态、改配置即可对接做市商；换其他云需自建专线，耗时数月。 流动性生态 隔壁即达 · 改配置接入 2 Aeron 专长超乎想象 “别人给你一份文档，我们陪你把它跑起来。” AWS SA 团队深耕 Aeron 底层代码、参数调优与客户联合优化，并与原厂 Adaptive 保持双周会。 真正落地时帮客户少走大量弯路，把迁移周期从 15 个月压缩到 5-6 个月。 迁移周期 15 月　→　5-6 月 3 行业总观效应 “站在 AWS，你才看得见整个行业。” AWS 掌握整个 CEX 行业一手动向 —— 全球前 50 交易所绝大多数跑在 AWS 上。 一旦搬走，就再也听不到行业全景与竞对动向，这是非常可惜的信息损失。 行业全景 全球前 50 所 · 尽在掌握 4 AI 引领下一浪 “下一波 AI 化改造，我们带你领跑。” AI 是 AWS 的战略重点 —— 贴近最强模型 Claude，叠加丰富的行业 AI 落地实践。 帮客户站在最前沿，引领交易所下一轮 AI 化改造与效率跃迁。 AI 引擎 Claude · 最强模型加持 留下 → 落地 → 全景 → 领跑 来源：AWS 内部竞争材料 + 行业观察
生态壁垒

全球 CEX 都在 AWS 上

全球前 50 所绝大多数核心系统在 AWS。东京 = 加密交易核心枢纽。正向飞轮：越多交易所→越多配套服务→新所更倾向 AWS。选 AWS = 接入整个交易核心生态。
全球 CEX 都在 AWS · 生态飞轮 越多交易所在 AWS → 越多做市商 / OTC / 托管 / 风控配套在 AWS → 新交易所更倾向选 AWS → 循环加速 头部交易所核心交易系统 Binance · Coinbase · Kraken 等 撮合 / 行情 / 风控核心系统 直接运行在 AWS 之上 全球前 50 大所绝大多数在此 合规认证生态 SOC 2 / ISO 27001 / MiCA 审计、KYC/AML 齐备 托管 Fireblocks · Copper 配套 监管沟通与牌照申请更顺畅 做市商专线生态 · 东京 Jump · Wintermute · GSR 就近部署 ap-northeast-1 专线直连交易所撮合 毫秒级套利与流动性供给 Aeron 低延迟客户 Coinbase · One Trading Flow Traders Aeron + AWS 构建超低延迟 撮合引擎 / 消息总线 生态飞轮 · 正反馈循环 全球前 50 CEX 绝大多数跑在 AWS ① 越多头部交易所 把核心系统搬上 AWS ② 做市商·托管·风控 配套生态跟随迁入 ③ 生态更完整 接入成本↓ · 延迟↓ ④ 新交易所默认选 AWS → 正反馈,飞轮加速 选 AWS = 接入整个加密交易核心生态 不只是一个云平台,而是整条撮合 · 做市 · 托管 · 合规产业链 来源：AWS 内部竞争材料 + 行业观察
下一站 · DEX

不止 CEX——下一站一定是 DEX

CEX 和 DEX 都在 AWS 上。CEX→DEX 是结构性迁移（2025 Perp DEX 交易量 $7.9T，占历史 65%）。即便完全链上的头部所，验证者也全跑在云上；Derive 用 Graviton+EKS+Aurora 首月 $3.7B。AWS 已有从官方架构蓝图到真实客户案例的完整 DEX 能力栈——CEX 守住、DEX 接住，一个平台走完下一站。
下一站是 DEX · AWS 同样是主场 去中心化前台 + 中心化云后台 = 当前最优解 · 从官方架构蓝图到真实客户案例的完整能力栈 CEX 和 DEX 都在 AWS —— 下一站一定是 DEX 市场趋势 · 结构性迁移 2025 全年 Perp DEX 交易量 $7.9 万亿 占衍生品历史总量 65% · 结构性放量 衍生品 · 稳定币 · 链上结算 永续合约占衍生品交易 78% 稳定币规模 3 年增长 13.6x 链上结算量 3 年增长 25x 结论：结构性迁移 CEX → DEX 是结构性迁移， 不是短期热点。 FTX 崩盘暴露 CEX 系统性风险 AWS 在 DEX 的独家位置 95%+ 金融交易业务运行在 AWS 『去中心化前台 + 中心化云后台』= 当前最优解 即便完全链上的头部交易所， 其验证者也全部跑在云服务器上。 两种官方参考架构 Hybrid ：链下撮合 + 链上结算 · 10 组件 Full On-Chain ：编译进验证者二进制 · 5 组件 15 组件 → AWS 服务映射 API Gateway / ALB — 交易入口 EC2 .metal 裸金属 — 低延迟撮合引擎 Graviton + EKS — 弹性算力底座 KMS + Nitro Enclaves — 私钥隔离签名 SQS FIFO — 订单严格顺序 Aurora / DynamoDB · MSK — 状态与行情流 覆盖 Hybrid 10 + Full On-Chain 5 全部组件 真实案例 + 价值 真实客户：Derive Graviton + EKS + Aurora 支撑 $3.7B 首月交易量 近百万笔 链上结算 AWS 三大价值 ① 规模化经验 省 30–50% 试错成本 ② 性能基准 50 万 TPS / 15ms 延迟 ③ 战略路线图 MVP → 成长 → 规模化 迁移 落地 LBank 若走 DEX：AWS 已备好从官方架构蓝图到真实客户案例的完整能力栈 CEX 守住 · DEX 接住 —— 一个平台走完下一站 来源：AWS DEX-on-AWS 知识库 + 官方架构 Blog
独家能力

AWS × Aeron 原厂独家深度合作

与 Adaptive/Real Logic（Martin Thompson，前 LMAX 首席架构师）双周联合会议 · 联合调优/Benchmark · 直通原厂工程师 · 推动 bug 修复。阿里云：零合作、零经验。
AWS × Aeron 原厂独家深度合作 双周定期联合会议机制 · 原厂级联合调优与技术直通 · 相较阿里云的绝对差距 Aeron 创始人 Martin Thompson · 前 LMAX 首席架构师 · SBE / Disruptor 设计者　|　Adaptive (Real Logic) = Aeron 原厂，AWS 与其建立独家深度合作关系 AWS 侧 · 原厂级独家能力 依托与 Adaptive 的直接通道 联合调优 原厂工程师共同压测 · 参数寻优 直接技术通道 一键 escalate 至 Aeron 核心团队 bug 优先修复 推动缺陷进入优先修复队列 新版本预览 提前获取 pre-release 联合验证 原厂官方培训 Adaptive 知识转移与认证 架构评审 原厂参与关键架构 review 双周定期联合会议 Bi-weekly Joint Sync · AWS × Adaptive × 客户 参与方 AWS Capital Markets SA 团队 / 我们 Adaptive 原厂工程师 客户 技术团队 核心议题 Aeron on Nitro 最新性能基线 场景化参数调优（延迟 / 吞吐） 新 EC2 实例特性评估与验证 bug 联合排查与复现 新版本兼容性验证 持续输出 调优 Best Practice 持续更新的实战手册 联合 Benchmark 迭代更新的性能基准 沉淀 VS 阿里云 · 无原厂合作 无任何合作关系 · 零经验 · 无升级路径 无联合调优 仅社区文档 · 自行摸索 无技术通道 问题无法上达原厂 bug 无优先级 只能等公开版本修复 无版本预览 被动等待 GA 发布 无原厂培训 无官方支持与认证 无架构评审 无原厂背书 来源：AWS 内部竞争材料 + 行业观察
行业洞察

CEX 架构演进与性能天花板

Kafka(80%, 2-10万TPS) → JRaft/TCP(10%, 5-50万, P99~10ms=TCP 极限) → Aeron/UDP(5%头部, 40-120万, <1ms)。想突破 10ms 必须跳 UDP/Aeron——这不是选择题，是必经之路。
CEX 架构演进与性能天花板 撮合引擎链路的三段递进 — 从 Kafka 标准方案到 Aeron/UDP，为何突破 TCP 天花板是必经之路 ① Kafka 标准方案 ~80% 客户 · 主流选择 TPS 2–10 万 · P99 15–20ms 链路：OMS · Raft 共识 ↓ Kafka（消息中间件） ↓ ME 撮合引擎（主备） 中间件解耦，易运维 延迟主要来自 Kafka 落盘/转发 ② SOFAJRaft / TCP 直连 ~10% 客户 · 进阶优化 TPS 5–50 万 · P99 < 10ms 去中间件：砍掉 Kafka OMS ⇄ ME 之间 TCP 直连 SOFAJRaft 做共识复制 ⚠ 这是 TCP 的物理极限区 某头部用了多年 + 大量人力， 才在 TCP 上做到 50 万 TPS。 TCP 队头阻塞 / 内核栈开销 是绕不过的结构性瓶颈。 ③ Aeron + UDP ~5% 头部 · 性能天花板之上 TPS 40–120 万 · P99 < 1ms UDP 单播 + 用户态可靠传输 共享内存 / 零拷贝日志 绕过内核 TCP 栈，无队头阻塞 跳 Aeron ≫ 死磕 TCP 与其耗多年人力逼近 TCP 极限， 不如直接换传输范式，投产更快。 AWS SA 团队 / 我们的建议路线 TCP 天花板：P99 ~10ms / TPS ~50 万 — 想突破必须跳 UDP/Aeron，这不是选择题，是必经之路 ↑ 唯一在天花板之上的方案 Aeron 提升 延迟 10→2ms 5x TPS 50万→ 120万+ 故障恢复 5min→ <1min HA 增强 阶梯高度 = 性能等级；越往右上，越突破 TCP 天花板。红线以上仅 Aeron/UDP 可达。 来源：AWS 内部竞争材料 + 行业观察
迁移效率

Aeron 迁移时间缩短 60%+

自行摸索 ~15 月 vs 有 AWS 全程支持 ~5-6 月。独家方案：优雅 Step Down、Snapshot 零中断、跨 AZ 60 秒切换。叠加 AI 代码生成，核心代码可能 2 人即可——调参和稳定性测试是我们最有经验的部分。
Aeron 迁移时间对比 两条路径：自行摸索 vs. AWS 全程支持 — 端到端交付周期估算 ① 自行摸索 （无 AWS 支持） 基础架构搭建 ~6 月 Premium 集成 ~6 月 业务灰度 ~3 月 ≈ 15 月 ② 有 AWS 全程支持 （AWS SA 团队 / 我们） ~2 月 ~1-2 月 ~2 月 ≈ 5-6 月 −60%↓ 0 3 月 6 月 9 月 12 月 15 月 时间缩短 60% 以上 ≈ 15 月 → ≈ 5-6 月：AWS 把最难的架构与稳定性阶段前置压缩 再叠加 AI 代码生成辅助：核心代码可能只需 2 人 LLM 对 Aeron 的理解已趋成熟 —— 消息编解码、订阅/发布骨架、集群配置等样板代码可由 AI 快速生成，人工聚焦于设计与评审。 核心代码 · 约 2 人 AI 生成骨架 + 编解码逻辑， 工程师主导设计与集成把关。 主要工作 · 调参与稳定性 背压、批量、丢包重传、故障 切换与长稳压测的反复打磨。 这正是 AWS 最有经验的部分 SA 团队带来低延迟网络、内核/ EC2 调优与生产级稳定性沉淀。 来源：AWS 内部竞争材料 + 行业观察
平台稳定性

阿里云稳定性故障记录

2022 香港散热崩溃 14h+（RDS 30s→133min，差 266 倍）· 2023 双 11 全球瘫痪 · 2024 新加坡锂电池爆炸停 7 天+。2 年 20+ 起公开故障。核心缺陷：AZ 可能只是一层楼、控制面单 AZ 击穿全 Region。
阿里云稳定性故障记录（公开） 2022–2024 公开重大故障时间线 · 3 起灾难级事件 · 全部来自阿里云官方 Status Page 故障时间线 · 2022 → 2024 灾难级 2022.12.18 · 香港 Region · Zone C 机房散热系统崩溃 散热失效 → 消防喷淋误触发进水 → 机房整体停机 14 小时+ RDS 承诺 30 秒自动切换，实际耗时 133 分钟 —— 差距达 266 倍 ECS 可用性最低跌至 20%；单 AZ 故障击穿全 Region 控制面 官方定性：运营十多年以来时间最长的一次大规模故障 来自阿里云官方 Status Page 灾难级 2023.11.12 · 双11 · 全球所有 Region 同时瘫痪 大促当日，阿里云全球所有地域控制面同时不可用；API / 鉴权 / 控制台大面积失败 来自阿里云官方 Status Page 灾难级 2024.09.10 · 新加坡 Region · Zone C 锂电池爆炸起火 数据中心锂电池爆炸起火 → 机房停机 7 天+ 整月可用性连 "1 个 8"（90%） 都达不到 部分客户数据可能永久丢失，不可恢复 来自阿里云官方 Status Page 核心架构缺陷对比 阿里云 · 架构缺陷 · AZ 可能只是一个数据中心，甚至同一栋楼的一层 · 控制面 / 中间件依赖单一 AZ · 单 AZ 故障即可击穿整个 Region · 跨 AZ 无真正隔离，单点依赖普遍存在 VS AWS · 我们的架构 · 每个 AZ 由多个物理独立数据中心组成 · AZ 间距 70–100 km，独立供电 / 散热 / 网络 · 跨 AZ 高可用为默认设计 · 无单 AZ 单点依赖，Region 级容错能力 注：2 年内 20+ 起 Region / AZ 级公开故障，数据均来自阿里云官方 Status Page。 来源：AWS 内部竞争材料 + 行业观察
性能基准

Aeron 性能数据（联合验证）

AWS 独立测试 + Aeron 原厂联合验证，部分优于官方基准。C+DPDK：P99 43μs / 集群 6M TPS(32byte)。这些参数不是文档默认值——是多家客户生产环境反复验证的最优值，拿来即用。
Aeron 性能数据（AWS 联合验证） 超低延迟消息传输基准 · Java / C / C+DPDK 三档实现 · AWS EC2 裸金属 + ENA 网络环境 AWS 独立测试 · 与 Aeron 原厂联合验证 · 部分指标优于官方基准 点对点延迟 · 288B · 100K msg/s · 单位 μs 版本 P50 P99 P999 Java 36 73 121 C 34 66 94 C+DPDK 36 43 47 集群最大吞吐 · 保持 P99 < 1ms · 单位 msg/s 版本 32 byte 288 byte 1344 byte Java 500K 250K 200K C+DPDK 6M 2M 450K 结论 · 拿来即用 这些参数是与 Aeron 原厂联合测试 + 多家客户生产验证得出的最优值， 直接套用即可，不用逐项调参试错，显著缩短上线周期。 关键调优参数 AWS SA 团队与原厂共同标定的生产配置 DPDK 内核旁路 P99 延迟 66μs 43μs 应用零代码改动 CPU Pinning 线程绑核，消除调度抖动 NUMA 亲和 内存/网卡本地节点分配 Term Buffer ↔ L3 对齐 缓冲区尺寸匹配 L3 缓存 ENA Ring Buffer 调优 增大收发环，降丢包重传 禁用超线程 (HT off) 物理核独占，尾延迟更稳 组合收益： Java → C+DPDK，尾延迟 P999 121μs → 47μs，吞吐提升 12×+ 来源：AWS 内部竞争材料 + 行业观察
机构接入

做市商东京生态优势

Jump Trading / Wintermute / DWF Labs / Flow Traders 全围绕 AWS 东京搭专线。在 AWS 接做市商=改配置即可（其他云需搭专线数月）。PrivateLink 单向安全连接、骨干网不经公网。交易所体量不够大，做市商不会为你在非 AWS 平台搭专线。
做市商东京生态 · 机构接入优势 选 AWS 东京 = 直接接入 Jump / Wintermute / DWF / Flow Traders 已建成的专线与撮合网络 东京做市商生态 头部做市商围绕 AWS 东京构建专线与撮合基础设施 专线 + AWS 骨干网 AWS 东京区域 ap-northeast-1 全球加密交易 核心枢纽 Jump Trading 高频做市 · 同区域部署 Wintermute 算法流动性 · 专线直连 DWF Labs 全品类做市 · 骨干网接入 Flow Traders ETF/加密 · 低延迟撮合 AWS PrivateLink · 机构级安全接入 做市商与交易所之间的私有连接,不触碰公网 ① 单向安全连接 做市商单向接入交易所服务,无法反向 访问交易所内网,权限边界清晰。 ② 流量全程走 AWS 骨干网 不经公网传输,天然规避 DDoS 与 链路嗅探,合规审计更简单。 ③ 同区域直连,延迟极低 亚毫秒级往返,抖动小、稳定可控, 高频撮合与风控毫无压力。 对比维度 接入做市商在 AWS 东京 部署在其他云平台 接入做市商 改配置即可复用 AWS 骨干网 · 分钟级接入 需为你单独搭建专线 · 周期以月计 网络延迟 同区域亚毫秒级 · 抖动小可预期 取决于专线质量与选路 · 不可控 额外成本 零 · 直接复用现有骨干网 专线租用费 + 长期运维维护成本 做市商配合意愿 标准接入流程 · 乐意配合 视交易所体量而定 · 体量不足大概率拒绝 交易所体量不够大,做市商不会为你在非 AWS 平台单独搭专线 —— 选 AWS = 直接接入做市商生态。 来源：AWS 内部竞争材料 + 行业观察
← → 键翻页 · 点击翻页 · 滑动翻页