市场在剧烈震荡之前并不会发出会议邀请。突如其来的降息、意料之外的选举结果或突发的地缘政治摩擦，都可能在几秒钟内导致资产价格剧烈波动。交易员们会迅速冲向屏幕，买单和卖单堆积如山。你的基础设施必须能够吸收这种冲击而不会出现卡顿。当交易量在几分钟内激增十倍时，速度变慢、订单失败或彻底宕机绝非小事，它们是信任的杀手。
构建一个能在这些时刻幸存的交易平台，意味着要及早做出架构选择。如果设计过于脆弱，单纯依靠蛮力提升算力是救不了你的。以下是如何处理这个问题的方法，而不是仅仅将波动视为简单的流量激增。
从具有弹性的云基础设施开始
僵化的硬件是你的敌人。如果你按照平均每日交易量来配置服务器，那么在交易激增时你会面临崩溃；如果你按最极端的情况来配置，那么在一年中的其他时间，你将会在闲置机器上浪费大量资金。
云基础设施通过自动扩缩容（auto-scaling）解决了这个问题。计算能力应该随着需求自动增长。在平静的周二上午，你可以精简运行。当就业报告发布且订单流增加三倍时，新的实例会自动启动以分担负载。关键在于配置反应足够快的扩缩容策略。应根据请求队列深度、CPU 利用率和网络吞吐量来设置阈值，而不是凭感觉猜测。此外，还要将你的架构分布在不同区域。不同时区的交易员不应在没有必要的情况下争夺同一个计算池。区域冗余可以保持低延迟，并在某个数据中心出现问题时提供回退方案。
将平台拆分为微服务
将所有内容运行在一个庞大的代码库中，就像把所有的鸡蛋都放在一个篮子里然后开始冲刺。在单体应用中，投资组合图表工具中的内存泄漏可能会导致你的订单执行引擎崩溃。在波动剧烈的市场中，这种耦合是不可接受的。
将平台拆分为独立的微服务。将用户身份验证与市场数据摄取分开处理。将订单执行与投资组合管理和支付处理隔离。当某个组件面临重负载时，你可以对其进行扩容，而不会干扰系统的其他部分。例如，如果某只模因股（meme stock）走红，每个人都想查看价格，你的市场数据服务可以进行扩容，而你的订单执行集群则专门保留用于实际交易。团队可以在周二下午部署支付网关的修复程序，而无需触动撮合引擎。
这种分离需要纪律。你需要清晰的 API、稳健的服务间通信模式以及优雅降级规则。如果投资组合图表在激增期间出现滞后，那只是令人烦恼；但如果订单簿冻结，那就是灾难性的。从一开始就要为故障隔离进行设计。
构建兼顾速度与准确性的系统
在电子交易中，低延迟并非奢侈品。如果你的验证和风险检查增加了不必要的延迟，交易员将会错过他们的价位。即使平台在技术上处于在线状态，用户也会觉得它坏掉了。
订单必须以最小的延迟通过验证和风险评估。这并不意味着要偷工减料，而是意味着要设计计算效率高的检查机制。使用内存数据网格进行信用额度和持仓检查，而不是在每次报价跳动时都查询关系型数据库。在订单到达撮合引擎之前，先在网关处验证订单语法。尽可能并行运行反欺诈和合规规则。
准确性是这个方程式中不可妥协的一半。速度绝不能以牺牲准确性为代价。一个快速但错误的成交比一个缓慢的成交更糟糕。你的系统必须保持严格的