Account Intelligence Dossier · v3 · 客观客户全景

LBank 360 客户全景

全球加密货币交易所（2015 · 12M+ 用户 / 216 国 · 衍生品 CoinGecko #9-10）。当前多云运行——衍生品/合约在 AWS 东京、现货在阿里云；正由 CTO 主导做"统一用户 1.0"新撮合交易系统、评估云平台选型，核心自研中间件 LCM（基于 Aeron）已旁路陪跑，预计 7 月底视稳定性决定切换。
🏛 2015 · 12M+ 用户 / 216 国 📊 现货 #20-23 · 衍生品 #9-10 🎫 6 张牌照 + 迪拜 VARA 申请中 ☁️ AWS(衍生品) + 阿里云(现货) 🔧 自研 LCM（Aeron 替代 Kafka） ⏰ 7 月底 切换决策窗口
$1.65M
2025 AWS ARR 实际 实际
35% : 65%
AWS(衍生品) : 阿里(现货) 份额
~$187K
AWS 月支出（东京 hub）口径 TAP
20s→<1s
LB failover 现状 · 机构目标 99.99%
7 月底
统一系统切换决策窗口

◆ 最新动态 · 现状 （以最近 6/29、6/30 交流为核心 · 此区始终最新）

📌 一句话现状：LBank 由 CTO（DayDay，原 Bybit）主导做"统一用户 1.0"新撮合交易系统替换老架构（现货/合约分离），核心自研 LCM（基于 Aeron 封装、替代 Kafka）已 6/10 起旁路陪跑（上百服务），预计 7 月底视陪跑稳定性由联合创始人 Jason 拍板是否正式切换、以及最终云平台选型。当前衍生品在 AWS 东京、现货在阿里云。

现状要点（6 条 · 客观）

① 业务方向：统一账户 + 冲机构

老架构现货/合约分离，新"统一用户 1.0"要一体化；方向是接入机构客户（对冲基金/专业交易者，要求 sub-ms 延迟 + 99.99% SLA），但当前仍散户为主（营销驱动、上新币见长）。

② 自研 LCM（Aeron 替 Kafka）

LCM = 基于 Aeron 封装的低延迟中间件替代 Kafka；主备 + pilot/etcd 选主、非 RAFT（为性能）；撮合核心全 C++ 重构；端到端 <1ms、吞吐十几万。

③ 单 AZ 两副本

LCM 单 AZ 两副本、leader 先落本地盘再异步发 slave；跨 AZ 尚未做。对机构入驻所需的 99.99% SLA/跨区容灾，可用性是需要补强的一环。

④ 云平台正在评估

新统一系统的云选型尚未最终定——现货侧在阿里云，客户在评估是否将新系统统一到阿里以简化运维/压成本；最终由 Jason 拍板。AWS 衍生品业务份额约 35%。

⑤ 成本高度敏感

客户对成本极敏感；阿里云侧有免费 credits 与折扣。云选型的核心考量＝成本、支持响应速度、平台稳定性。

⑥ 支持体验反馈

此前对某次 DMS 事件的恢复时长与研发拉通速度有反馈意见。Ethan（Infra Lead）关注故障快速恢复、支持响应、平台稳定性——这是云选型的关键因素之一。

🕐 交流与项目时间线

从 2025-12 架构研讨到 2026-07 切换决策窗口的关键节点（客观事件）。

