架构师这个头衔快烂大街了，但真正做架构的人快失业了
我上次去面试一个P7的架构岗，对面坐的HRBP问我：你平时画架构图用Visio还是ProcessOn？我说我基本不画图，我都是先看代码，她愣了一下，然后问那你觉得我们公司应该用K8s还是Serverless？我差点当场笑出来，这问题就像问装修工人应该用电钻还是锤子，关键是你家墙里有没有钢筋啊。后来我没去，但这事让我琢磨了很久，现在到处都是架构师，大厂一个项目组能塞四五个架构师，每人负责一个域的PPT，可真出了问题，谁又真的愿意把服务器日志从头翻到尾？
十年前架构师看代码，现在的架构师看别人写的代码摘要
2013年我在一家电商公司，当时系统经常半夜报警，数据库连接池被打满。架构师老周直接拉上我，在机房蹲了三个通宵，用手写SQL一条条排查慢查询，最后发现是订单表上一个索引建错了顺序。他那个决策很简单：把联合索引的字段顺序调一下，当时有人反对，说DBA团队都出方案了，用中间件分库分表。老周说先改索引，如果QPS还到不了3000再分。结果改完后，那个接口从900ms降到120ms，稳定跑了一年多。那时候的架构师是真的在拼命理解技术底层，知道一条索引为什么生效，知道内存和磁盘之间的代价差多少倍。但现在呢，很多所谓架构师做技术选型，问的问题就是：业界主流是什么？阿里在用那个？云厂商主推哪个？然后直接拍板。他们根本不会去读一下Kafka的源码，也不清楚RocketMQ的存储结构，更没算过自己业务的消息积压到底会吃掉多少内存。
所有业务都在做微服务，但没人能说清楚拆分后的收益到底是多少
我见过最离谱的一个项目，某个传统企业搞数字化转型，花大价钱请了咨询公司，把原本一个单体应用拆成了17个微服务。拆完之后，一次登录请求要经过API网关、认证服务、用户服务、权益服务、消息服务，来回跳5次，每次都要序列化和网络IO。结果上线之后，登录接口的平均时延从原来的45ms涨到380ms，运维那边每天要处理的服务间调用重试风暴，比原来的单机日志排查痛苦十倍。我问那个项目的架构师，你拆分的时候有没有压测过网络开销？他说不用压，微服务是标准解法，大家不都这么干吗？后来我实在忍不住，上生产环境把一次完整调用的链路追踪打出来，发现光是JSON序列化和反序列化就占了78ms，服务间网络传输占了150ms，真正业务逻辑只花了30ms。我说你看，这架构比原来的单体还慢，可他却说没事，我们后续加缓存就能优化。问题是缓存一加，数据一致性又出来了，又搞分布式事务，最终状态从一天收敛变成了一周收敛。这种架构师不是在解决问题，是在给业务上杠杆，而且上的还是反向杠杆。
更可怕的是，架构师开始用降本增效的KPI来掩盖自己的无能
前阵子一个朋友找我诉苦，说公司要求整体技术成本降低30%，CTO把任务甩给架构组。他们架构组做了什么？把所有服务器的规格从8C16G降到了4C8G，理由是监控显示平均使用率不到40%。结果大促一来，直接雪崩，容器被Linux OOM Killer干掉了十几个核心节点。我当时就问他，你们有没有算过GC线程的开销？有没有分析过CPU的突发尖峰？他说没有，反正监控是Prometheus抓的，平均负载就是低。这种拿平均数和峰值玩数字游戏的做法，根本不算架构优化。我见过真正厉害的降本，是把一个数据归档任务的调度从每15分钟跑一次改成每2小时一次，代码里加了一个状态机判断，成本直接降了62%，而且业务完全无感知。那个人并不叫架构师，他只是一个在业务代码里泡了五年的后端开发，但他理解数据的生命周期，知道哪些数据热哪些数据冷。现在很多架构师整天研究Service Mesh、多集群联邦这些新名词，可连自己系统的流量模型都没摸清楚，什么流量是读多写少，什么时段是洪峰，哪些调用能异步化，全凭感觉。
架构师真正的对手不是什么新框架，而是自己不再写代码的那一天
我最近两年一直在刻意保留一个小模块，每周五下午自己改代码，不告诉任何人。那个模块是用户积分计算器，逻辑不算复杂，但涉及很多边界条件，比如过期积分、退款扣减、渠道叠加。我为什么要这么做？因为一旦你连续三个月不写代码，你看到一份代码review的时候，大脑里就没有那种对逻辑陷阱的直觉了。你会开始喜欢那些抽象得很深的类结构，你会觉得策略模式加工厂模式很好看，你会支持把配置外置到Apollo，但实际上，你可能连这个配置被谁消费都没理清。我碰到过一个架构师，他设计了一套特别优雅的规则引擎，可以动态下发积分规则，看起来产品需求都不用发版本了。结果上线后，业务配置错误导致用户被错误发放了双倍积分，查了一天没找到原因，因为规则配置在后台页面上，日志里没有留下任何痕迹，连审计都没有。后来我介入，查了配置中心的历史变更记录，才发现是上个月一个测试账号不小心改了一个百分比小数点导致的。那个架构师从一开始就没想过：事故的可追溯性比灵活性更重要。真正的架构决策，不是选一个炫酷的模型，而是提前想清楚当系统出错时，你是否有能力用最短的时间定位它。
现在我还好，但我知道很多架构师早晚要出事
上周一个老同事打电话给我，说他们公司要搞架构重组，他被内定为主架构师，问我有没有什么资料推荐。我问他，你现在每天还看多少代码？他说哪来得及，天天开会，一天六个会，能有两个小时写代码就不错了。我说那你别接这个活，你不是去当架构师，你是去当替罪羊的。他不信，说老板很认可他。我没再劝。因为我知道，一个架构师如果不在代码里活着，那他就只能在PPT里表演。而PPT这种玩意儿，表演得再精彩，生产环境一抖动，就全他妈露馅了。
我可以接受技术选型失误，因为没人能永远决策正确。但我真的接受不了一个自称架构师的人，面对一个具体的死锁问题，第一反应是打开搜索引擎而不是看线程Dump。架构师这个称呼应该是一种能力认证，而不是一个职级名字。如果你天天画盒子，那你只是个画画的。如果你能指出盒子里那行代码为什么慢、为什么会出错、怎么改它，你才配叫架构师。就这么简单，也这么难。