项目上线前一周，团队突然发现当前用的技术栈在高并发场景下扛不住。作为架构师，老张坐在会议室中间，所有人盯着他等一句话：换不换？怎么换？
压力从哪来？
技术选型从来不是纯技术问题。老板关心成本和上线时间，开发怕学习新框架，运维担心部署复杂度。架构师夹在中间，选错了背锅，拖久了误事。尤其是当几个主流方案各有优劣时，那种“怎么选都像赌”的感觉最折磨人。
别一个人扛决定
老张没急着拍板。他拉上后端、前端、测试各派一个代表，建了个临时小组。每人负责调研一个候选方案：Spring Cloud Alibaba、Dubbo 3 和自研网关。三天后摆数据说话——QPS、故障恢复时间、团队熟悉度、社区活跃度全列出来，做成对比表贴在白板上。
有争议的地方直接写出来。比如有人坚持用新技术提升简历含金量，有人担心线上出问题半夜被叫起来修。把这些话摊开讲，反而让讨论回归实际。
小步验证比纸上谈兵强
光看文档容易偏。他们搭了个模拟环境，把三个方案的核心流程跑一遍。特别是压测环节，用 JMeter 模拟下单高峰：
<testPlan>
<threadGroup threads="200" rampUp="10"/>
<httpSampler domain="api.example.com" port="8080" path="/order" method="POST"/>
<resultCollector/>
</testPlan>结果一目了然：自研网关吞吐量最高，但错误率也高；Dubbo 稳定，但改造现有服务工作量大。最终选了折中方案——保留原有通信结构，引入 Sentinel 做流量控制，快速落地。
留退路比追求完美重要
上线那天，老张特意让运维多备了一套老配置。万一新限流策略出问题，十分钟内能切回去。这种“可逆性”设计后来成了团队惯例：加功能先做开关，改接口留兼容层。
有次产品经理临时要加推荐模块，后台资源紧张。他们没硬上算法模型，而是先接了个静态规则引擎，数据达标后再逐步替换。这样既满足进度，又不至于一步踩空。
工具帮不上忙时，靠流程兜底
再好的架构工具解决不了人为分歧。老张后来搞了个“决策日志”，每次重大变更记清楚：谁提的建议、依据是什么、有没有做过原型、风险点在哪。这东西不为追责，是让新人也能看懂“当初为啥这么干”。
有次新来的同事质疑为什么不用 Kubernetes，翻完日志发现去年试过，因公司网络策略限制导致服务发现不稳定才放弃。省了又一轮重复争论。
压力不会消失，但可以分摊
现在团队开技术会，老张不再第一个发言。他习惯先问：“你们觉得卡点在哪？” 把问题抛回去。有时候答案比他想的更接地气。比如前端说“只要接口字段不变，你们爱用啥用啥”，后端说“给两周学习时间就行”。很多“大难题”其实只是信息没对齐。
技术决策压不垮人，持续闭门造车才会。找个最小闭环试起来，比在会议室吵三天更有用。