竞争防守时间线 Aeron 差异化对抗阿里云迁移攻势 · 架构研讨 → 旁路陪跑 → 稳定性拍板 2025-12-29 架构研讨会 CTO Jason / DayDay 深度技术交流 五层架构·MQ·Aeron 2026-02-16 阿里云竞争防守 Aeron 差异化反击 阿里以 OKX 案例 推动迁移攻势 6/29 内部策略对齐会 时长 34 min 打法与口径对齐 明确防守节奏 6/30 LCM 性能架构交流 时长 64 min Eason 团队 · 客户侧 性能与架构深聊 6 月中旬起 上百服务旁路陪跑 并行·无损陪跑 积累稳定性数据 持续验证中 7 月底 Jason 拍板窗口 视稳定性定切换 是否全量迁移 ⚠ 窗口收窄 来源：LBank WBR + 6/29·6/30 客户交流
时间线：2025-12-29 交易引擎架构研讨会 → 2026-02 Aeron 技术交流 → 6/29 内部对齐 → 6/30 客户 LCM 性能/架构交流 → 6 月中旬起旁路陪跑 → 7 月底切换决策。

🏢 公司概况 · 商业模式 · 市场地位

2015 年成立的全球加密交易所，12M+ 用户 / 216 国，散户起家、正冲机构化。衍生品排名（#9-10）显著高于现货（#20-23）。2022-08 成为 AWS 客户。

维度事实状态
成立 / 创始人2015 年（Tracxn 记 2016 by Eric He）；Eric Xu 任 North America CEO实际
总部 / 团队新加坡 + 迪拜 + 吉隆坡，团队分布中国及多地；实体 LBK Exchange FZE（迪拜自贸区）实际
用户 / 覆盖12M+ 用户 / 216 国实际
市场地位现货 CoinGecko #20-23（3.1-4% 份额，年量 $1.66T）· 衍生品 #9-10实际
定位散户为主（100x Gem 上新、AFA 赞助、韩国投放）；方向为接入机构客户实际
业务结构衍生品/合约（AWS 东京，800+ 对 24/7）+ 现货（阿里云）双线；新"统一用户 1.0"要一体化实际
AWS 关系2022-08 成为客户；2025 ARR $1.65M；ES PPA 已签（2025-12，3 年）实际
商业逻辑：CTO（原 Bybit）接手后主导做新"统一用户 1.0"平台替换老架构、把整体投入（成本 + 人工）压到最低。选型核心动因＝成本 + 散户为主对延迟要求不极致。联合创始人 Jason 对统一系统上线无硬性 deadline（老系统仍在运行）。

👤 关键人物 · 决策链

决策链：DayDay（CTO，大方向）+ Jason（Co-founder，云选型/商务最终拍板）；Ethan（Infra Lead）主导落地，是主要技术接触点。（仅客户方。）

CTO（原 Bybit）

DayDay

主导"统一用户 1.0" / LCM 自研；2025 到任。技术侧大方向决策者。

Co-founder · 最终拍板

Jason

云平台选型 / 商务最终拍板；散户为主、对统一系统无硬性 deadline。

Infra Lead · 技术接触点

Ethan（= Eason）

落地负责人、主要技术接触点；关注故障快速恢复、支持响应、平台稳定性。

产品 / 开发

Rocky · Javen · Lando

Rocky＝Product Director（前 CTO）；Javen＝C++ 开发、Lando＝Java 开发（LCM/Aeron 模块）。

⚠️ 说明：年初账户计划（UAP）另列过安全/运维等岗位人员，但当前在任与职责已有变化，此处仅列最近交流中确认的核心人物，其余待最新对齐后更新。

⚖️ 监管 · 牌照 · 展业

已获 6 张牌照/证书，迪拜 VARA 申请中。散户为主、全球化营销、多语言运营（6 语）。

司法辖区牌照 / 状态
美国FinCEN MSB + NFA
加拿大MSB
意大利OAM
澳大利亚AUSTRAC
立陶宛VASP
迪拜 UAEVARA 牌照申请中（LBK Exchange FZE，迪拜自贸区）
展业 / 语言全球 216 国；营销驱动（AFA 赞助、韩国投放）；客服 6 语（英/中/泰/马来/韩/阿拉伯）
与机构入驻的关系：机构客户要求统一合规（SOC2 / ISO27001）、统一审计与多辖区合规报告，多云分离的合规栈会增加复杂度——统一平台有助于合规一致性。

