1. 面对这个面试题先想明白面试官在考察什么前阵子面了一家金融科技公司的后端岗位二面的时候面试官抛了个问题假如当前系统QPS只有100你作为负责人怎么把成本降下来听到这个题我愣了一下不是因为难而是因为很多人一上来就会列一堆优化手段上缓存、加消息队列、搞微服务拆分、上K8s做弹性伸缩。但说真的流量只有100 QPS的时候这些操作大概率不是在降本而是在增加成本。我当时的思路是反过来问自己几个问题这100 QPS是怎么分布来的是平均100还是峰值100单机能不能扛住现在的资源利用率有多少有哪些固定成本是明显浪费的如果这些问题没有想清楚任何优化方案都是在猜。面试官想考察的其实是你对“成本”这件事的理解深度——你有没有成本意识能不能用数据说话会不会在低流量场景下做出合理的取舍。先把这个题的底层逻辑捋清楚。100 QPS是什么概念假设单请求平均耗时50ms单实例可以支撑大约20并发。而100 QPS意味着期望并发约5个100×0.05。这连一台普通虚拟机都能轻松扛住。如果不加思考就引入一堆中间件和冗余节点不客气地说这是在花钱买复杂度。所以这道题的正确打开方式不是“如何通过高端技术省钱”而是“如何识别并砍掉那些超出实际负载的过度供给”。把系统当前所有资源列出来逐个问一句真的需要这么多吗这才是降本的第一性原理。1.1 成本优化不等于性能优化也不等于架构重构很多人容易掉进一个误区觉得降本就要把架构搞得很大用最前沿的技术。实际上对于100 QPS的系统如果现状是30台ECS放在那里你第一反应应该是“这30台里面有多少台是多余的”而不是“我要不要引入Service Mesh”。成本优化的核心动作是“做减法”不是“做加法”。性能优化关注的是单位资源能处理多少请求而成本优化关注的是“花出去的钱是否都产生了对应的业务价值”。举个最简单的例子如果一台4核8G的机器能支撑500 QPS你的业务只需要100 QPS那1台机器就够。但如果因为打了某些高可用要求非要部署3个节点那也行但成本是3台。这时合理的降本方向是评估真的需要3副本吗如果不那么核心降成2副本甚至单节点快速恢复机制成本直接少了三分之一。这些判断靠的不是技术炫技而是对业务等级和风险容忍度的清晰认知。1.2 面试时容易被忽略的边界先区分“峰值流量”与“平均流量”我在回答时特意问了一句这个100 QPS是平均还是峰值如果平均100峰值可能到300甚至更高。如果是峰值100平时只有二三十那最优解和前者完全不同。这个细节很关键因为降本方案里流量模型决定了你能不能缩容、该不该留buffer、要不要上弹性。比如一个典型业务系统白天时段平均QPS 120夜间只有20。这种有明显的波峰波谷直接用固定实例数就很浪费。这时候引入定时扩缩容或者基于指标的自动伸缩可以让低成本时段只保留一两台机器。如果峰值和均值相差不大倒是可以维持固定容量减少不必要的弹性组件维护成本。反正记住一句话没有流量画像就没有降本方案。2. 先算清账本QPS 100 的系统的成本构成与浪费点识别设计降本方案前我最推荐先做一次“成本体检”。把每个月云账单拉出来按资源类型拆开看计算、存储、网络、数据库、中间件、人力运维成本。为什么要拆因为不同系统成本结构完全不同。有些系统数据库是大头有些是日志存储爆炸有些是容器集群空转。如果让我给一个典型QPS 100的后端系统画像大概率成本分布是这样的成本项常见占比典型浪费点计算资源ECS/容器30%-50%实例规格过剩、副本过多、长期低负载运行数据库与缓存20%-30%规格过高、慢查询导致扩容需求、为“未来”预留存储与备份10%-20%日志不归档、备份保留周期过长、冷数据占用热存储网络与带宽5%-10%单机多副本间传输、跨可用区流量中间件与治理组件5%-15%注册中心、配置中心、监控系统自身耗资源人力与运维开销隐性过多微服务带来的部署、联调、维护成本从这个表能看出计算和数据库是主战场。但我要特别提醒别忽视“中间件成本”。很多团队为了追求某种架构美感给100 QPS的系统挂了完整的微服务全家桶网关、注册中心、配置中心、链路追踪、监控大盘、多套环境。每样东西本身要占用资源还要有人维护。这些固定成本不会随着QPS下降自动消失是降本时要重点审视的沉没成本。2.1 通过QPS反推实例数量一顿估算心里就有底在面试时我直接和面试官算了一笔账。假设单请求平均处理时间50ms那么单个实例能够支撑的最大QPS约为1/0.0520 QPS单线程模型下。如果是4核8G的机器配合合理连接池和并发配置单机支撑100 QPS通常没有问题。实际上很多Java服务单机跑到几百QPS很常见主要看CPU密集还是IO密集。如果平均耗时更高比如200ms那并发模型下单机可能只能支撑50 QPS假设10个并发都能处理。所以100 QPS也未必单机就能扛需要先测量接口的TP99延迟。这里想说明的是不要看到100就拍脑袋说一台机器搞定而是要有能力根据实际指标估算。我是这样做的找监控系统拉出线上接口的耗时分布再结合机器配置做容量预估。如果当前机器CPU使用率只有10%内存占用不到一半那答案很明显——资源冗余。2.2 常见成本浪费的三个画像结合我见过的一些低流量系统浪费基本集中在三个画像上。第一个是“高配低用”。申请ECS时选了当时最新款高配规格比如16核32G但业务请求量根本跑不满CPU长期在5%以下。这种资源浪费最直接降配就能省一大笔钱。云厂商的计费不是线性的很多情况下8核16G和16核32G的价格差很远但对你这个业务而言实际差异微乎其微。第二个是“大马拉小车”的数据库。MySQL或者云上RDS选了高规格连接数和IOPS远远用不满。还有的上了Redis集群实际只有两个键在被高频访问。这时完全可以降规格、换单节点、甚至把部分缓存去掉。第三个是“面板好看钱包受罪”的中间件。一个100 QPS的系统非要把服务拆成十几个微服务每个服务都要分配开发、测试、生产三套环境。每套环境里跑着注册中心、配置中心、监控agent。这样算下来光环境开销就够养好几个服务了。更重要的是人力和维护成本是隐性的很难量化但真实存在。2.3 找到大头再动手别在无关紧要的角落抠钱我见过有些人一说降本就去调云厂商的折扣、换更便宜的套餐、洽谈预留实例。这些当然可以做但前提是先把架构层面的浪费解决掉。就像一家餐厅你拼命砍纸巾的成本但后厨食材浪费一大堆那再怎么抠也没意义。所以我的降本流程是先找影响面最大的点通常是实例数量和数据库规格再处理次要项比如日志和存储最后才去谈计费策略比如包年包月、Spot实例、预付折扣等。把这个顺序记牢面试时回答也会更有逻辑。3. 分层降本从架构、数据到链路一层一层挤出水分算清楚账之后就可以开始设计方案了。我用“架构层—数据层—链路层”三个层次来拆解这样在面试中不会乱实际落地时也好推进。3.1 架构层微服务不是万能的低QPS下该合就合这个话题可能有点招微服务爱好者的反对但我还是要说对于一个只有100 QPS的系统微服务带来的收益大概率小于成本。微服务的初衷是应对超大规模团队协作和超高流量弹性而100 QPS的场景单体应用或者极少数服务拆分反而更省心。我在处理类似系统时优先考虑把多个业务模块合并部署。比如原来拆了用户服务、订单服务、支付服务、通知服务每个服务独立注册、独立部署、独立配资源。如果流量不高直接合并成一个应用用内部模块划分来隔离开代码边界。这样减少了至少三套部署单元节省了容器内存和网络开销也缩短了链路耗时。当然如果团队真的很庞大、各团队需要独立发布合并会带来协作成本那另说。但这是个权衡而不是技术对错问题。架构层还有一个经常被忽视的点环境实例。很多系统在开发、测试环境都常开着集群即便晚上没人用。如果这些环境不是24小时需要完全可以用定时开关机的方式只在工作时间内启动。省下的费用不是小数目而且几乎不影响研发效率。3.2 数据层缓存、数据库与存储的一次大扫除数据层是成本重灾区。先从缓存说起——不是所有系统都需要Redis。如果业务缓存命中率不到50%而且数据本身就在数据库里加缓存只会增加一致性风险和额外的运维成本。100 QPS下直接查询MySQL的QPS也就是几百完全没问题。所以我会先做缓存必要性分析如果是为了缩短几十毫秒的响应时间而这些时间用户感知不强那就把缓存砍掉数据层成本直接下降。数据库方面第一件事是检查规格。很多系统的RDS规格远远超用。可以观察CPU使用率、内存占用、连接数峰值、慢查询数量。如果CPU几乎不超过10%连接数常年个位数那么降一个规格甚至两个规格都没有问题。第二件事是清理无效索引。索引不是越多越好每多一个索引写操作都要维护还占用额外存储。在100 QPS的写入量下保留必要索引即可。第三件事是历史数据归档。把一年前的订单、日志等冷数据迁到对象存储或者归档存储数据库体积变小日常查询变快也就不用为了承载大数据量而升级规格。存储层面日志是很多人忽略的钱坑。按100 QPS计算每天请求量约864万如果每条请求产生200字节日志一天就是1.7GB左右。听起来不多但如果日志保留30天、且多副本冗余也有几十GB甚至上百GB。关键是这些日志里真正被捞出来看的可能不到1%。我的做法是降低访问频率低日志的保留周期只用近7天对超过30天的日志转归档存储成本能低一个数量级。再加上日志压缩、采样上报存储成本能砍掉一半以上。3.3 链路层减少无用功让每个请求都划算链路层的降本核心是“用最小的资源完成同样的业务目标”。最简单有效的是减少重复计算。比如某些接口查询结果在短时间内不变却每次都查库、做复杂计算这就是白烧CPU。可以考虑在应用内存里做短暂缓存命中后直接返回。100 QPS下一个请求从100ms降到10ms理论上单机承载能力能翻十倍虽然你不需要真的翻十倍但你可以借此缩小实例规格。另一个方向是异步化。如果一个请求里有两步操作其中一步不是核心路径比如发邮件、推送通知就可以丢进队列或线程池异步处理让调用方更快返回也降低阻塞。虽然异步不会直接减少资源消耗但可以减少线程数、减少等待占用从而让同样资源支撑更多请求。对于降本来说少用一台机器就是实打实的省。还有接口合并。如果前端一次要调3个接口才能拿到页面数据这3个请求都要走网络、DNS、负载均衡、业务逻辑。如果后端提供一个聚合接口一次搞定请求量就从300 QPS降到100 QPS链路负载和日志量都同步下降。这种优化在100 QPS场景下尤其难得因为请求量少改动风险也相对可控。4. 弹性与容量治理让成本跟着真实流量走而非拍脑袋预留前面聊的都是“砍掉多余资源”但在一个长期运行的系统中真正让成本回归合理的手段是弹性策略和容量治理。即使你不做大的架构改造只要把弹性做对就能把很多成本自动抹平。4.1 定时扩缩容与指标扩缩容才能让夜间流量不白烧钱100 QPS的系统往往白天忙、晚上闲。这种情况下最浪费的就是24小时跑满固定数量的实例。如果你用的是容器平台可以为工作负载配置HPA水平自动伸缩依据CPU使用率或请求量伸缩副本数。白天流量上来自动加副本晚上没人访问缩到最小副本。如果平台能力不支持至少可以搞个定时脚本在每晚8点把无状态服务缩到1个副本次日早上7点再扩回来。需要注意的是缩容不是粗暴地减少副本就完事。你得先保证服务能平滑缩容比如设置优雅停机、在缩容前断开流量、让正在处理的请求完成。这些细节不做好的话缩容带来的服务抖动比省下的钱更让人头疼。还有如果服务依赖数据库连接池缩容后连接数要重新调整不然会出现连接池占满的假象。我在一次实战中就遇到过类似问题后面第五章会详细讲。4.2 建立成本水位线让资源利用率可见除了弹性还要有“成本水位线”的监控。简单说就是对每个服务设定合理的CPU、内存使用率目标区间。如果连续几天使用率低于20%就触发资源整理提醒如果高于80%则考虑是否需要扩容或优化。这个机制能防止成本悄悄反弹。低QPS系统最怕的是“反正流量不高就多留点buffer吧”这种心态会让资源一点点堆起来最终成本变成刚性的。我们可以用表格做一个资源水位样例服务当前实例数平均CPU平均内存建议订单服务48%40%缩到2实例规格不变用户服务215%60%可降至1实例若容忍短时故障支付回调25%30%合并至订单服务取消独立部署定时任务12%20%保留可降配表格只是示意核心在于把抽象的成本消耗变成一眼可见的指标。有了这个水位表你每次做降本决策都有依据而不是凭感觉。团队里也可以约定一条规则新申请的资源必须提供容量预估和使用率预期避免“怕不够先申请多”。5. 从面试题到落地我的一次低成本改造实操复盘说完了理论我把一个真实的改造过程分享出来。为了不涉及具体公司信息就叫它“某旧系统”好了。这套系统对外提供数据查询能力平均QPS不到100峰值也才150左右。它的问题是每月云成本高得离谱而且团队每次开会都被质疑为什么这么高的费用。5.1 改造前的状态和关键数据系统原有部署情况如下8台4核8G的ECS前后端分离部分服务各部署2个实例1套4核16G的MySQL主从从库基本没读过2个Redis节点其中一个只有某个列表缓存用得到十几个微服务很多只依赖同一个核心库各自部署日志存储保留45天未压缩未归档我拉出一个月的监控数据做了成本归因。计算资源占了大头约55%数据库与缓存占25%存储日志占15%其他占5%。CPU利用率超过20%的服务只有两个其余常年个位数。很明显这不是“性能不够”而是“供给过剩”。5.2 三步改造过程第一步合并服务。我把依赖关系简单、没有独立扩展需求的6个服务合并成了2个。合并之后原本需要12个实例的服务现在只保留4个实例。这个动作最省成本同时也暴露了很多隐藏问题不同服务原本有独立的日志目录、配置项合并后需要统一端口冲突、依赖包版本冲突也需要慢慢收拾。好在流量不高灰度验证压力不大。第二步数据库降配与清理。将MySQL从4核16G降为2核8G关闭了从库改为用主库备份机策略。原因是读流量极低从库只起到了“摆设”作用。同时清理了20多个无用索引归档了两年前的历史数据到便宜的对象存储。Redis也从双节点变为单节点且只保留真正高频访问的数据。第三步弹性与开关。所有应用接入了弹性伸缩夜间自动缩容到2个实例。日志从45天调整为热日志7天超过7天的自动压缩并转移到低频存储。这一步之后存储成本直线下降。5.3 效果对比与踩过的坑改造后月度云成本降了约48%。服务可用性没有明显下降平均响应时间反而缩短了因为合并后的调用链路更短。从效果上看这次改造是成功的。但有几个坑我必须提醒。第一个坑是合并服务时的“连坐问题”。原本两个服务各自部署一个出问题不影响另一个合并后某个模块的Bug会导致整包重启。为了安全我给合并后的服务增加了更精细的线程池隔离比如订单处理线程池和通知发送线程池分开避免互相耗尽。第二个坑是缩容时的连接风暴。有一次夜间缩容从4个实例缩减到2个结果所有服务重新建立数据库连接瞬间把一个本来很空闲的数据库打出了大量连接。最后靠限制每个实例的数据库连接池上限以及延长缩容的冷却时间才解决。第三个坑是日志归档被“忽略”。因为压缩任务执行时间过长导致当天的日志没有及时归档存储量短暂反弹。后来调整了压缩任务的调度频率并分片处理就正常了。6. 如果面试官追问这些降本手段的边界与风险在哪面试官通常会顺着你的方案继续追问比如“你合并服务后如果流量涨到10000 QPS怎么办”或者“你降数据库规格万一突然有热点活动怎么办”这时候不要慌答案的核心是“降本不是一锤子买卖而是动态平衡”。任何优化方案都有前提和边界你能说出来反而说明你考虑全面。先说合并服务的边界。服务合并适用于低流量、单团队维护的系统。如果业务复杂度高、团队多人并行迭代强行合并会造成代码耦合和发布互相制约。所以我在方案里会强调合并不等于消灭模块边界代码层面依然保持清晰的分包只是部署时放到一起。再说降低数据库规格的边界。降规格的前提是性能监控数据支持并且有快速回退机制。比如云数据库通常支持在控制台一键升配用时也就几分钟。所以在降低成本的同时要把“升配预案”写清楚一旦流量突增或者大促来临能及时恢复容量。这也是云厂商比自建机房有优势的地方。还有缓存和异步的边界。砍缓存的前提是数据库撑得住一旦访问量增加或者出现热点数据库压力会迅速上升。所以砍缓存时要谨慎评估读放大和热点场景。异步本来是降耗时的手段但引入队列也要维护如果只是100 QPS完全可以用进程内线程池没必要额外搭建消息队列中间件。最后其实我想说这类面试题没有标准答案。面试官想听的是你能不能把一个具体问题落到可执行、可度量的方案中并且能意识到方案的风险和盲区。如果你在面试时能把成本构成表拉出来再把“先诊断—再治理—后评估”的思路说清楚基本上已经是一个很完整的回答了。我在实际做降本的过程中最大的体会是在低流量场景下最简单的方法往往最有效。合并一台机器、关掉一个不用的Redis、把日志保留期缩短这些事情听起来不够“高大上”但每个月省下来的钱是实实在在的。优化完所有技术项之后记得把账单拉出来对比一下这就是你最好的面试案例和绩效素材。