第22章部署与运维

22、部署与运维：服务器选型、Docker容器化、CI/CD流水线、灰度发布

做市系统写好了代码，跑通了回测，接下来就是最现实的问题——怎么让它稳定地跑在线上。

说实话，很多量化团队死就死在这一步。策略再牛，服务器一挂、网络一抖、部署出错，全是白搭。我自己早期就吃过这个亏，半夜三点爬起来重启进程，那滋味……嗯，不想再体验了。

核心观点：做市系统的运维，本质上是在「低延迟」和「高可用」之间找平衡。别追求极致，先追求稳定。

一、服务器选型：别在硬件上省钱

做市交易对服务器要求其实很明确：CPU要快，内存要大，网络要稳。但很多人一上来就盯着顶级配置，我觉得没必要。

我个人习惯这样选：

CPU：高频优先，核心数够用就行。做市逻辑大多是单线程事件驱动，核心多了用不上。我一般选 Intel Xeon Gold 系列，主频 3.0GHz 以上。
内存：至少 64GB。订单簿、历史数据、风控状态全在内存里，别省这点钱。
硬盘：NVMe SSD，容量不用太大，500GB 足够。日志和快照写盘要快。
网络：双网卡绑定，10Gbps 起步。最好托管在交易所同一机房或相邻机房。

组件	推荐配置	避坑点
CPU	Intel Xeon Gold 6xxx, 3.0GHz+	别买AMD EPYC，某些交易所的FPGA加速卡不兼容
内存	64GB - 128GB DDR4 ECC	ECC必须，内存错误会导致订单簿数据错乱
硬盘	NVMe SSD 500GB+	别用SATA SSD，写入延迟差一个数量级
网络	双10Gbps网卡，bonding模式	单网卡挂了你就等着穿仓吧

我曾经踩过的坑：有一回贪便宜用了云服务器，结果交易所行情推送延迟从50微秒飙到2毫秒。做市策略直接亏了三天利润。从那以后，我坚持用物理机托管。

二、Docker容器化：环境一致性是命根子

做市系统最怕什么？「在我电脑上跑得好好的」。Docker就是来解决这个问题的。

我建议把整个做市系统拆成几个容器：

行情容器：负责接收交易所行情，解析后推送到内部消息队列
策略容器：运行核心做市逻辑，计算报价
风控容器：独立进程，监控所有风险指标
日志容器：收集所有日志，写入远程存储

下面是一个典型的 Dockerfile 示例，注意我用了多阶段构建来减小镜像体积：

# 第一阶段：编译
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o marketmaker .

# 第二阶段：运行
FROM alpine:3.18
RUN apk add --no-cache ca-certificates tzdata
COPY --from=builder /app/marketmaker /usr/local/bin/
EXPOSE 8080
CMD ["marketmaker"]

小技巧：基础镜像用 alpine 能省不少空间。我见过有人用 ubuntu 做基础镜像，一个容器 1.2GB，部署 10 个节点硬盘直接爆了。

三、CI/CD流水线：自动化是唯一出路

手动部署做市系统？别闹了。一次误操作可能就导致几百万的损失。

我搭建的 CI/CD 流水线一般分四步：

代码提交触发构建：GitHub/GitLab Webhook 触发 Jenkins 或 GitLab CI
自动化测试：跑单元测试、集成测试、回测验证
构建镜像：自动打标签，推送到私有镜像仓库
部署到测试环境：先部署到 staging，跑 30 分钟模拟交易

下面是一个 .gitlab-ci.yml 的简化版本：

stages:
  - test
  - build
  - deploy

unit_test:
  stage: test
  script:
    - go test ./...
    - go vet ./...

build_image:
  stage: build
  script:
    - docker build -t registry.internal/marketmaker:$CI_COMMIT_SHORT_SHA .
    - docker push registry.internal/marketmaker:$CI_COMMIT_SHORT_SHA

deploy_staging:
  stage: deploy
  script:
    - kubectl set image deployment/marketmaker-staging marketmaker=registry.internal/marketmaker:$CI_COMMIT_SHORT_SHA
  only:
    - main

关键点：CI/CD 流水线里一定要加「回滚」步骤。我习惯在部署脚本里保留最近 5 个版本的镜像，一旦发现异常，一键回滚。

四、灰度发布：别拿生产环境当小白鼠

做市系统不像普通网站，挂了可以等一会再修。你想想看，策略一停，流动性就没了，做市商身份可能直接被交易所取消。

灰度发布的核心思路：让新版本先服务一小部分流量，观察没问题再全量切换。

我常用的灰度策略有两种：

按交易对灰度：新版本只负责 BTC/USDT 这个交易对，其他交易对还是老版本处理
按资金比例灰度：新版本只分配 10% 的资金，亏完了就停，不影响主账户

具体实现上，我习惯用 Nginx 或 Envoy 做流量分发：

upstream marketmaker {
  server 10.0.1.10:8080 weight=90;  # 老版本，90%流量
  server 10.0.1.11:8080 weight=10;  # 新版本，10%流量
}

server {
  listen 443 ssl;
  location / {
    proxy_pass http://marketmaker;
  }
}

注意：灰度发布期间一定要监控「成交率」和「滑点」这两个指标。我曾经有一次灰度，新版本成交率下降了 5%，但滑点改善了 0.1 个 tick。最后发现是报价频率太高导致成交率下降，得不偿失。

五、知识体系总览

下面这张图是我自己总结的做市系统部署运维架构，你可以对照着看：

说白了，部署运维这件事，就是把你写好的策略代码，安全、稳定、可回滚地放到线上跑。别追求花里胡哨的工具，先把基础打牢。

最后说一句：做市系统上线后，前两周是最关键的。我建议你每天凌晨三点起来看一次监控——别问我为什么知道这个时间点。

交易系统化学习资料微信Strategy888888

📚 课程目录

22、部署与运维：服务器选型、Docker容器化、CI/CD流水线、灰度发布

一、服务器选型：别在硬件上省钱

二、Docker容器化：环境一致性是命根子

三、CI/CD流水线：自动化是唯一出路

四、灰度发布：别拿生产环境当小白鼠

五、知识体系总览