☁️ 云足迹 · 支出结构

多云运行，无本地机房。衍生品/合约在 AWS 东京，现货 + 中台在阿里云。

云开销份额 · 阿里 7 : AWS 3 LBank 云成本结构 — 阿里云承载现货/大数据/风控，AWS 承载合约；两朵云 Region 均在东京 阿里云 · 60–70% 现货 · 大数据 · 风控 AWS 30–40% 合约业务 横向占比条 — 段宽即份额（阿里 7 成 / AWS 3 成，取中值示意） 7 : 3 阿里 : AWS 环形占比 — 云开销总盘 阿里新系统账单 月账单标价 ~ 十几万美金 实际付 ~ $1–2 万 / 月 标价与实付差额由 credits 抵扣 免费 Credits Waive 年初至今主要靠免费额度抵扣 现金支出被大幅压低 credits 耗尽后实付将回升 Region · 东京 阿里云 & AWS 均部署于东京 同城双云 · 低延迟互通 迁移时网络拓扑变动可控 ⚠ 风险 · 统一用户 1.0 迁移 若新「统一用户 1.0」系统选择切至阿里云，则原本跑在 AWS 上的合约业务 （占云开销 30–40%）将随统一架构一并迁出，AWS 份额可能归零。 影响面：合约交易撮合 · 行情 · 清算链路 —— 当前唯一留在 AWS 的核心负载。 应对：以东京同城低延迟 + 合约稳定性为抓手，守住 AWS 这 3 成基本盘。 AWS 份额风险敞口 30–40% → 面临迁出 来源：LBank WBR + 6/29·6/30 客户交流
份额结构：AWS 约 35%（衍生品/合约，东京）· 阿里云约 65%（现货 + 中台 + 日志）。数字为份额口径。
维度现状状态
AWS 月支出~$187K（东京 hub ~$213K/月口径）口径 TAP
2025 ARR$1.65M（2024 baseline $631K）实际
份额AWS 35%（衍生品）· 阿里云 65%（现货 + 中台 + 日志）份额口径
商业协议ES PPA 已签（2025-12，3 年）；更大额 Cross-Service PPA 为年初设定的目标（尚未签署）ES 已签 大额目标
2025 用量曲线Jan 82K → Dec 260K/月；12 月 +70K（含合约库 r6g→r8g 大版本升级 + 压测 + 首购 ES）口径 TAP
⚠️ 口径说明：以上金额来自年初账户计划（TAP/UAP，数据约截至 3 月）与用量记录，年初设定的增长目标不代表当前实际走向；本页明确区分"实际"与"目标/口径"。实时账单请以账户团队 Cost Explorer 为准。

🎯 架构 AWS 交易平台架构（东京）

衍生品/合约平台运行在 AWS 东京 ap-northeast-1，三层设计（架构描述来自年初 TAP，仍有参考价值）。

