网络应用架构优化技巧

拆分服务，别把鸡蛋放一个篮子里

很多刚开始做网络应用的团队都喜欢搞“大一统”架构，所有功能塞进一个项目里。用户少的时候没问题，一旦流量上来，改个登录逻辑都得全系统重启。后来我们公司一个内部工具就栽在这上面——订单、用户、消息全在一个服务里，发版时经常连带宕机。

后来干脆拆了微服务，用户归用户，订单归订单，用 HTTP 或消息队列通信。虽然运维复杂了点，但局部出问题不影响整体。比如支付模块升级，用户还能正常浏览商品。

缓存不是万能药，但不用真扛不住

有个同事一开始觉得“数据库挺快的”，结果首页查个列表每次都要联表查询五六张表，页面加载直接 3 秒起步。后来加了 Redis 缓存热门数据，接口响应降到 200ms 以内。

关键不是所有数据都缓存，而是识别热点。比如商品详情页、用户权限配置这些读多写少的数据，缓存命中率很高。但像实时交易流水这种频繁变动的，缓存反而可能引发一致性问题。

GET /api/product/{id}
if cache.exists("product:" + id):
    return cache.get("product:" + id)
else:
    data = db.query("SELECT * FROM products ...")
    cache.setex("product:" + id, 3600, data)
    return data

动静分离，别让用户等资源

前端页面里一堆 JS、CSS、图片混在主服务里返回，不仅拖慢接口，还浪费后端资源。我们把静态资源扔到 CDN 上，HTML 里直接引用外链，服务器压力小了一半。

比如把 /static/ 路径映射到对象存储，图片上传也走直传 OSS，回调通知业务系统。用户发个带图帖子，图片上传不再卡住 API 响应。

数据库别只靠索引撑着

很多人优化数据库第一反应就是加索引，确实有用，但表太大时即使有索引也慢。我们有个日志表，每天几百万条，查一个月内的记录经常超时。

后来上了分库分表，按时间每月一张表，查询路由自动匹配。同时冷数据归档到低成本存储，主库只留最近三个月。既省空间，查询也快了。

接口设计要“惜字如金”

早期接口喜欢一股脑返回所有字段，前端用不用都给。结果一个用户信息接口返回 50 个字段，其中一半是废弃的。移动端流量蹭蹭涨，加载还慢。

改成按需返回，用 fields 参数控制输出：/api/user/123?fields=name,avatar,email。后端只查必要字段，传输体积小了 70%。

别忽视超时和降级机制

有一次第三方天气接口抽风，响应十几秒不回来，导致我们的主页也打不开。后来加上调用超时设置，并配本地默认值降级。

比如请求外部服务时设 2 秒超时，失败就返回缓存数据或空占位，至少保证页面能正常展示。用户体验比完全卡住好太多。