北京治疗白癜风最好的医院是 http://m.39.net/pf/a_4579738.html业务特点
大麦业务链条涵盖了从B端生产、C端销售、现场换验的全套流程。其业务架构也经过几个阶段的发展：
第一阶段：保障不健全、设施不完善；
第二阶段：支持部分大型抢票需求；
第三阶段：“体系化”承接所有大型抢票需求；
第四阶段：“常态化”体验优化；
第一阶段
此时的大麦架构还在大麦自己的IDC内，主要是原有大麦技术架构承担需求。此时的架构存在以下几个问题：
保障设施不健全：大麦IDC机房硬件、快递均有限制，DB还是SqlServer，很多库是单库，不能应对大型抢票时的挑战；
预案、限流不健全：系统在面对高流量时，没有自我保护措施；
监控运维手段零散：定位问题、解决问题耗时长；
解决方案
这一阶段主要是一些零散解决方案，针对问题解决。比如搭建简易版限流方案，做性能优化点，整体上未体系化解决问题。
第二阶段
第二阶段由于已经被阿里收购，所以架构重构直接切入阿里域内解决方案，逐步替换掉老系统。
这一阶段的关键就是新老方案的迁移：
APP链路改造：技术改造重点放在无线端，所有APP流量先进入阿里域，再路由到大麦IDC，让阿里机房抵挡大量流量；
借助阿里基础运维设施：由于入口流量直接进入阿里域，降级、限流的动作可以依赖于阿里服务治理平台能力做；
建立抢票预案：围绕于大型抢票场景做预案建设，比如商详页增加tair缓存，靠tair抗住阿里域流量，建设流量打到大麦IDC；
第三阶段
第三阶段针对于抢票流程上的系统做了体系化升级，完善了抢票流程和可靠保障机制。升级后的架构可以承接住所有大型抢票需求，用户体验有所提升。
优化动作：
精简了搜索response过大的问题，降低了对宽带的压力；
在阿里域内，大型抢票选座流量直接打到了阿里域内，采用异步和类似ConcurrentHashMap的平衡机制，解决了大麦IDC选座的缓存一致性问题；
继续完善阿里域内交易链路功能，下单接口全部放在阿里域内，下单之后订单同步到大麦IDC内服务履约；
保障流程：
大麦主要是票务平台，主要保障的*金链路就是抢票，针对于这个链路需要建立可靠性保障和SOP。
抢票分为抢票前、抢票中、抢票后等环节：
抢票前：重点是由业务方抢票申报，再由技术方确认是否安排预演或压测，由业务方判断预案执行范畴及风控级别；
抢票中：重点监控和过程中的应急处理，每逢大促，各个角色聚集一起，各司其职；
围绕于抢票流程，可靠性保障包括：预案/预演/容量等专项；
预案建设：已有成熟的流程不再安排预演，新玩法需要模拟抢票，提前暴露问题，并建立体验问题预案；
容量保障：技术拉取全链路最近类似项目压测数据作为基础数据，和线上真实流量做评估，分析抢票环节是否可以顺利支撑，是否存在性能瓶颈，是否需要做限流；
预案执行：在全链路中找到核心场景，如：首页搜索、商品详情、票务选座、交易下单、票务库存、订单服务、无线端等场景建立预案。同时将高频使用缓存信息在活动开始30分钟预热到缓存中；
问题复盘：针对于每次活动出现的问题、客服反馈、线上问题进行收集，组织复盘，并将todo落实到action上，