AWS 衍生品平台架构（东京） LBank 衍生品交易平台 · AWS ap-northeast-1（东京）三层架构 · Multi-AZ 私有子网 EDGE 层 · 全球接入 Route 53 · Geo DNS 地理路由 · 就近解析 4.25 亿查询 / 月 CloudFront + Shield 边缘缓存 · 静态加速 DDoS 防护 Cloudflare / Akamai 主 CDN · 多云加速 WAF / Bot 防护 NLB / ALB 四层 / 七层负载均衡 入口分流 APP 层 · Tokyo VPC · Multi-AZ 私有子网 ap-northeast-1a / 1c / 1d 撮合引擎 m5zn.12xlarge ×3 3.9GHz · 20K TPS 订单服务 c6i / c7i.2xl ×40+ 下单 / 撤单 / 持仓 行情服务 c6i / c7i.4xl ×10+ 深度 / K线 / 推送 API / WebSocket m7i ×20+ REST / WS 网关 EKS 微服务集群 容器化 · 弹性伸缩 Trading Account Risk Market Auth DATA 层 · 持久化 & 缓存 Aurora MySQL r8g.8xl ×4 主 · r6g.8xl ×3 读副本 6TB · 10.5B IO / 月 ElastiCache Redis 35 节点集群 会话 / 热数据缓存 MSK · Kafka 事件流 / 消息总线 成交 / 撮合流水 OpenSearch 日志检索 / 审计 19 TB ANALYTICS & 副区 ClickHouse Cloud 实时 OLAP 分析 第三方 · 非 AWS EMR · Flink on EKS 流计算 / 实时风控 42K vCPU-h / 月 us-west-1 · 北美网关 跨区接入 / 就近下单 副区 us-east-1 · 全局服务 IAM / CloudFront 控制面 副区 月支出 ~ $187–213K · Route 53 4.25 亿查询/月 · Aurora 10.5B IO/月 · EMR 42K vCPU-h/月 · OpenSearch 19TB 来源：LBank UAP/TAP 2026 + WBR
三层架构：Edge(Route53/CloudFront/Cloudflare) → App(m5zn 撮合 + EKS 微服务) → Data(Aurora/Redis 35 节点/MSK/OpenSearch 19TB) → Analytics(ClickHouse/EMR Flink)。
层组件
Regionap-northeast-1（东京 Primary Hub）；副区 us-west-1（北美网关）、us-east-1（Route53/CloudTrail/ACM）。账号 Production VansDeriv + Test awstech
EdgeRoute53 Geo DNS（4.25 亿查询/月）→ Cloudflare（主 CDN/WAF）+ Akamai（次），CloudFront 有限 → NLB/ALB
App（Multi-AZ）撮合 m5zn.12xlarge×3（3.9GHz，20K TPS）、订单 c6i/c7i.2xl×40+、行情 ×10+、API/WS m7i×20+、EKS 微服务（Trading/Account/Risk/Market/Auth）
DataAurora MySQL r8g.8xl×4 主 + r6g.8xl×3 读（6TB，10.5B IO/月）、ElastiCache Redis 35 节点、MSK Kafka、OpenSearch 19TB
AnalyticsClickHouse Cloud（Marketplace）、EMR Flink on EKS（42K vCPU-h/月）
阿里云环境：现货交易平台（ECS/ApsaraDB/SLB）+ 中台微服务 + 运维平台 + Splunk 自建日志分析。

🎯 撮合 统一用户 1.0 · LCM 自研中间件

现状：LCM = 位于前台交易系统与撮合引擎之间的低延迟通信中间件，基于 Aeron（transport 封装成 MQ）自研，替代原 Kafka。主备 + pilot/etcd 选主、非 RAFT；撮合核心全 C++ 重构。

