从大麦网架构学到的东西
业务特点
大麦业务链条涵盖了从B端生产、C端销售、现场换验的全套流程。其业务架构也经过几个阶段的发展：
第一阶段：保障不健全、设施不完善；
第二阶段：支持部分大型抢票需求；
第三阶段：“体系化”承接所有大型抢票需求；
第四阶段：“常态化”体验优化；
第一阶段
此时的大麦架构还在大麦自己的IDC内，主要是原有大麦技术架构承担需求。此时的架构存在以下几个问题：
保障设施不健全：大麦IDC机房硬件、快递均有限制，DB还是Sql Server，很多库是单库，不能应对大型抢票时的挑战；
预案、限流不健全：系统在面对高流量时，没有自我保护措施；
监控运维手段零散：定位问题、解决问题耗时长；
解决方案
这一阶段主要是一些零散解决方案，针对问题解决。比如搭建简易版限流方案，做性能优化点，整体上未体系化解决问题。
第二阶段
第二阶段由于已经被阿里收购，所以架构重构直接切入阿里域内解决方案，逐步替换掉老系统。
这一阶段的关键就是新老方案的迁移：
APP链路改造：技术改造重点放在无线端，所有APP流量先进入阿里域，再路由到大麦IDC，让阿里机房抵挡大量流量；
借助阿里基础运维设施：由于入口流量直接进入阿里域，降级、限流的动作可以依赖于阿里服务治理平台能力做；
建立抢票预案：围绕于大型抢票场景做预案建设，比如商详页增加tair缓存，靠tair抗住阿里域流量，建设流量打到大麦IDC；
第三阶段
第三阶段针对于抢票流程上的系统做了体系化升级，完善了抢票流程和可靠保障机制。升级后的架构可以承接住所有大型抢票需求，用户体验有所提升。
优化动作：
精简了搜索response过大的问题，降低了对宽带的压力；
在阿里域内，大型抢票选座流量直接打到了阿里域内，采用异步和类似ConcurrentHashMap的平衡机制，解决了大麦IDC选座的缓存一致性问题；
继续完善阿里域内交易链路功能，下单接口全部放在阿里域内，下单之后订单同步到大麦IDC内服务履约；
保障流程：
大麦主要是票务平台，主要保障的黄金链路就是抢票，针对于这个链路需要建立可靠性保障和SOP。
抢票分为抢票前、抢票中、抢票后等环节：
抢票前：重点是由业务方抢票申报，再由技术方确认是否安排预演或压测，由业务方判断预案执行范畴及风控级别；
抢票中：重点监控和过程中的应急处理，每逢大促，各个角色聚集一起，各司其职；
围绕于抢票流程，可靠性保障包括：预案/预演/容量等专项；
预案建设：已有成熟的流程不再安排预演，新玩法需要模拟抢票，提前暴露问题，并建立体验问题预案；
容量保障：技术拉取全链路最近类似项目压测数据作为基础数据，和线上真实流量做评估，分析抢票环节是否可以顺利支撑，是否存在性能瓶颈，是否需要做限流；
预案执行：在全链路中找到核心场景，如：首页搜索、商品详情、票务选座、交易下单、票务库存、订单服务、无线端等场景建立预案。同时将高频使用缓存信息在活动开始30分钟预热到缓存中；
问题复盘：针对于每次活动出现的问题、客服反馈、线上问题进行收集，组织复盘，并将todo落实到action上，关注action执行进度；
第四阶段
在进行了全链路系统性完善之后，我们依然不能说肯定不会出现宕机的问题。因为抢票环节注定是少数人可以抢到票，抢不到票的可能在舆情疯狂吐槽。为解决这些问题，我们需要为真正的用户提供极致体验。
新交易系统上线，融合了大麦交易系统和阿里星环平台，渲染接口、下单接口基于星环实现大麦特性扩展。
星环带来的优点有2点：
依托于共享基础能力，除了可以复用共享能力外，还可以参考主站交易的大促方案，比如限流、监控日志、问题排查等。基于星环可以实现未支付关单等个性化能力定制，提高研发效率；
结合集团风控体系，人机识别、定制策略等对非法用户进行了二次拦截，让真实用户抢票体验更好，大大提升了真实用户购买率；
为摸清交易链路的性能水位，需要做到性能常态化，每月定时执行压测、结合当月各项系统功能，评估压测场景和压测目标，压测完成后，更新链路现状，为抢票提供有效数据支撑。
之前的可靠性保障规范不完善，监控、预案、入口不统一。所以建立预案自动化平台，运营在配置抢票活动时【抢票开始前】，可以设置一些预案；在【抢票进行中】可以对核心场景进行统一视图监控，并且有能力实现人为干预和控制；在【抢票结束后】提供历次抢票数据，供分析，帮助运营自助完善，实现自动化流程。
比如针对于商详页，有6-10项降级预案（包括本地缓存或tair缓存、三方依赖接口限流、异常降级等），每个预案设置的值，执行时间都有差异，每次降级操作都需要人工经验判断，操作繁琐。这里需要实现自动化或系统容错实现降级。
总结
经过以上几个阶段，大麦从最开始的“原始”状态进化到了“常态化”流量压测、预案执行新阶段，系统可靠性提升，用户体验提高。后续还需要在项目热度智能分析、风控自动调节等方向进行持续优化。