App 后端从一台到多台的演进

一台服务器撑起整个 App 后端，这件事在用户过万之前都成立。真正要想清楚的不是什么时候买新机器，而是每一步该先挪走什么。顺序对了，每一步都是平滑过渡；顺序错了，多花钱还多出事故。 一、先分离数据库 增长最早撞上的墙通常是数据库。应用和数据库同机时，备份任务、慢查询、运营报表任何一样都能把接口拖慢。分离的动作是新购一台内存更大的机器做独立数据库，内网打通，选凌晨低峰停写迁移。经验上的触发点：日活过万，或数据库内存占用超过整机一半。 二、再拆静态与上传资源 用户量上来之后，头像、图片、升级包会把应用机的磁盘和带宽吃掉。这一步把对象存储和 CDN（内容分发网络）引进来：上传走对象存储的接口，下载走 CDN 域名，应用机只处理动态请求。带宽压力降下来之后，应用机的配置反而常有富余。 三、最后上负载均衡 前两步做完，应用机只剩动态计算，单台真正扛不住时才轮到负载均衡出场。前提还是那几件旧事：会话进 Redis，定时任务挪出应用进程单独跑，文件不落本地盘。否则两台应用机就会出现任务重复执行、用户随机掉登录的怪象。负载均衡用 Nginx 或云上的均衡服务都行，健康检查配好，机器故障时自动摘除。 四、每一步的验证动作 每次架构调整完成后跑同一组验收：核心接口的 P95 耗时、错误率、数据库慢查询数，和调整前逐项对比。数字变差就回滚排查，别带着疑问往前赶。 顺云产品线里，从云服务器到裸金属 B4 都能承担 App 后端的角色，数据库吃内存就给内存，计算吃 CPU 就加核数，按瓶颈选型即可。演进路线记住三个先后：先库后应用、先静态后动态、先单机后集群，跳步不会更快，只会把风险堆到一起。