从大麦网架构学到的东西

春哥叨叨

共 2091字,需浏览 5分钟

 ·

2021-06-07 15:25

业务特点

大麦业务链条涵盖了从B端生产、C端销售、现场换验的全套流程。其业务架构也经过几个阶段的发展:

  • 第一阶段:保障不健全、设施不完善;

  • 第二阶段:支持部分大型抢票需求;

  • 第三阶段:“体系化”承接所有大型抢票需求;

  • 第四阶段:“常态化”体验优化;

第一阶段

此时的大麦架构还在大麦自己的IDC内,主要是原有大麦技术架构承担需求。此时的架构存在以下几个问题:

  1. 保障设施不健全:大麦IDC机房硬件、快递均有限制,DB还是Sql Server,很多库是单库,不能应对大型抢票时的挑战;

  2. 预案、限流不健全:系统在面对高流量时,没有自我保护措施;

  3. 监控运维手段零散:定位问题、解决问题耗时长;

解决方案

这一阶段主要是一些零散解决方案,针对问题解决。比如搭建简易版限流方案,做性能优化点,整体上未体系化解决问题。

第二阶段

第二阶段由于已经被阿里收购,所以架构重构直接切入阿里域内解决方案,逐步替换掉老系统。

这一阶段的关键就是新老方案的迁移:

  1. APP链路改造:技术改造重点放在无线端,所有APP流量先进入阿里域,再路由到大麦IDC,让阿里机房抵挡大量流量;

  2. 借助阿里基础运维设施:由于入口流量直接进入阿里域,降级、限流的动作可以依赖于阿里服务治理平台能力做;

  3. 建立抢票预案:围绕于大型抢票场景做预案建设,比如商详页增加tair缓存,靠tair抗住阿里域流量,建设流量打到大麦IDC;

第三阶段

第三阶段针对于抢票流程上的系统做了体系化升级,完善了抢票流程和可靠保障机制。升级后的架构可以承接住所有大型抢票需求,用户体验有所提升。

优化动作:

  1. 精简了搜索response过大的问题,降低了对宽带的压力;

  2. 在阿里域内,大型抢票选座流量直接打到了阿里域内,采用异步和类似ConcurrentHashMap的平衡机制,解决了大麦IDC选座的缓存一致性问题;

  3. 继续完善阿里域内交易链路功能,下单接口全部放在阿里域内,下单之后订单同步到大麦IDC内服务履约;

保障流程:

大麦主要是票务平台,主要保障的黄金链路就是抢票,针对于这个链路需要建立可靠性保障和SOP。

抢票分为抢票前、抢票中、抢票后等环节:

  • 抢票前:重点是由业务方抢票申报,再由技术方确认是否安排预演或压测,由业务方判断预案执行范畴及风控级别;

  • 抢票中:重点监控和过程中的应急处理,每逢大促,各个角色聚集一起,各司其职;

围绕于抢票流程,可靠性保障包括:预案/预演/容量等专项;

  1. 预案建设:已有成熟的流程不再安排预演,新玩法需要模拟抢票,提前暴露问题,并建立体验问题预案;

  2. 容量保障:技术拉取全链路最近类似项目压测数据作为基础数据,和线上真实流量做评估,分析抢票环节是否可以顺利支撑,是否存在性能瓶颈,是否需要做限流;

  3. 预案执行:在全链路中找到核心场景,如:首页搜索、商品详情、票务选座、交易下单、票务库存、订单服务、无线端等场景建立预案。同时将高频使用缓存信息在活动开始30分钟预热到缓存中;

  4. 问题复盘:针对于每次活动出现的问题、客服反馈、线上问题进行收集,组织复盘,并将todo落实到action上,关注action执行进度;

第四阶段

在进行了全链路系统性完善之后,我们依然不能说肯定不会出现宕机的问题。因为抢票环节注定是少数人可以抢到票,抢不到票的可能在舆情疯狂吐槽。为解决这些问题,我们需要为真正的用户提供极致体验。

新交易系统上线,融合了大麦交易系统和阿里星环平台,渲染接口、下单接口基于星环实现大麦特性扩展。

星环带来的优点有2点:

  1. 依托于共享基础能力,除了可以复用共享能力外,还可以参考主站交易的大促方案,比如限流、监控日志、问题排查等。基于星环可以实现未支付关单等个性化能力定制,提高研发效率;

  2. 结合集团风控体系,人机识别、定制策略等对非法用户进行了二次拦截,让真实用户抢票体验更好,大大提升了真实用户购买率;

为摸清交易链路的性能水位,需要做到性能常态化,每月定时执行压测、结合当月各项系统功能,评估压测场景和压测目标,压测完成后,更新链路现状,为抢票提供有效数据支撑。

之前的可靠性保障规范不完善,监控、预案、入口不统一。所以建立预案自动化平台,运营在配置抢票活动时【抢票开始前】,可以设置一些预案;在【抢票进行中】可以对核心场景进行统一视图监控,并且有能力实现人为干预和控制;在【抢票结束后】提供历次抢票数据,供分析,帮助运营自助完善,实现自动化流程。

比如针对于商详页,有6-10项降级预案(包括本地缓存或tair缓存、三方依赖接口限流、异常降级等),每个预案设置的值,执行时间都有差异,每次降级操作都需要人工经验判断,操作繁琐。这里需要实现自动化或系统容错实现降级。

总结

经过以上几个阶段,大麦从最开始的“原始”状态进化到了“常态化”流量压测、预案执行新阶段,系统可靠性提升,用户体验提高。后续还需要在项目热度智能分析、风控自动调节等方向进行持续优化。

浏览 84
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报