架构师做技术评审，其实是在帮公司省真金白银

小王刚升任架构师，第一次主持技术评审会，紧张得手心冒汗。他以为要讲高深理论、画满屏UML图，结果开场就被CTO一句话点醒：“别讲‘应该’，说清楚‘不这么干，下周服务器多花两千块’。”

评审不是挑刺，是掐住成本的命门

很多团队把技术评审当成“走过场”：开发提方案，架构师点头或划几笔修改意见，散会。但真正懂行的架构师，一开口就在算账。比如看到有人提议用Kafka集群处理日均500条订单通知——他立马问：“消息量不到10QPS，用Redis Pub/Sub加个重试队列，运维成本砍掉80%，连服务器都不用新加。”

三招直击省钱要害

第一招：盯死资源利用率
翻看上月云监控截图，发现ECS CPU峰值才12%，却常年挂着4核8G实例。评审时直接打开实时监控页面：“这台机器跑着三个微服务，但每个服务实际只用300MB内存。合并部署+调低规格，月省680元，半年就是四千多。”

第二招：拒绝“为未来买单”的过度设计
有同事提出给用户中心加区块链存证模块，理由是“以后可能合规需要”。架构师没谈技术，只甩出两行数据：

当前用户年增长：8%
历史投诉率：0.002%

接着说：“按这节奏，十年后用户量也到不了百万级。先用带签名的MySQL binlog归档，够用五年，零额外成本。”

第三招：把“可维护性”换算成人工时
看到一份用Python写的数据清洗脚本，硬编码了17个数据库连接参数。架构师当场新建个配置文件模板：

db:
  user_center: <env:UC_DB_URL>
  order_log: <env:OL_DB_URL>

然后说：“现在每次换环境改17处，平均耗时22分钟。统一配完，新同事1分钟搞定。团队10人，每月少浪费37小时——相当于白拿半个人力。”

真正的评审现场什么样

上周某电商项目评审，开发提了套“全链路灰度发布方案”，含5个定制中间件。架构师听完，掏出手机打开阿里云价格计算器，边点边说：“这套自研组件，光运维人力每月至少2人天。换成Nacos+Spring Cloud Gateway原生灰度，配置3分钟，不新增服务器，连License费都省了。”会后，方案重写，预算从12万砍到0元。

技术评审不是在纸上谈兵，是把每一行代码、每一个组件、每一次扩容，都放在电费单、人力表和续费提醒里过一遍。省下的不是虚的“效率”，是实打实到账的现金流。