今天有朋友问我，说我的文章里，总是提“脱离业务的架构设计是耍流氓”。
每次都是架构根据业务折衷，有没有业务和产品由于技术难度太大来做折衷的？
当然有，当一个业务技术难度非常大的时候，可以通过业务和产品的优化，来简化系统架构。
以“12306车票秒杀”为例，秒杀业务架构难度大，业务和产品可以这么折衷：
case 1
一般来说，下单和支付放在同一个流程里，能够提高转化率。
对于秒杀场景，产品上，下单流程和支付流程异步，放在两个环节里，能够降低数据库写压力。
12306，下单成功后，系统占住库存，45分钟之内支付即可。
case 2
一般来说，所有用户规则相同，体验会更好。
对于秒杀场景，产品上，不同地域分时售票，虽然不是所有用户规则相同，但能够极大降低系统压力。
北京9:00开始售票，上海9:30开始售票，广州XX开始售票，能够分担系统压力。
case 3
秒杀场景，由于短时间内并发较大，系统返回较慢，用户心情十分焦急，可能会频繁点击按钮，对系统造成压力。
产品上可以优化为，一旦点击，不管系统是否返回，按钮立刻置灰，不给用户机会频繁点击。
case 4
一般来说，显示具体的库存数量，能够加强用户体验。
对于秒杀场景，产品上，只显示有/无车票，而不是显示具体票数目，能够降低缓存淘汰率。
显示库存会淘汰N次，显示有无只会淘汰1次。更多的，用户关注是否有票，而不是票有几张。
...
无论如何，产品技术运营一起，目标是一致的，把事情做好，不存在谁是甲方，谁是乙方的关系。
脱离业务的架构设计是耍流氓。
架构难度大，产品也应该折衷。
画外音：秒杀业务的架构优化讲过了，这次说产品上的优化。
兄弟，你的产品折衷了吗？或者，奇葩了吗？
欢迎分享你的故事。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31556838/viewspace-3149565/ ，如需转载，请注明出处，否则将追究法律责任。