LCM 架构（Aeron 自研中间件） LBank 自研低延迟中间件 · 前台 → LCM → 撮合 → 清结算 · 全链路单节点主备 · 单 AZ · 端到端 <1ms 前台交易系统 柜台 / OMS 报单入口 单节点主备 LCM 中间件 Aeron 自研 · MQ 替代 Kafka leader / follower 双副本 撮合引擎 全 C++ 重构 · 避 GC 单节点主备 清结算 Clearing & Settlement 单节点主备 报单 订单流 成交回报 LCM 内部：leader / follower 主备两副本 + pilot 控制面（接 etcd 选主防脑裂） leader（主副本） ① 先写本地盘落盘 (WAL) ② 再异步发送 slave 本地磁盘持久化 follower / slave（备副本） ring buffer 收到即 ACK 收到即返回（未必已落盘） 异步复制 ring ACK pilot（控制面服务） 选主 · 探活 · 存元数据 不参与投票 与数据面解耦 etcd 集群 选主 / 防脑裂（多数派） 元数据一致性来源 存元数据/选主 探活 / 选主 落盘 / 复制逻辑 leader：先写本地盘落盘 (WAL)， 　　　　再异步发送 slave slave：ring buffer 收到即 ACK， 　　　 收到即返回（未必已落盘） 非 RAFT — 为极致性能 无 quorum / 无多数派确认 单 AZ 部署，主备同机房 吞吐十几万/秒，目标 10 万/分片 技术要点 • Aeron transport 封装成 MQ，替代 Kafka • 非 RAFT 共识（为性能牺牲强一致确认） • 撮合核心全 C++ 重构（几十万行，避 GC） • 单 AZ 部署，全链路单节点主备 • 端到端延迟 < 1ms • 吞吐十几万/秒（目标 10 万/分片） ! AWS 判读：可用性 / 持久性隐患 架构 = 单 AZ + 仅两副本 + 本地盘 corner case（存在数据丢失风险）： · slave 未落盘即宕机 → 已 ACK 数据丢失 · 本地盘慢 / 故障 → 复制与落盘背离 · 单 AZ 整体故障 → 主备同时不可用 建议：跨 AZ 部署 / quorum 确认 / 持久化存储 来源：LBank WBR + 6/29·6/30 客户交流
LCM 架构：前台→LCM(主备+pilot/etcd)→撮合→清结算，全单节点主备；leader 先落本地盘再异步发 slave。
架构要点：① pilot 控制面负责选主+探活+存元数据、不投票，后接 etcd 集群防脑裂；② 上下游 OMS/撮合/清结算均单节点主备，数据可靠性压在中间件；③ 非 RAFT＝为性能（RAFT 两节点共识通信成本）+ Aeron+Java 开发 GC 考量；④ 线上两副本（成本权衡）；⑤ 统一账户一体化跑现货+合约，机构/散户核心撮合相同。
可用性观察：LCM 落盘为 leader 先本地盘、slave ring buffer 收到即 ACK，与 Aeron RAFT（同步发 follower）不同。happy path 无问题，但极端场景（slave 未落盘即挂 / 本地盘变慢）存在数据丢失窗口，且单 AZ 有机柜级故障风险——对机构入驻所需的 99.99% SLA，跨 AZ / 多副本一致性是需要补强的一环。

🎯 可用性 高可用 / DR

机构入驻要求 99.99% SLA + 跨区容灾。当前性能达标，可用性/DR 是需要补强的一环。

单 AZ 两副本 vs 多 AZ RAFT 存储层高可用架构对比：LBank 现状（单 AZ 主备）→ AWS 建议（跨 3 AZ RAFT，RPO=0） LBank 现状：单 AZ 两副本（主备） leader + follower 同 AZ · 本地盘 · 异步复制 AZ-1 · 单可用区 / 单机柜 Leader（主） 本地盘 · 先落盘 写入即持久化 Follower（备 / slave） 异步接收 · 收到即 ACK 未必已落盘 异步复制 收到即 ACK 复制链路：leader 落盘 → 异步推送 slave → slave 收到即回 ACK（未落盘） 同一 AZ · 同一机柜 · 依赖本地磁盘持久化 Corner Case：数据丢失风险 slave 未落盘即宕机 → 已 ACK 数据丢失 或 slave 盘慢 → 主备长期不一致 无多数派确认，RPO > 0 单 AZ 机柜级故障 leader + follower 同处一个 AZ 机柜 / 供电 / 网络故障 爆炸半径 = 整个集群不可用 结果：可用性受限于单 AZ，存在数据丢失窗口 现状 vs 建议 VS 演进 AWS 建议：多 AZ RAFT 三节点跨 3 个 AZ · 同步复制 · 自动故障转移 AZ-a Node 1 Leader / 主 AZ-b Node 2 Follower AZ-c Node 3 Follower（投票） Raft 同步复制 · 3 投票成员跨 3 AZ · quorum=2 多数派确认 单集群性能 20 万 TPS · P99 < 10ms Raft 同步复制 / 3 投票成员跨 AZ 同步复制不牺牲吞吐 AZ 故障：零数据丢失 多数派已确认 → RPO = 0 自动选主 · 秒级故障转移 跨 3 AZ 可容忍 1 AZ 全挂 延迟极致方案（可选） 或同 AZ 内用 PPG（集群放置组）打散：100K 负载下 2ms 延迟 以少量可用性换极低延迟，可按业务取舍 结论 1）性能不是问题：Aeron 多层调优下，即使采用 RAFT 同步复制也能做到百万级 TPS。 2）可用性才是关键：单 AZ 两副本存在数据丢失窗口与机柜级爆炸半径；多 AZ RAFT 实现 RPO=0、AZ 故障零丢失。 来源：LBank WBR + 6/29·6/30 客户交流
对比：单 AZ 两副本主备（本地盘、异步 ACK，存在数据丢失窗口 + 机柜级风险）vs 跨 3 AZ RAFT（3 投票成员 quorum=2、AZ 故障零数据丢失、RPO=0）。
组件现状机构入驻目标
撮合引擎20,000 TPS on m5zn.12xlarge，冗余有限机构级撮合性能 + Multi-AZ HA
数据库单核心库服务所有业务线（交易/结算/钱包）= 单点业务线隔离 + RDS Proxy 秒级 failover
负载均衡failover 需 20 秒<1s failover
高可用东京 Multi-AZ；无跨区 DR；SLA ~99.9%99.99% SLA + 跨区 DR（RPO<1min/RTO<5min）

