实战SOP:CodeArts用Go重铸Python服务

背景:Python 服务稳不住,优化到了尽头

手上有个内部数据同步服务,Python 写的,日均处理几十万条记录。功能不复杂:拉上游数据、做转换、写库、回执。但稳定性一直是个心病,症状很典型:

• 内存缓慢上涨,几天后 OOM 被系统杀掉,重启恢复;
• 高峰期延迟抖动,P99 忽高忽低,GIL 争抢一严重全服务一起慢;
• 升级一个依赖库就崩,依赖树里某个包不兼容,排查要半天;
• 部署依赖重,venv、系统库、编译工具链,换台机器就得重来。

试过优化:加内存、开多 worker、换异步框架、给热点函数加缓存。每样都有点用,但都是治标——内存涨得慢了,还是会涨;延迟抖得轻了,还是会抖。

最后做了个决定:整个服务重铸为 Go,行为不变,一个字都不许改。这件事交给码道 CodeArts 主力完成,我做裁判。

方案:重铸不是翻译,是重写纪律

重铸最容易犯的错,是"照着 Python 逐行翻译"。这样翻出来的 Go,要么把异常吞掉,要么把 asyncio 的并发模型硬塞进 goroutine,稳定性不升反降。CodeArts 的做法是先立纪律,再动手:

1. 先拍金标准,再动一行代码:

# 用真实样本构造用例:输入 JSON + 期望输出 JSON + 期望错误码
fixtures/
  001-normal.json         # 正常记录
  002-empty-batch.json    # 空批次
  003-bad-field.json      # 字段缺失,期望 400
  004-upstream-timeout.json # 上游超时,期望 504

这些用例是重铸的唯一裁判:两套服务输出必须一字不差。没有它,"行为不变"就是一句口号。

2. Go 版的结构(与 Python 模块一一对应):

type Service struct {
    db      *sql.DB
    client  *http.Client
    limiter *rate.Limiter
}

func (s *Service) Sync(ctx context.Context, batch []Record) (Report, error) {
    ctx, cancel := context.WithTimeout(ctx, 30*time.Second)
    defer cancel()

    if err := validate(batch); err != nil {
        return Report{}, &APIError{Code: 400, Err: err}
    }
    rows, err := s.fetchUpstream(ctx, batch)
    if err != nil {
        return Report{}, &APIError{Code: 504, Err: err}
    }
    return s.persist(ctx, rows)
}

三个细节值得说:context 带超时,链路任何一段卡住都不会拖死整个请求;错误显式返回并带业务码,不再靠异常穿透;http.Client 与连接池在启动时一次性配好。

3. 双端对拍:

# 同一批 fixture 分别打两套服务,逐字比对
for f in fixtures/*.json; do
  py=$(curl -s -X POST localhost:8000/sync -d @$f)
  go=$(curl -s -X POST localhost:8080/sync -d @$f)
  if [ "$py" != "$go" ]; then
    echo "DIFF: $f"
    diff <(echo "$py" | jq -S .) <(echo "$go" | jq -S .)
  fi
done

对拍跑通的那天,才允许谈切流。

4. 灰度切流。 按 1% → 10% → 50% → 100% 分四档,每档至少观察一天:错误率、P99 延迟、内存曲线、日志异常量。任何一项劣化超过阈值就回滚——回滚路径必须提前演练过,不能等出事才翻文档。

实践要点

1. 先有金标准,再谈重写。 行为不变的重铸,测试就是唯一裁判。用例要覆盖正常路径、空输入、非法字段、上游超时、超大批次——覆盖不到的边界,翻译时最容易走样。
2. 错误处理必须显式。 Python 的异常是隐式抛出,Go 的 error 是返回值。翻译时每个 except 都要有对应的 if err != nil,并且保留原错误码。CodeArts 在翻译时会特意标注"这一处 Python 吞掉了异常",让我确认是要保持吞掉还是改成显式返回。
3. 超时和重试要在代码里看得见。 Go 的默认 http.Client 没有超时,不显式设置就是无限等待。context 超时、连接池上限、重试次数,这三样必须写在配置里,不能靠库的默认值。
4. 并发模型要重做,不是照搬。 asyncio 是单线程事件循环,goroutine 是多线程调度。把前者硬套后者,会出现共享状态竞争。CodeArts 的做法是:先在 Python 侧标出所有共享状态,再在 Go 侧给出对应的同步方案(互斥锁、channel 或原子操作),不搞"看着像"的翻译。
5. 换了语言不等于内存没有问题。 Go 的 GC 也需要边界:GOGC 与 GOMEMLIMIT 配合容器内存上限设置,否则大对象短时间暴增照样 OOM。上线前压测一次内存曲线,比任何理论都可信。
6. 观测先行,切流在后。 指标、结构化日志、链路追踪,在切流前就要对齐,否则灰度期间出了问题,你连"哪套服务在慢"都判断不了。

收官:数字说话

重铸后跑了三周:内存曲线是一条平直的线,不再缓慢爬升;P99 延迟的高峰抖动消失,峰值时段也稳定;部署从"装依赖半小时"变成"拷一个二进制"。最意外的好处是排障:Go 的 panic 栈和 pprof 让一次线上问题的定位从半天缩短到十几分钟。

当然,代价也要说清楚:重铸投入了两周的开发时间,Go 版本代码量比 Python 多,类型和错误处理是实打实的写法成本。这笔账是否划算,取决于服务的重要程度——对核心链路,稳定性值这个价;对一次性脚本,就不值。

小结

这次重铸最大的收获,不是学会了 Go,而是明白了一件事:稳定性不是语言给的,是纪律给的。金标准用例、显式错误、显式超时、对拍验证、灰度切流——这五条里任何一条缺失,换什么语言都不稳。CodeArts 的价值,是把这套纪律变成可执行的任务书:每一步都有产物,每一处"行为可能变了"都会被指出来让我确认。