软件开发架构师

秒杀架构优化,产品折衷

架构 48 2019-03-07 09:30

今天有朋友问我,说我的文章里,总是提“脱离业务的架构设计是耍流氓”。


每次都是架构根据业务折衷,有没有业务和产品由于技术难度太大来做折衷的?


当然,当一个业务技术难度非常大的时候,可以通过业务和产品的优化,来简化系统架构。


以“12306车票秒杀”为例,秒杀业务架构难度大,业务和产品可以这么折衷:


case 1

一般来说,下单和支付放在同一个流程里,能够提高转化率。


对于秒杀场景,产品上,下单流程和支付流程异步,放在两个环节里,能够降低数据库写压力。


12306,下单成功后,系统占住库存,45分钟之内支付即可


case 2

一般来说,所有用户规则相同,体验会更好。


对于秒杀场景,产品上,不同地域分时售票,虽然不是所有用户规则相同,但能够极大降低系统压力。


北京9:00开始售票,上海9:30开始售票,广州XX开始售票,能够分担系统压力。


case 3

秒杀场景,由于短时间内并发较大,系统返回较慢,用户心情十分焦急,可能会频繁点击按钮,对系统造成压力。


产品上可以优化为,一旦点击,不管系统是否返回,按钮立刻置灰,不给用户机会频繁点击。


case 4

一般来说,显示具体的库存数量,能够加强用户体验。


对于秒杀场景,产品上,只显示有/无车票,而不是显示具体票数目,能够降低缓存淘汰率。


显示库存会淘汰N次,显示有无只会淘汰1次。更多的,用户关注是否有票,而不是票有几张。


...


无论如何,产品技术运营一起,目标是一致的,把事情做好,不存在谁是甲方,谁是乙方的关系。


脱离业务的架构设计是耍流氓。

架构难度大,产品也应该折衷。

画外音:秒杀业务的架构优化讲过了,这次说产品上的优化。


兄弟,你的产品折衷了吗?或者,奇葩了吗?

欢迎分享你的故事。

文章评论