🎯 压测 LCM 压测数据

客户 LCM 压测报告（LBank-03）：单线程达标，多线程 P999 偏高——分析指向压测程序侧而非中间件。

LCM 压测数据研判 LBank LCM 压测报告可视化 · 单线程基线 vs 多线程阶梯 · AWS 瓶颈判读 单线程基线 达标 ✓ Payload 1024B 171,318 TPS p99 443µs Payload 128B 165,211 TPS p99 142µs 丢包 loss = 0 结论：单机单线程即达 17 万 TPS， 延迟稳定、零丢包。 → broker / 服务端处理能力充足， 基线本身健康。 AWS 判读 瓶颈定位 ① broker 非瓶颈 单线程基线已证明服务端富余 ② 瓶颈 = 客户端压测程序 • 发送 / 消费同机，资源争抢 • Java / Python GC 停顿 • 单机 CPU / 网卡到上限 ③ 加压不增吞吐 → 已饱和 反常信号：多线程吞吐 < 单线程 典型的压测端（而非被测端）受限特征 多线程阶梯 异常 ⚠ 线程 threads 4 → 8 压入 offered 300K → 1,100K 实测吞吐钉死 142 – 153K TPS < 单线程 171K p999 延迟恶化 512B / 500K → 905µs 1024B / 500K → 10.3ms 加压 3.6 倍，吞吐不升反降、 尾延迟放大 23 倍 → 压测端饱和。 吞吐对比：单线程 vs 多线程 (TPS) 180K 150K 100K 50K 0 单线程基线 171K 171,318 165,211 153K 142K 单线程 1024B 单线程 128B 多线程 峰值 多线程 谷值 ↑ 多线程各档吞吐均落于单线程基线之下 —— 加压端而非 broker 触顶 AWS 建议 下一步 多台压测机分布式加压 发送机 ≥ 4 核，发送/消费分离 CPU 绑核（taskset / isolcpus） JVM 采用 G1 GC + 堆调优 逐步加压，定位真实吞吐拐点 复测目标 吞吐随线程/机器数近似线性增长 → 证伪单机瓶颈 来源：LBank WBR + 6/29·6/30 客户交流
压测数据：单线程 1024B→171,318 TPS/p99 443µs（loss=0，达标）；多线程 threads4→8 吞吐钉在 142–153K、p999 恶化至 10.3ms。
分析结论：broker 全程非瓶颈，瓶颈在客户端压测程序——发送/消费同机 + Java/Python GC + 单机瓶颈。建议：分多台压测机、发送机 ≥4 核、绑核、调 JVM/GC（G1）。1KB / 171K TPS / P99 443µs 已满足当前交易引擎要求。

