我与 IT 这三十年：1999，socket 第一次连到生产系统

原创

已于 2026-07-14 11:35:00 修改 · 399 阅读

于 2026-07-14 11:31:05 首次发布

1999，socket 第一次连到生产系统

1998 年，我写的是 MIS，是表单、字段、数据库和报表。

到了 1999 年，表单开始连上更硬的东西。

那一年，我给银行做开发，使用 SCO UNIX 做前置机，真正在生产环境里使用 socket 编程。现在看这句话很平常，甚至有点老派。可是对当时的我来说，这是软件责任感发生变化的一年。

以前写程序，更多是在自己的机器、部门内部系统或者相对可控的环境里打转。错了可以改，慢了可以调，重启一下也未必是什么大事。银行系统不一样。它连着交易，连着柜台，连着用户的钱，也连着一套不能随便停、不能随便错、不能只靠“应该没问题”上线的生产秩序。

socket 也不再只是书上的 API。

它变成了一条真实的线。

线的这一头，是你写的程序；线的另一头，是一个更大的系统。

前置机这个词，带着年代感

“前置机”这个词，现在听起来有些古老。

但在 1990 年代末和 2000 年代初，它是很多行业系统里非常关键的一层。银行、证券、电信、税务、社保，各种核心系统都不会让外围业务系统随便直连。中间通常会有一层前置系统，负责协议转换、连接管理、报文收发、日志记录、权限隔离、异常处理。

它像一个门房，也像一个翻译。

柜台系统或者业务系统发来请求，前置机按约定格式组包，通过 socket 发到后端主机或者核心系统。返回结果再被解析、转换、记录，然后交回前端。今天我们会用 API Gateway、消息队列、服务网格、负载均衡、观测平台讲类似事情；当时的很多系统，则是更直接的 UNIX 进程、TCP 连接、固定格式报文和日志文件。

前置机的价值在于，它站在不稳定的边界上。

外部系统可能慢，网络可能断，核心系统可能返回错误，报文可能不合法，柜台人员可能重复操作。前置机不能只做“转发”。它要知道什么时候等待，什么时候超时，什么时候重试，什么时候拒绝，什么时候把问题写进日志，什么时候必须人工介入。

这些东西在教科书里不难理解。

到了生产系统里，每一个选择都变得具体。

超时时间设短了，正常交易可能失败；设长了，前端用户会一直等。日志太少，出问题查不到；日志太多，磁盘和性能又会受影响。错误码设计不清楚，业务人员看不懂；错误处理太随意，问题会被吞掉。

这就是生产系统给程序员上的第一课：代码不是只要能跑，还要能解释、能追溯、能承受现实。