第二章 技术选型与架构原则：低延迟、高可用、可扩展性
做券商电子交易系统，说白了就是在跟时间赛跑。我入行那会儿，有个老前辈跟我说过一句话，我一直记到现在：「交易系统里，慢一秒就是亏一个亿，宕一分钟就是丢一城。」这话虽然有点夸张，但道理一点不假。
这一章，咱们就聊聊架构设计的三大核心原则——低延迟、高可用、可扩展性，以及主流技术栈的选型对比。嗯，这里面的坑，我踩过不少，希望能帮你绕过去。
2.1 三大核心原则：一个都不能少
2.1.1 低延迟：从纳秒级开始思考
低延迟是什么？不是「快」，而是「可预测的快」。我见过很多团队，一上来就追求极致性能，结果系统抖动得厉害，关键时刻反而掉链子。
在交易系统中，延迟通常分为几个层次：
- 网络延迟：从客户端到服务器，物理距离决定下限。我记得有家做高频交易的客户，为了省那几微秒，直接把服务器搬到了交易所机房里。
- 处理延迟：CPU 处理、内存访问、锁竞争。这里有个常见的误区——很多人觉得用多线程就能快，其实线程切换的开销有时候比业务逻辑本身还大。
- IO 延迟：磁盘读写、网络 IO。你想想看，一次磁盘寻道的时间，CPU 能执行几百万条指令了。
核心观点：低延迟不是靠单一技术实现的，而是从硬件、操作系统、中间件到应用层，每一层都要优化。我曾经在一个项目中，仅仅是把日志从同步刷盘改成异步批量写入，就把平均延迟从 500 微秒降到了 80 微秒。
2.1.2 高可用：别让「单点」成为你的噩梦
高可用，说白了就是「别挂」。但现实是，系统总会挂。关键是怎么挂，挂了之后怎么办。
我常用的高可用设计手段包括：
- 冗余部署：主备、多活。别把鸡蛋放在一个篮子里。
- 故障转移：自动切换，别等人来修。我曾经遇到过，主节点挂了，备节点因为配置问题没切过来，结果整个交易停了 15 分钟。那 15 分钟，我至今记忆犹新。
- 优雅降级：核心功能保得住，非核心功能可以砍。比如行情推送挂了，至少交易下单不能停。
避坑指南：我曾经以为「多副本」就万事大吉了，结果发现副本之间的数据同步延迟，导致用户看到的价格不一致。后来我们引入了「强一致性 + 本地缓存」的方案，才解决了这个问题。
2.1.3 可扩展性：别让架构成为业务增长的瓶颈
可扩展性，就是「能扛得住增长」。我见过不少系统，一开始跑得挺欢，用户一多就崩了。为什么？因为架构设计时没考虑扩展。
可扩展性通常分两种：
- 垂直扩展：加 CPU、加内存。简单粗暴，但有上限。
- 水平扩展：加机器。这才是正道。但水平扩展有个前提——你的系统得是无状态的，或者状态管理得好。
我个人习惯，在设计初期就把「无状态化」作为默认原则。每个服务节点都不保存用户会话，所有状态都丢到 Redis 或数据库里。这样，加机器就像加乐高积木一样简单。
2.2 主流技术栈对比：Java / C++ / Go
选技术栈，就像选兵器。没有最好的，只有最合适的。下面这张图，是我自己总结的选型逻辑：
2.2.1 C++：极致性能的代价
C++ 在交易系统里，尤其是高频交易领域，地位不可撼动。为什么？因为它能让你直接操作内存、控制 CPU 缓存、甚至绑定 CPU 核心。
我见过一个用 C++ 写的行情解码模块，从网卡收到数据包到应用层拿到行情，延迟只有 2 微秒。换成 Java，同样的逻辑，至少 10 微秒起步。
但 C++ 的代价也很明显：开发效率低、容易出内存问题、调试困难。我曾经花了一周时间，就为了追一个野指针导致的偶发崩溃。嗯，那滋味，不想再体验第二次。
我的建议：如果你的系统需要纳秒级响应，比如做市商策略、套利引擎，C++ 是唯一选择。但如果是业务逻辑复杂的后台服务，慎重。
2.2.2 Java：生态为王
Java 在券商系统里，是绝对的主力。为什么？因为它的生态太强了。Spring Boot、Netty、Kafka、Redis 客户端……几乎你能想到的中间件，都有成熟的 Java 版本。
而且，Java 的 JIT 编译器经过多年优化，在大多数场景下性能已经非常接近 C++。我做过一个对比测试：同样的交易路由逻辑，Java 版本的平均延迟是 50 微秒，C++ 版本是 30 微秒。差距不大，但 Java 的开发效率高了一倍不止。
不过，Java 有个天生的短板——GC 停顿。虽然 G1、ZGC 已经大幅改善了这个问题，但在极端低延迟场景下，GC 依然是个隐患。我习惯的做法是：把 GC 日志打开，定期分析，必要时用「对象池」来减少 GC 压力。
2.2.3 Go：后起之秀
Go 是近几年在金融科技圈火起来的。它的优势很明确：并发模型简单（goroutine）、编译快、部署方便（单二进制）。
我最近一个项目，用 Go 重写了原来的 Java 网关层。结果呢？内存占用从 2GB 降到了 200MB，启动时间从 30 秒降到了 1 秒。而且，Go 的 goroutine 在处理大量长连接时，比 Java 的线程模型优雅得多。
但 Go 也有不足：生态不如 Java 丰富，泛型支持刚完善，第三方库的质量参差不齐。如果你要用 Go 做核心交易引擎，我建议先做充分的 POC（概念验证）。
2.3 选型决策矩阵
下面这个表格，是我在实际项目中总结的选型参考。你可以根据自己的场景，对号入座：
| 维度 | C++ | Java | Go |
|---|---|---|---|
| 极致低延迟 | ★★★★★ | ★★★☆☆ | ★★★★☆ |
| 开发效率 | ★★☆☆☆ | ★★★★★ | ★★★★☆ |
| 生态丰富度 | ★★★☆☆ | ★★★★★ | ★★★☆☆ |
| 并发模型 | ★★★☆☆ | ★★★★☆ | ★★★★★ |
| 运维复杂度 | ★★★☆☆ | ★★★☆☆ | ★★★★★ |
| 人才储备 | ★★☆☆☆ | ★★★★★ | ★★★☆☆ |
我的个人经验：没有「银弹」。我见过用 Java 做高频交易的，也见过用 C++ 写业务逻辑的。关键是要搞清楚你的核心瓶颈在哪里。如果延迟是命门，C++ 没得选；如果业务复杂、迭代快，Java 更稳妥；如果追求轻量和并发，Go 值得一试。
2.4 架构原则落地：一个简单的例子
说了这么多理论，咱们来看一个实际例子。假设我们要设计一个「订单路由系统」，它需要把用户的订单发到不同的交易所。
低延迟怎么做？
- 用 Netty（Java）或 epoll（C++）做异步 IO，避免线程阻塞。
- 订单数据用直接内存（DirectBuffer）传输，减少拷贝。
- 核心路径上不要加锁，用无锁队列（Disruptor）处理。
高可用怎么做？
- 部署两个实例，一主一备，用 Keepalived 做 VIP 漂移。
- 订单状态持久化到数据库，备机启动时自动恢复。
- 交易所连接断开时，自动重连并补发未确认的订单。
可扩展性怎么做？
- 按交易所分片，每个分片独立部署。
- 用一致性哈希做请求路由，加机器时只影响少量数据。
- 配置中心统一管理，新节点启动时自动拉取配置。
避坑指南：我曾经在设计订单路由时，把「交易所连接」和「业务逻辑」放在同一个进程里。结果一个交易所连接超时，导致整个进程卡住。后来我学乖了，把连接管理独立成一个代理层，业务逻辑和网络通信彻底解耦。
好了，这一章的内容就到这里。技术选型和架构原则，说白了就是「权衡」二字。没有完美的方案，只有最适合你当前场景的方案。下一章，咱们聊聊具体的网络通信模型，看看怎么把「低延迟」从理论变成现实。