🎯 行业 CEX 撮合成熟度阶梯

行业视角——把 LBank LCM 放到撮合成熟度阶梯上定位。

CEX 撮合成熟度阶梯 撮合引擎架构 5 级阶梯 · 性能 × 可用性/容灾 —— LBank LCM 定位参照 · 币安 / OKX 对标 可用性 · 容灾能力 → 架构演进 · 吞吐 / TPS → 级 1 自建 Kafka 主备 Kafka 主 / 备双写日志 撮合状态靠 MQ 回放重建 切换有秒级抖动 · 单点风险 级 2 统一 Kafka / kRaft 去 ZooKeeper,kRaft 内建共识 元数据一致性 · 运维简化 仍是 MQ 中心式架构 级 3 Raft OMS + 主备撮合 订单管理 (OMS) 走 Raft 复制 撮合仍主备,非全链路共识 故障切换更可控 级 4 全链路 Raft(多 AZ) 撮合 + OMS 全程 Raft 共识 跨多可用区 (AZ) 部署 秒级容灾 · 近无损切换 级 5 · HEAD Aeron(HEAD 层) UDP 单 / 多播,超低时延传输 百万 TPS / 个位数 ms 欧洲期货 · 期权所标配 参照 · 币安 自建 Kafka · ~20 万 TPS · 个位数 ms 参照 · OKX Aeron · 200 万 TPS Kenny benchmark 中 LBank LCM · 现状定位 Aeron 自研 MQ 替代 Kafka —— 消息层已升级 低时延 / 高吞吐,性能对标 HEAD 层 但仍非 RAFT 共识,且单 AZ · 两副本 容灾 / 可用性 ≈ 仍停留在 Kafka 时代 定位：介于中间层(≈级 2–3)—— 快,但不够稳 LBank ≈ 此处 来源：LBank WBR + 6/29·6/30 客户交流
成熟度阶梯：自建Kafka主备 → 统一Kafka/kRaft → Raft OMS+主备 → 全链路Raft(多AZ) → Aeron(UDP)。LBank 的 LCM 基于 Aeron 自研，性能达标；可用性/多 AZ 是行业头部持续演进的方向。
行业脉络：约 80% 交易所从 Kafka 起步（TPS 2-10万/P99 15-20ms），约 10% 用 SOFAJRaft/TCP（5-50万/<10ms，TCP 天花板约 P99 10ms），约 5% 头部用 Aeron/UDP（40-120万/<1ms）。LBank 直接选择了 Aeron 路线自研——起点较高，下一步的重点是可用性与多 AZ 演进。

🎯 数据 数据平台

围绕交易/结算/钱包三业务线的 workload-centric 数据管理。

领域现状
核心库单 Aurora MySQL 服务所有业务线（交易/结算/钱包）——单点，阻碍 99.99% SLA
CDC基础 CDC 实现，高峰期有性能问题；下游约 70 个消费者
缓存 / 搜索ElastiCache Redis 35 节点；OpenSearch 19TB（交易检索 + 日志）
流 / 分析MSK Kafka 事件流；EMR Flink on EKS 实时处理；ClickHouse Cloud 分析
日志Splunk 自建（在阿里云侧）
演进方向：业务线隔离（Trading/Settlement/Wallet 独立集群）+ Binlog Replica 级联卸载主库 + MSK 实时 CDC 迁 70 下游消费者；数据湖（S3 + Lake Formation + Iceberg + Athena）支撑监管报告与风险分析。

🎯 AI AI 现状

AI 是客户明确的投入方向；当前 AWS 上尚无生产 AI/ML workload，已在做 AgentCore POC。

