我至今记得那个深夜监控大屏上的活跃用户曲线像一根被点燃的引信疯狂向上窜动。凌晨三点数据库连接池报警慢查询日志刷屏应用服务器CPU飙到95%。那是我第一次真正意识到百万级用户不是写出来的是逼出来的。你可以在架构图上画漂亮的微服务网格可以在PPT里吹Kubernetes集群弹性伸缩但当午夜流量洪峰真正拍过来时你手里那套后端技术栈——也许只是几台裸金属、一个PostgreSQL、一堆Go进程——才是唯一的救命稻草。很多团队死在扩容的路上不是因为技术不够新而是因为他们总想用下一套技术栈解决眼前的问题却忘了手里这套已经跑通了业务。今天我不聊云原生不聊Service Mesh就聊聊我是如何用一套朴素且“不酷”的后端技术栈撑起百万级用户的服务。先说清楚背景。我们做的是一款社交类App核心操作是feed流、私信、点赞、关注。用户量从十万冲到百万只用了四个月。技术团队从三个人变成八个人但后端代码库始终只有一个主仓库部署单元也就三个API网关、业务服务、异步worker。多一分则肥少一分则瘦这就是那套技术栈的全部。很多人听到这个会觉得寒酸但事实是支撑百万用户的核心从来不是服务数量而是每一层都能在压力下保持可预测的延迟。可预测比高性能更珍贵。因为当流量翻倍时你能算出数据库什么时候到瓶颈缓存命中率掉多少队列积压多久能消化——这种确定性才是架构师的定心丸。第一道生死关API网关的“降级芭蕾”。我们的网关就是一台Nginx加一层OpenResty脚本后面挂四个业务实例。起初所有接口都走网关转发但百万用户同时在线时热点接口的QPS会瞬间冲破三万。真正的灾难不是请求太多而是依赖太深——一个feed请求要聚合关注列表、内容过滤、推荐排序、未读计数串行调用四个下游。第一次压测时P99延迟飙到8秒用户截图发到微博运维电话被打爆。我干了一件事把网关从“转发器”改造成“薄业务层”。在OpenResty里直接读取热点用户的预聚合feed缓存命中就返回不命中才回源到业务服务。这个改动让80%的feed请求在网关层就被消化掉后端服务压力骤降七成。记住网关不是路由阀门它是第一道缓存边界。很多架构师把网关当纯流量管道这种洁癖在百万级场景下会害死人。但网关层缓存只能缓解读压力写路径才是那座随时可能崩塌的冰山。用户发一条动态要写内容表、刷粉丝时间线、更新用户动态计数、触发推送。如果用同步事务一个写请求会拖垮整个数据库。异步是百万级服务的呼吸节奏强一致是团队内部的自嗨。我们的做法很简单业务服务只做一件事——把消息体原封不动推入Kafka然后立即返回“发布成功”。真正的时间线扇出、计数更新、内容审核全部交给异步worker处理。用户看到的是毫秒级响应后台在几秒内悄然完成所有一致性收敛。这里的关键是你必须容忍短暂的不一致才能换取无限的水平扩展。如果你非要每个写操作都同步更新所有读模型那你的数据库会第一个替你向用户道歉。Kafka选型的时候我们没上集群就用三台普通SSD服务器搭了分区副本。百万用户每天的写消息量大概是两千万条峰值每秒两万条Kafka轻松扛住。真正需要花心思的是消费端的水位管理。刚开始我们用单个group消费所有事件结果某天一个慢消费者堵住了整个管道时间线更新延迟了十五分钟用户疯狂投诉“刷不到新内容”。队列的容错不在于你消费者写得有多聪明而在于你为最慢的那个消费者准备了多少冗余。后来我把时间线扇出拆成三个独立topic普通用户走批量扇出大V用户走单独推送系统通知走低优先级管道。每个topic独立消费组、独立重试队列、独立监控面板。延迟从“全员陪跑”变成“局部可控”这才是异步架构该有的姿态。再说数据库。我们用的是PostgreSQL单主双从没分库分表。百万用户核心业务表数据量在五千万行左右单表查询配合索引完全够用。很多团队在数据量过百万就开始预分库这是对运维复杂度的自我感动。我坚持单库理由很简单跨分片事务是灾难分布式ID是麻烦数据迁移是噩梦。我们只做了两件事一是冷热数据分离三个月前的动态归档到历史库业务表始终保持在一个健康体积二是缓存为王Redis里存全量在线用户状态、热点feed、未读计数命中率常年维持在95%以上。数据库的慢查询日志我每天扫一遍哪个查询吃掉了超过50毫秒立刻优化索引或改写业务逻辑。慢查询是架构的手雷你不拔掉它它迟早在你庆功宴上炸响。缓存的坑比想象中深得多。Redis集群规模不大四十个分片每秒支撑几十万次读写但缓存穿透和击穿会让你欲哭无泪。有一次运营搞活动用户疯狂点击一个不存在的用户主页请求越过Redis直击数据库主库连接数瞬间打满。我们紧急加了布隆过滤器拦截非法key又给空结果也加了一层短TTL缓存才稳住局势。缓存是用来挡子弹的防弹衣不是用来显摆的内存数据库。你必须为它的失效模式做好预案。另一种更隐蔽的坑是缓存与数据库的一致性我们的策略非常简单先写数据库再删除缓存。这样即使删除失败缓存过期后也能恢复脏窗口只有几毫秒到几秒。别迷信那些复杂的双写一致性方案在业务可容忍的瞬时不一致面前简单就是最大的可靠。用户服务必须要聊登录态。百万级用户意味着每秒有上千次token校验如果每次都去数据库查会话那数据库会直接崩溃。我们的方案是用JWT加Redis黑名单。JWT本身无状态网关验签通过就放行把用户态从数据库压力表里彻底抹去。只有用户注销或修改密码时才把token塞进黑名单缓存。这个设计让认证环节几乎零成本。但JWT有个致命弱点无法主动失效。你想踢一个异常用户下线得等token自然过期。架构上任何看似优雅的无状态方案都会在运营干预时露出獠牙。所以我们在网关层维护一个小内存缓存存最近十分钟被强制失效的用户ID校验时先比对这个名单。代价很小但运营和风控功能瞬间变得可控。文件存储也是后端技术栈的一环。用户上传图片和视频我们没有自建对象存储直接用云OSS加CDN。但真正要命的不是存储本身而是上传链路的弱网容忍。百万级用户的网络环境千奇百怪有人在地铁里有人在地下室上传大文件时经常中断。我们做了分片上传和断点续传客户端把文件切成2MB的块每块独立上传服务端组合校验。你永远不要指望用户网络稳定你要做的是让不稳定的网络也能完成操作。同时上传接口单独走一台带宽更充裕的网关避免大数据流量挤占正常的业务请求。很多后端工程师只关注CPU和内存带宽和网络质量同样能把你拖入深渊。监控和告警是那套技术栈里最不起眼却能救命的部分。我们用了Prometheus加Grafana自定义埋点记录每个关键操作的耗时和错误码。没有监控的架构优化等于在黑灯瞎火的房间里闭眼拆炸弹。我给自己定了三条军规每日十点看延迟曲线任何接口P99超过300毫秒就要追查每次发布后立刻对比错误率波动超过0.5%就回滚每周末分析慢查询日志和缓存命中率形成一份一页纸的体检报告。百万级服务的运维不是靠应急抢险而是靠日复一日的枯燥盯梢。还有那个凌晨三点激活的告警电话它不是一个烦人的骚扰而是系统在告诉你你哪里想错了。我最怕的不是告警而是沉默。一个流量巨大的服务如果什么告警都没有只能说明你的监控没覆盖到真正的痛点。说到发布与迭代我们没上微服务也没搞金丝雀复杂网络。一个主仓库一套CI流水线Git打tag自动构建镜像滚动更新到Kubernetes集群。滚动更新解决90%的发布风险剩下的交给回滚脚本。我们每次发布前自动化测试会跑一遍核心链路然后放量到10%的实例观察五分钟错误率再全量。这个过程折腾下来线上更新误差率控制在极低水平。百万级用户最怕的不是发布慢而是发布带病上线。你看很多团队推崇蓝绿部署、流量染色其实对小团队来说一套靠谱的灰度确认脚本比什么花架子都管用。架构的复杂度永远要与团队规模匹配超纲的架构会让维护者变成消防员。最后聊聊心态。百万级用户听起来吓人但拆解下来无非是读写分离、缓存、异步、可观测这四个基本功的排列组合。我们没有用任何时髦的中间件没有引入陌生的大数据组件没有请外部专家做高并发培训。所有技术栈加起来一只手数得过来Go、PostgreSQL、Redis、Kafka、Nginx、Docker/K8s。这些玩意任何一个三年经验的工程师都懂。但懂技术不等于会驾驭技术真正的功力在于知道什么时候该用、什么时候该忍。比如Kafka分区数我们一开始设了24个后来发现消费端瓶颈不在分区而在反序列化逻辑调优了worker的批处理参数就解决了。与其扩分区不如优化你的处理代码这是我踩了无数次坑才学会的教训。支撑百万级用户我最大的心得是做减法比做加法难一万倍。每当你觉得某个模块不够优雅想引入一个新框架重构时请想想你现在这套技术栈已经运行了几个月没有出严重故障。系统稳定的秘诀不是不断更换更好的零件而是让所有零件在极限工况下默契配合。我们也曾心动过要不要上TiDB要不要改成读写分离的分库中间件要不要用ElasticSearch替代模糊查询每次讨论后我都问自己一个问题换上去用户会感受到什么区别如果答案是“更快了一点点”而不是“彻底不卡了”那就别换。百万级服务拼的不是谁技术更华丽而是谁能在业务狂奔时始终稳住阵脚。那套后端技术栈至今还在跑它不性感但它是真实的、可靠的、每行代码都带着生产环境的温度。架构的尽头不是星辰大海而是那些你在深夜里独自修复过的慢查询和队列积压。这就是我的一整套支撑百万级用户的哲学