一个百万级用户App的服务器架构，核心答案只有一句话：别急着一步到位，你的第一版服务器配置够用就行，真正的分水岭在“日活10万”这条线上。这句话不是拍脑袋，而是过去十年移动互联网反复验证过的规律，100万注册用户听着唬人，但日活可能只有几万，一台中等配置的云服务器就扛得住，反过来，如果100万是日活，那问题就不是“怎么弄”而是“怎么扩容”了。
先分清你是哪种100万：注册量不等于并发量
很多创业团队拿到“100万用户”这个数字就慌了，恨不得第一天就上Kubernetes集群，这个思路从一开始就跑偏了，判断服务器需求，看的不是累计注册用户数，而是峰值并发连接数和日活用户数（DAU）,这是两个完全不同的量级。
行业共识认为，移动App的日活通常是注册用户总数的十分之一到二十分之一，也就是说，100万注册用户，日活在5万到10万属于正常范围，再换算成峰值并发多数情况下，同时在线人数不超过日活的十分之一，所以就得出一个关键结论：你的服务器真正要应对的峰值并发，大概率在500到1000之间。
这个量级是什么概念？一台配置稍好的云服务器，配合数据库优化，轻松扛住几千并发，问题是很多团队在架构设计上自己给自己挖坑，比如把图片上传、接口请求、数据库读写全部塞在同一台服务器上,那再好的机器也扛不住。
100万用户App服务器需要什么配置：分阶段对号入座
冷启动期，目标用户数10万以内
这个阶段别过度设计，如果你正在了解100万用户app服务器需要什么配置，先看这套起步方案：一台4核8G的入门级云服务器，带宽按5M起步，系统盘40G起步，数据盘单独挂100G，云厂商选简米云、酷番云、华为云都行,新用户活动价一年几百块就搞定。
架构上保持极简：Nginx做反向代理，后端直接跑单体应用（比如Java的Spring Boot或Go的Gin），数据库用MySQL单实例，再加一个Redis做缓存，这个阶段的核心任务是验证产品，不是炫技，唯一要注意的是，把静态资源（图片、视频）走对象存储,别占服务器本地磁盘。
成长期，日活破万
当你的日活稳定超过1万，就得开始拆服务了，这里最标准的操作是读写分离：MySQL主库负责写入，从库负责读取，读写比例至少是1比5，再上CDN把静态资源分发出去,源站压力直接砍掉一半。
此时服务器配置升级到8核16G起步，应用服务器一台、数据库服务器一台、缓存服务器一台，三台机器组成最小集群，别想着用物理服务器，云服务器随时能升配,弹性才是这个阶段最需要的。
成熟期，日活10万以上
到了这个量级，你再问服务器怎么弄，答案就变成“平台化”，容器化部署（Docker加Kubernetes）成为刚需，微服务拆分按业务模块走，数据库要考虑分库分表，这个阶段没有标准答案,全看你的业务场景。
预算失控怎么办：App服务器租用价格如何计算
很多团队在服务器上的预算规划是拍脑袋做的，服务器成本有一条基本规律：80%的预算应该花在数据库和网络上，而不是CPU上，大家最常犯的错误是买了一堆高配计算型服务器，结果数据库连不上、带宽不够用。
如果是预算有限的创业团队,可以参考这个成本模型：
- 初期月成本控制在1000元以内：1台4核8G服务器（约300-500元每月）加1台2核4G数据库服务器（约200-300元每月）
- 成长期月成本在3000到5000元：应用服务器2台、数据库主从2台、Redis 1台、CDN流量费另算
- 成熟期月成本1万元起步：这个阶段按量付费比包年包月划算，配合容器化能省下不少
另外一个容易被忽略的坑是带宽，云服务器的带宽费用比CPU贵得多，5M带宽一个月就要几百块，100M带宽一个月可能上万，正确做法是默认按流量计费，配合CDN把大头流量消化掉，同城双活或异地多活的架构，普通创业团队现阶段不必考虑,先把单区域做扎实。
高并发架构避坑指南：从一台服务器开始做对三件事
第一件事：数据库连接池必须开
不管你的App现在有多少用户，数据库连接池一定要从一开始就配置好，HikariCP是Java生态的标配，Go用database/sql自带连接池，Python用SQLAlchemy，连接池大小不是越大越好，业内公认的公式是核数乘以2加1，比如4核机器，连接池设9到10个就够了，默认值往往不够用,连接池开得过大反而会把数据库拖垮。
第二件事：缓存必须早于性能问题出现
很多团队等数
据库慢查询报警了才想起上Redis，这是最典型的反面教材，缓存逻辑应该在写第一个接口时就设计好，热点数据、用户会话、验证码这些天然适合放Redis的数据，就别让它们去查MySQL，这里还有个小技巧：缓存一定要设置过期时间,不设过期时间的缓存就是在给自己埋雷。
第三件事：日志必须跟业务分离
日志写入是个容易被忽视的IO瓶颈，默认情况下，应用日志和业务代码跑在同一块磁盘上，流量一上来，大量日志写入会拖慢数据库查询和接口响应，正确做法是日志走独立的日志服务，比如简米云的SLS或自建的ELK,或者至少把日志目录挂载到单独的数据盘上。
大厂都在用的压测方法：先压测再扩容
没有压测就谈架构，都是纸上谈兵，服务器到底扛不扛得住，压一下才知道。压测工具选Apache JMeter或者wrk，这两个都是开源免费且行业认可的，压测前先定好目标：接口响应时间P99小于300毫秒，错误率小于0.1%，压测方法很简单从500并发开始，逐渐往上加，直到接口响应时间超过1秒或者错误率超过1%,这个临界点就是你的系统真实容量。
压测结果直接决定你的扩容策略，如果500并发就崩溃，先看数据库慢查询，再看应用代码有没有死循环或锁竞争，最后才考虑加机器，盲目从1台加到10台，很有可能只是把单点问题变成了分布式问题，成本翻倍，问题没解决,这种情况在实践中相当常见。
服务器选型常见的三大误区
盲目上微服务，业务还没跑通，先搞了十几个微服务，每个服务都连数据库，连表和表之间的关联查询都做不了了，微服务是为了解决团队协作和独立部署问题，不是为了解决并发问题，并发不够，先加缓存、做读写分离,实在不行再考虑微服务。
忽视内网带宽，云服务器之间的内网通信也是有带宽上限的，如果你选择了低配的云主机，它们之间的内网传输速率上限可能只有1Gbps，当应用服务器和数据库服务器之间频繁传输大量数据时，这个内网带宽就会成为新的瓶颈，选型时看好内网带宽规格,别让低配主机的内网限制拖了后腿。
把所有鸡蛋放一个篮子，所有的服务都在同一家云厂商的同一台服务器上，一旦机房故障，你的App就彻底瘫痪，最基础的容灾方案是不同可用区的双机部署，数据库做跨区同步，如果你的App服务的是特定区域的用户，比如做本地生活应用,那服务器选靠近用户的区域会更划算。
高并发App选云服务器还是物理服务器
如果身边有朋友做传统行业转型，会建议买物理服务器放机房托管，觉得这样省钱又可控，但对大多数App团队来说，云服务器在弹性扩容、按需付费、运维便利性上的优势是压倒性的，物理服务器只适合以下两种场景：一是业务极其稳定，流量波动可以忽略不计；二是合规要求数据本地化存储，不能出机房，其他情况,闭眼选云服务器就对了。
从成本角度算一笔账：一台中配物理服务器年费加托管费大约5000元左右，但这台服务器实际利用率可能不到20%，云服务器按量付费，用多少算多少，同样预算能覆盖更长时间的需求变化，拿最常见的4核8G配置来说，简米云新用户价一年几百块，传统物理服务器要贵一个数量级,这笔账不用细算。
百万用户服务器方案常见问题解答
100万注册用户要用多少台服务器？
核心答案：起步阶段2台足够，1台应用服务器加1台数据库服务器，这是最稳妥的底线配置，应用服务器推荐8核16G，数据库服务器4核8G，再配一台Redis可以做缓存，如果预算确实紧张，单台8核16G的机器也能撑过早期阶段，等日活破5万再扩到四五台,量变引起质变的时候再动手也不迟。
带宽选多少合适？按流量计费还是按固定带宽？
这个问题没有恒定答案，跟你的App类型强相关，如果是视频类或有大量图片的App，必须按流量计费，否则固定带宽费用贵到怀疑人生，如果是工具类、资讯类App，读写以文本为主，5M到10M的固定带宽足够。正确姿势是先按流量计费跑一周，看后台统计的峰值带宽和日均流量,再决定要不要切固定带宽。
数据库用MySQL还是NoSQL？
绝大多数业务场景，MySQL依然是首选，关系型数据库在事务一致性上的优势是NoSQL无法替代的，具体到部署形态，100万注册用户根本不需要一开始就上分布式数据库，单实例加读写分离就够用，NoSQL（比如MongoDB或Cassandra）更适合日志存储、行为追踪这类高写入量低一致性要求的场景，稳妥的组合方案是MySQL存核心业务数据,NoSQL存非核心数据。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/606052.html
