一、量化交易与微服务架构概述
1.1 量化交易的基本概念
量化交易，说白了就是用数学模型代替人的直觉做决策。我入行那会儿，很多人觉得这就是「写代码炒股」，其实远没那么简单。
一个典型的量化系统，核心就三件事：
- 数据——行情、财务、舆情，缺一不可
- 策略——信号生成、回测、优化
- 执行——下单、风控、成交反馈
举个例子，你写了个均线策略：当5日均线上穿20日均线时买入。听起来简单吧？但实际跑起来，数据延迟、网络抖动、交易所接口异常……任何一个环节出问题，策略就废了。
核心要点：量化交易的本质是「用确定性流程应对不确定性市场」。流程越复杂，对系统架构的要求就越高。
1.2 微服务架构的优势
传统量化平台喜欢搞「大单体」——一个进程里塞满所有功能。我早期参与的一个项目就是这样，行情、策略、风控全揉在一起。结果呢？改一行风控代码，整个系统要重新部署。有一次上线前发现行情模块有bug，但策略模块已经验证通过了，愣是等了两天一起发版。
微服务架构把这些问题拆开了。每个服务独立部署、独立扩展、独立维护。你想想看：
- 行情服务——只负责接入交易所数据，高吞吐、低延迟
- 策略服务——只跑模型，不关心数据从哪来
- 风控服务——独立校验每笔订单，出问题只影响它自己
- 订单服务——统一管理下单、撤单、成交回报
这样做的好处很明显：
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 部署 | 全量部署，牵一发动全身 | 独立部署，按需更新 |
| 扩展 | 整体扩容，资源浪费 | 按服务粒度扩，精准控制 |
| 故障隔离 | 一个bug拖垮整个系统 | 单个服务故障，不影响全局 |
| 技术栈 | 统一语言、统一框架 | 各服务可选用最适合的技术 |
我的经验：微服务不是银弹。服务拆得太细，运维成本会爆炸。我个人习惯是：先按业务边界拆，每个服务至少能独立完成一个「完整业务动作」。比如「下单」就是一个完整动作，而「计算均线」只是策略服务内部的一个步骤。
1.3 为什么量化平台需要网关
好，现在系统拆成微服务了。问题来了：客户端怎么调用？
你想想看，一个量化平台可能有：
- Web端查看账户、策略
- 手机App接收预警
- 自动化交易程序直接下单
- 第三方系统接入查询数据
如果每个客户端都要知道所有服务的地址、端口、鉴权方式……那维护起来就是噩梦。我曾经见过一个团队，光维护客户端和服务端的接口文档就用了三个人。
网关就是来解决这个问题的。它作为系统的「统一入口」，承担了以下职责：
- 路由转发——客户端只认网关，网关帮你找到对应的微服务
- 身份认证——所有请求先过网关，鉴权通过才放行
- 限流熔断——防止某个客户端把系统打爆
- 协议转换——客户端用HTTP，内部服务用gRPC，网关帮你转
- 日志监控——所有请求的入口，天然适合做全链路追踪
避坑指南：我曾经在一个项目里把网关当成了「万能代理」，什么逻辑都往网关里塞。结果网关成了新的单体瓶颈。记住：网关只做「跨服务」的事，不做「服务内部」的事。比如「校验用户权限」是网关的事，但「校验订单金额是否足够」是订单服务的事。
下面这张图展示了量化平台中网关的核心位置：
从图上可以清楚看到：所有客户端只和网关打交道。网关背后，微服务之间通过内部网络通信。这样做的好处是——客户端不需要知道系统内部有多少服务、服务部署在哪里、用什么协议。网关把这些复杂性全屏蔽了。
总结一下：量化交易对延迟、稳定性、安全性要求极高。微服务架构帮我们拆解了复杂度，而网关则是把这些拆散的服务「重新粘合」起来的关键组件。没有网关，微服务就是一盘散沙。
嗯，这一章先聊到这儿。量化交易和微服务架构的底层逻辑，你大概有个印象了。下一章我们深入网关的核心功能——路由与负载均衡，看看网关到底是怎么「指哪打哪」的。