第二章：核心需求分析

做交易网关，说白了就是跟时间赛跑。我这些年经手过好几个交易系统项目，每次跟业务方聊需求，他们翻来覆去就那几句话：「要快、不能断、别出事、以后好扩展」。嗯，这四个词背后，其实藏着不少门道。

2.1 低延迟要求

低延迟是交易网关的命根子。我见过太多团队，一上来就堆技术栈，结果延迟反而上去了。为什么会这样？因为没搞清楚延迟到底从哪来。

我个人习惯把延迟拆成三块：

• 网络延迟：数据在网线上跑的时间。这个物理定律没法破，但我们可以缩短路径。比如把网关部署在交易所机房里，或者用FPGA做硬件加速。
• 处理延迟：CPU处理数据包的时间。这里坑最多。我记得有个项目，团队用了Java的垃圾回收，结果每几秒就卡一次。后来换成C++，延迟直接降了一个数量级。
• 排队延迟：请求在队列里等着被处理。很多人忽略这个。你想想看，如果网关处理不过来，请求就会堆积，延迟自然就上去了。

我曾经在一个项目中，发现延迟总是忽高忽低。排查了三天，最后发现是网卡的中断合并（Interrupt Coalescing）搞的鬼。关掉之后，延迟曲线立马平滑了。这种细节，文档上不会写，只能靠实战积累。

2.2 高可用性设计

交易网关不能挂。挂了就是真金白银的损失。我见过最惨的一次，某券商网关宕机10分钟，客户直接索赔几百万。

高可用性设计，我建议从三个维度入手：

维度	策略	说明
冗余部署	主备模式、多活模式	至少两套网关同时运行，一台挂了另一台立刻接管
故障检测	心跳检测、健康检查	每100毫秒检查一次，连续3次失败就触发切换
快速恢复	自动重启、状态同步	网关崩溃后自动拉起，从对端同步会话状态

这里有个关键点：高可用不是靠一个组件就能搞定的。你得从网络层、应用层、数据层都做冗余。说白了，就是不能有单点故障。

2.3 安全性需求

交易网关是金融系统的门户，安全防线一旦被突破，后果不堪设想。我参与过几次安全审计，发现最常见的问题其实不是加密强度不够，而是「该加密的地方没加密」。

安全性需求，我总结为四个层面：

1. 传输安全：所有网络通信必须加密。TLS 1.2以上是底线，我个人建议直接用TLS 1.3，性能更好。
2. 认证授权：每个请求都要验证身份。API Key + 签名是最基本的，敏感操作还要加二次认证。
3. 防重放攻击：每个请求带时间戳和随机数，服务端做去重。我记得有个项目没做这个，结果被攻击者重放订单，差点出事。
4. 风控检查：交易前做实时风控。比如检查账户余额、交易频率、异常模式等。

2.4 可扩展性需求

交易量是会增长的。你今天设计的时候觉得够用，明年可能就不行了。可扩展性说白了就是：加机器就能扛更多流量。

我建议从两个方向考虑：

• 水平扩展：多台网关实例并行处理。关键是要做到无状态设计，这样加实例就像加筷子一样简单。
• 垂直扩展：单台机器用更强的硬件。比如用多核CPU、大内存、高速网卡。但垂直扩展有天花板，所以水平扩展才是王道。

你想想看，如果网关里存了会话状态，那水平扩展就麻烦了。新来的请求可能被路由到没有状态的实例上。所以，我习惯把状态放到外部存储里，比如Redis或者共享内存。

嗯，这四个需求其实是有冲突的。比如高可用需要冗余，但冗余会增加延迟。安全加密会消耗CPU，影响性能。所以实际设计时，你得做权衡。我个人习惯是：先保证延迟达标，再考虑高可用和安全，最后做扩展性。

这张图把四个核心需求的关系画清楚了。它们不是孤立的，而是相互影响的。比如你为了低延迟砍掉了安全加密，那系统就暴露在风险中。所以，设计时得找到那个平衡点。