最近有朋友问我，说我的文章里，总是提“脱离业务的架构设计是耍流氓”。
每次都是架构根据业务折衷，有没有业务和产品由于技术难度太大来做折衷的?
当然有，当一个业务技术难度非常大的时候，可以通过业务和产品的优化，来简化系统架构。
以“12306车票秒杀”为例，秒杀业务架构难度大，业务和产品可以这么折衷：
case 1
一般来说，下单和支付放在同一个流程里，能够提高转化率。
对于秒杀场景，产品上，下单流程和支付流程异步，放在两个环节里，能够降低数据库写压力。
12306，下单成功后，系统占住库存，45分钟之内支付即可。
case 2
一般来说，所有用户规则相同，体验会更好。
对于秒杀场景，产品上，不同地域分时售票，虽然不是所有用户规则相同，但能够极大降低系统压力。
北京9:00开始售票，上海9:30开始售票，广州XX开始售票，能够分担系统压力。
case 3
秒杀场景，由于短时间内并发较大，系统返回较慢，用户心情十分焦急，可能会频繁点击按钮，对系统造成压力。
产品上可以优化为，一旦点击，不管系统是否返回，按钮立刻置灰，不给用户机会频繁点击。
case 4
一般来说，显示具体的库存数量，能够加强用户体验。
对于秒杀场景，产品上，只显示有/无车票，而不是显示具体票数目，能够降低缓存淘汰率。
显示库存会淘汰N次，显示有无只会淘汰1次。更多的，用户关注是否有票，而不是票有几张。
...
无论如何，产品技术运营一起，目标是一致的，把事情做好，不存在谁是甲方，谁是乙方的关系。
脱离业务的架构设计是耍流氓。
架构难度大，产品也应该折衷。
画外音：秒杀业务的架构优化讲过了，这次说产品上的优化。
【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】
