凌晨两点，我盯着nginx的错误日志，第无数次把`proxy_pass`指向的端口从8080改成8081。隔壁工位的Java小哥已经靠着椅子睡死过去，咖啡杯里浮着半只飞蛾。这不是什么科幻场景——我们正在给一个老旧的单体应用做web服务扩展，而这场手术的第一刀，就切在了负载均衡上。

web服务扩展的本质，是让系统在流量洪峰来临时还能喘口气。但别急着上Kubernetes，先看看你手边的nginx配置。很多团队把扩展想得太玄乎，其实第一步往往简单粗暴：多开几个进程，让CPU核心别闲着。我见过一家做在线教育的公司，他们的服务器配置堪称豪华，32核的机器只跑着单进程的Node.js。压测时CPU使用率不到15%，请求却已经超时。加个`cluster`模块，把进程数调到和核心数一致，吞吐量立刻翻了四倍。有时候扩展不是加机器，是把你已有的机器榨干。

但进程再多也扛不住数据库这堵墙。去年双十一，某电商平台的订单服务在扩容到20个节点后突然崩溃——不是服务本身挂了，是MySQL的连接数被打满。每个节点默认开100个连接池，20个节点就是2000个连接，而数据库的`max_connections`只有500。这种事故太典型了，代码层面毫无问题，纯粹是资源协调的失误。解决方式也不复杂：给连接池设上限，或者引入中间件做连接复用。可就是这么个低级错误，能让整个技术团队在凌晨三点集体清醒。

说到中间件，Redis几乎成了扩展的万金油。把热点数据从数据库挪到缓存里，响应时间能从80毫秒降到2毫秒。但这玩意儿用不好就是定时炸弹。有个做社交产品的朋友跟我吐槽，他们为了扩展把用户会话全塞进Redis，结果Redis一重启，全体用户被迫重新登录。后来换了Redis Cluster，又碰上缓存穿透——某个不存在的用户ID被恶意刷，请求绕过缓存直击数据库，直接把主库打挂了。扩展不是堆组件，你得想清楚每个组件在崩溃时会发生什么。

真正的扩展高手都在做无状态化。把用户的登录状态从session里挪到JWT令牌中，把上传的文件从本地磁盘挪到对象存储，把定时任务从进程内调度挪到独立的消息队列。这个过程很痛苦，尤其当你面对的是十年前写的老代码，session里塞了一堆业务数据，改起来牵一发动全身。但一旦完成，你会发现扩展变得异常轻松——随便加节点，随便缩容，服务之间互不牵连。

我见过最极端的案例，是一家做直播弹幕的创业公司。他们的服务端架构简单到令人发指：一台nginx做负载均衡，后面挂着三台无状态的应用服务器，共享一个Redis存弹幕历史。弹幕量暴涨时，他们做的事情就一件：在云控制台上点“创建实例”，新服务器自动从镜像启动，加入负载均衡池，整个过程不到三分钟。没有编排系统，没有服务发现，就因为应用层彻底无状态。这种朴素的做法，比那些上了全套微服务却连配置中心都搞不定的团队，不知道高到哪里去了。

扩展这条路上没有银弹。Kubernetes能帮你管理容器，但管不了你代码里的共享可变状态；Service Mesh能处理服务间通信，但治不了你SQL里的笛卡尔积。我见过太多团队，一谈扩展就想着上最时髦的架构，结果把简单问题复杂化。写到这里，天快亮了。Java小哥醒过来，揉着眼睛问测试结果怎么样。我看着监控面板上平滑的曲线，说：这次咱们连一行代码都没改，就是调了调参数，把连接池和缓存策略优化了一下。他愣了半天，蹦出一句：就这？是啊，就这。扩展很多时候不是造火箭，是拧螺丝，只是你得知道该拧哪颗。