AI / AgentCore 切入点 LBank AI 现状 → AWS AgentCore / Bedrock 价值映射：从「比价」转向「运行时底座 + 数据安全 + 用量成本」 客户现状 · AI 栈 AWS 切入 · AgentCore / Bedrock 价值 客户 Agent 平台 · 用户鉴权 自建 agent 编排 + 身份鉴权 已 POC：Bedrock AgentCore 已验证可行，待生产化落地 模型来源：GPT / Codex OpenAI / 微软供给，现主力 拿到 65 折商务价 价格锚点已被设低 Claude MAP 75 折报价 AWS 侧现有商务方案 客户反馈：相对偏贵 纯比价难赢，需换维度 廉价逆向 API 渠道 低价转售 Claude / GPT 代码 / 数据出境风险 无合规保障，隐患大 AgentCore：agent 运行时底座 托管 Runtime + Identity + Memory 承接现有 POC，直接生产化 锁定平台底座，非单纯模型 AI 行业经验分享 交易所 / 金融 Agent 落地案例 最佳实践 + 架构护航 补齐能力，而非只拼价格 解决用量与成本 Prompt 缓存 / 批量 / 用量优化 商务弹性，缩小价差 按真实用量算 TCO，非牌价 数据安全底线 Bedrock 保证不训练 / 不留存 合规通道替代逆向渠道 杜绝代码 / 数据出境风险 承接 POC → 生产底座 补齐能力，非仅比价 价差用商务化解 合规 & 安全 > 便宜 来源：LBank WBR + 6/29·6/30 客户交流
AI 现状与方向：已 POC AgentCore；客服传统人工（6 语言）；开发侧用 LiteLLM 逆向多渠道；方向为 GenAI 客服 + AI 驱动运维 + 开发者效能。
三条 AI 线：① GenAI 客服（Bedrock/Claude + AgentCore + Connect，6 语言 24/7，降客服成本）；② AI 驱动运维（告警降噪 + 根因分析降 MTTR，Splunk→CloudWatch）；③ 开发者效能（IDE + LiteLLM Gateway）。客户对模型质量与数据安全（代码/数据出境）敏感。

🎯 安全 安全 · 数据治理

现状为密码认证 + HIDS 在阿里云 + egress 监控成本较高；机构入驻需统一合规。

领域现状方向
访问管理多账号碎片化、EC2 密码认证（考虑 JumpServer）100% 无密码（Session Manager + Instance Connect）+ 全审计
网络安全基础 SG、微服务隔离有限、egress 监控成本高微服务隔离（mTLS/PrivateLink）+ egress 成本优化
合规审计CloudTrail（4.15M events/月）、Config 基础；HIDS 在阿里云集中监控（GuardDuty + Security Hub + Inspector）+ HIDS 统一
数据治理Secrets Manager（45 secrets）、KMS 静态加密统一数据分类 / 访问策略

🎯 成本 成本结构

客户对成本高度敏感——这是云选型的核心考量之一。

成本现状：AWS 月支出 ~$187K（东京 hub）；份额 AWS 35% / 阿里云 65%；阿里云侧有免费 credits 与折扣。优化空间：RI 扩至 m5zn/m7i（20-30%）、Compute Savings Plans（15-25%）、Graviton 迁移（20%）。云选型综合考量＝成本 + 支持响应 + 平台稳定性。

🎯 机构 机构 / 做市商接入

机构入驻是业务方向。机构与做市商看重低延迟直连与稳定性。

现状与方向：当前散户为主；做低延迟系统（LCM/Aeron）本就是为将来接机构做准备。机构 / 做市商（MM）看重快 + 稳——下单/切单时间不能大波动、主备切换时间敏感。CEX 通常内网做市（延迟差几毫秒收益差数十倍）。接入方式上，机构低延迟直连 / colocation（VPC peering、同 AZ placement）、跨 AZ 数据一致性是需要规划的能力。