概要

此文章基于阿里巴巴-王冬在”2021年5月29日Ocon软件大会第二天-大麦票务技术体系重塑演进之路”的演讲后做的个人总结。

一、分享内容的大概流程

1)这是一个高流量系统的重构经历。

2)这是一个从业务分析到架构落地的完整案例。

3)这个一个大型系统的架构升级实践。

二、目录结构

从高流量说起，定义并解决关键问题。

提炼业务分析方法，确定核心架构。

关键技术方案决策，架构边界清晰。

架构与组织设计。

三、题外话

基于此次软件大会，可以发现一个很突出的特点，优秀的技术人员会把细节把控的很棒，并且很实用，及时总结，及时反思，及时落地，从不拖拉，严于利己，心胸阔达，热爱分享(一定要学好知识，为什么呢？一是自己要学好，二是要传播知识，传播文化，自己学好了才能不误人子弟。)。

四、演讲逻辑

首先说业务，然后说现阶段模式，接着说出现的问题/痛点与改进方式，达到一种什么效果，再接着说出现的问题/痛点(前面的流程线:循环渐进的说)，最后做总结。

细致入微，把某个点说透，让别人知道架构怎么演进，而不是只是让别人觉得自己公司的架构很牛，而不能实现落地。

在这次大会中各个演讲者的差距很明显(不仅仅是技术)，真正脚踏实地做技术的大牛仅占比20%左右。

一、从高流量说起,定义并解决关键问题

业务的不同形态

演唱会:进场十几万人。

马拉松:2-4W人要在2小时内快速入场。

等等。

人:用户热度高,易造成舆情风险

比如，2017年周杰伦活动，图中的商品敏感数据删掉了，可以发现大麦此次的请求量级基本上是和双11一个量级的。

如果项目抗住了流量，那么外界可能会说”系统做的不错”，如果项目没抗住流量，那么外界可能会说”系统做的不行”，以后可能就逐渐失去了热情。

定义当前关键问题:寻找系统关键瓶颈点

寻找问题前，首先要定位问题(系统核心问题)。

首页->导购->商品，可以使用缓存容易解决，缓存的时间可以设置的相对长一点，可能会牺牲用户体验。

最后在支付流程，由于前面的流量大多都挡掉了，其实这里的并发很小。

所以选座和交易这两个方面，是急需解决的问题。

选座的座位量级大约为5-10W，需秒级获取实时状态。

交易，锁库存面临高并发强一致性。

库存是一项特殊的业务，演出票的库存是没法超卖的，无法补库存，即无法临时补座位。

那么其背后的问题是，库存少，用户人多。

这里可以引发一个问题，除了抢票的方式，能否有其他的方式，因为抢票需要提前做好多准备工作，比如好多台机器，可以发现成本和收益比其实是很低的。

比如其他方式，“先报名再摇号”呢？被否定了，因为各个主办方会互相比较谁在比较短的时间内卖完了票。

系统思考方法 :高流量的选座体验升级

在图左上角，系统分析中可以发现，QPS是一个输入，单请求的数据量是一个输入。

QPS越高，总请求量越高，请求压力越大，延迟越高，错误率高，用户体验差，之后用户不断刷新，在用户不断刷新过程中，请求量又升高(这是隐式的连带请求量)，最终导致了恶性循环。

当然了，QPS限流方案，用户体验有些差，是不得已的解决方案。

解决上述问题的核心策略:

1)链路优化->减少系统压力等，减少错误率。

2)数据压缩->10W级座位顺滑。

3)预锁座->降低冲突率。

第一部分，由于每个座位都是一个状态，可以看到右边第一部分，画锁的部分，计算KEY=时间戳%分桶数，比如可以把时间分片，如果是100ms延迟的话，那么可以上10把锁，相当于把1s分成十份，如果是10ms延迟，那么可以把锁变成100把锁。

但这个问题解决并没这么简单，还要解决稳定性问题:比如假如”十万人”都要知道这个状态的话，其实可以让”一个人”进来先看一下，出去之后再通知”所有人”。如果”看的人”堵在里面怎么办，网络延迟等极端情况，那么要把等待请求快速失败，这样整体系统才不会宕掉。

这个时候发现一套缓存集群不够用，对缓存进行分片，之后怕缓存宕掉，如果缓存宕掉，那么整个链路就瘫痪了，所以对整个缓存体系做了双备份。

第二部分，数据量大造成的问题，抢票时，发现网卡被打满了，这个在一般的抢票业务中还是不太常见的，而且序列化和反序列化的时间也很长，所以对于整体的座位，还是希望做数据压缩的。发现现在的数据条件还是是比较符合这种条件的，数据包括ID和状态以及座位静态信息，那么对座位ID做了偏移量的压缩，做了偏移量压缩之后，为啥还要做通用压缩，因为在抢票过程中还有很多爬虫在爬，一方面是为了压缩让数据量更小，另一方面，跳转不同的压缩算法，让爬虫不知道每次是用的哪个压缩协议，如果每个压缩协议都解一遍的话，也是可以达到的，但是效率非常低。

第三部分，其一，预锁座，10W个人抢10个座位，冲突是否很大？一般来说到最后订单详情页去提交的时候，冲突是很大的。

没实施方案前，锁的是DB，相对压力是很大的，成功率20%。

实施新方案后，预锁座状态，轻量级缓存来锁一下，效果好得多，成功率90%。

其二，风控模块，类比DDOS攻击，如果爬虫把每个座位都爬一般的话，那么在一定时间内座位都被锁定了，座位被锁定之后，其他人都会被拒绝服务，这是最直观的情况。

此时利用集团的风控系统去判断哪些请求时疑似爬虫请求，但是也不可能解决所有爬虫问题。这里对每个请求加一个超时时间，超时时间不是固定值，是基于抢票的热度和当时的情况去做的超时值的设计。

最终，选座方案，通过以上三种方式，就把一个比较大的并发请求转换成一个比较小的并发请求，数据做到最小，多种压缩算法去抵挡爬虫，最后通过预锁座的方式来减少系统在前一分钟的压力。

重视安全生产:高并发的库存一致性保障

选座方案依赖库存系统，每个座位都对应系统中的一个库存，库存做的一个比较通用的方式。

基本方式:抢票分组和低频分组分开，因为在抢票的过程中，正常还是需要售卖的，库存的查询和扣减分开，缓存前置，一些依赖作为弱依赖，假设系统宕掉，只依赖DB即可。

扣减库存，最大的瓶颈就是行锁，针对于行锁的优化，对场次所有的库存做了拆分，让不同的库存拆分到不同的库的不同的表里，那么在物理上来说就隔离了，这里复用了双11的补丁，理解成对于事物上的优化，极大的提升行锁的性能，最后为了保险做了基于单库的阈值排队，对单库做了整体的压测，压测80%的量，对于每个库做了单个阈值，如果当整体的并发扣减请求达到这个阈值之后，之后所有的请求就变成串行了。扣库存的事物，把一个大事物拆分成一个一个小的事物，用对账表的方式保证一致性。

库存必须是没问题的。即使平时在不断的迭代，库存的核心也可能是不变的，但是基于库存的加加减减可能会有逻辑的改动，新人和老人不出问题，这个保证不了。只要防御不出大的问题，1W个库存超了5个没啥事。

如何保证在高速的迭代保证系统不出大问题，那么针对库存的所有场景，做库存的红线机制，也就是库存的约束表达式，针对于每次库存的扣减情况与回滚情况都会做表达式实时的巡检，保证库存不出大的问题，可以思考自己做的系统可能出现的最大的问题是什么，怎么避免这种问题。大麦如果出现了超几百个库存的问题，也是没有什么办法解救的。

复用已有能力:保障研发效率及稳定性

利用阿里现有的支付中台体系。把集团的能力应用到了大麦。

问题:

全链路业务模型的匹配度,票务模型能否匹配到一般的商品模式上(模型不匹配，影响效率。);

未来业务演进的灵活性

演出项目:项目场次和票价。

场次和票价做层次处理，关联到SKU即可。这个模型匹配比较简单。

用阿里的共享交易体系去做，整体的成本节省很多，如何保证灵活性，希望尽量共享模型复用，票务模型最好能在自己的掌控范围内来迭代，最好把票务相关的业务去切开，保证灵活性，一会还会有讲到。

二、提炼业务分析方法,确定核心架构

业务的关键流程

三大角色:主办方、监管方、场馆方。

票房规划后形成一个个库存，自销或分销，监管方去监管。用户拿票入场核验。

从核心角色诉求到核心技术能力

沉淀分析方法,从业务分析到核心架构

这是一个自顶向下的方法，而不是自底向上的方法，自顶向下需要对业务有很深的了解。

三、关键技术方案决策,架构边界清晰

货:座位是库存,对座位的产销突显其行业性

在整个票务流程中，票是处于核心位置的，票是核心的实体。票在生产过程中有画座和票房规划，在分销时，会预留座位，选座(特定的人)，补选，机选。这样也方便统计上座率。

这个能力是这个行业中特有的能力，所以不能复用阿里的核心交易中台。

要把特定能力和共有能力区分开。

保障灵活演进:划定体系边界,隔离票务行业性

1)复用性:大麦交易体系是基于共享交易体系去做的。

2)隔离行业性:要解决座位的产和销问题。核心实体是库存，也是座位。产和销是两个能力，这两个能力也是最终的系统核心能力。

3)麦场:系统对接，接入的公共报文，各个商家的隔离性，不要因为一个商家的问题影响其他的商家。通用能力处理完成之后，要规模化的去做。这么多的商家是一个个的接入还是一起接入，这样基于ISV做接口的适配，一家家的做还是规模化的做都是可以的。但是要注意在前期的接入过程中，接口适配器写的越来越多的泛滥问题。

围绕行业能力升级:作为产销的体验升级

围绕核心座位一系列体验升级:基于插件的思路，画座的能力，统一升级，整体渲染规范，刚开始是每个端自定义标签做逻辑，后来统一CSS规范。

通过VR的方式，实景的看到座位的视角，刚开始是先建模，生成全景图，后来发现成本太高了，最后采用了比较简单的方案，首先根据大的座位图，在哪儿些点采集是比较好的，找人拿全景相机去实体拍摄即可，拿拍的照片和实际座位去绑定即可，有时太高大上的方案还是比较困难的，可以找一些比较简单的方案去做。

经验系统化:座位机选及票房规划提效

当然这里还有预售这个核心问题，卖的过程中，用户是不知道座位的(隐形的问题)，后台有人员用支付的优先级去人工选座，人一个个去处理的，需要几百人去做。现在把这种事情做成系统化，做了数字化评分，每一排每个座位，包括每个看台，都有优先级，再通过优先级进行机器选座。

后来发现，票房选座和机选是大同小异的，无非是好的座位，计算好价格，就可复用到机选上面了。

架构师一定要发现一线同学的问题，系统化的解决掉。

场:现场服务的核心挑战

应对极端情况:现场高可用方案

大麦的两个业务场景:

Chinajoin，十几万人入场。

马拉松入场，俩小时之内最多进入5W人左右，那么一个人平均进场的时间很短。

现场需要急需应对的极端情况:断网和断电，比如连网管的网线被踢掉了，或者突然没电了，导致当时的验票不行，需要在现场做高稳定性处理。

其一、断网场景:

问题描述:每个检票口离了好几公里，每个检票口设置本地服务器，在断网的请看下，数据很难同步，不同的口互相读不到，会给黄牛等不法分子可乘之机，看起来是小问题，但是票的附加值是比较高的，处理不好会给现场带来很大的混乱。

问题解决:

右边的图闸机、PDA与麦小智通过路由器连接，路由器连接阿里云，这是有网的状态。

麦小智是解决验票点之间的数据同步问题。断网，也可以通过lora同步。

断网是不好的，在麦小智上又增加了4G网卡和NBLT的支持，外网断掉还可以通过4G网卡备份，4G可能信号也会不好，也会拿NBLT来备份。

以前的原方案:在会场周围加很多NP的杆子，NP之间做中间连接，缺点:每个杆子找一个人去盯着，杆子只要被踢掉了，网络就断了。

其二、断电场景:

大型赛事用闸机，闸机验票还有挡人流的功能。

断电后闸机怎么用呢，由于UPS电源成本很高，只能用PDA一个个去验证，如果人群管不住，其实也保证不了，有专门人员去拦截人群解决问题。

软硬件分离的架构设计:现场多设备管控及适配

除了网络问题，还有各种各样的硬件。

硬件需要安全的管控，接入LOT的平台，进行实时的管控，把业务逻辑和驱动逻辑拆分出来。

有些硬件需要做疲劳度测试，相当于把接口和实现分开，这样就很容易做疲劳度测试。

提升研发及管控效率 :云边端一体化

每个端:PDA、本地端、云端，都需要支持整体的验票逻辑。

验票逻辑，三个端都会有:云端挂了->本地端->PDA端

一体化的SDK去解决问题:

1)离线模式支持PDA的验票。

2)云端的模式,小剧场的。

3)云边端模式,马拉松。

以上的三个层次保持了系统的稳定性。

现场解决方案全景图

整个三层体系。

端程序，离线数据服务，支持断电场景。

云端，支持多个票务系统数据导入。

本地服务，基本DOCKER化，利用K8S管控。

麦小智主网设备，保证每个主网之间的数据同步和网络是可户备的。

总结

不同的类目有不同的差异点。

做行业SAAS，SAAS其实一般是技术开发平台，并相应加入业务属性，这里作者起名叫TPASS平台。

四、架构与组织设计

找到适于当前的最优团队设计

无线团队，可快速响应无线的需求。

当无线体系比较成熟的时候，这个团队带来的是比较低效的。

属于中转需求的团队，沟通效率低，转换和包装的功能，成长比较困难。

后来把无线服务层下沉到各个业务团队，有公共的东西还需做一些管控，做了framework去做公共的内容。

针对不同的业务和技术时期，可以采用不同的服务划分方式，取决于当前是什么阶段。

业务架构与团队相互协调一致

康威定律。

业务架构和技术架构保持一致。这样效率最高。这个过程中出现的问题，比如上游和下游，上下游都说自己是平台，不会单接入，得对方推送过来，无非是决定性问题，就是下游团队做，但是需要通过数据适配器的方式去做衔接，业务上可做很多的扩展。需要看业务边界，不然所有业务系统都会有适配器，最后会很乱。

从顶层架构要清晰，至少顶层不会出问题，如果某个出问题，单做就好了，因为边界是清晰的。

应用之间会有很多关系，要明确。单独重构一个应用，最后是这个应用中的模块关系。

最终:

大的边界不要出错，

由大到小，

大的边界总架构师负责，

应用边界具体子域负责，

应用之内的模块具体模块负责。

五、总结

核心角色的核心诉求，来定义核心架构;

定义问题很重要，首要思考是定义好关键问题并解决它;

根据业务特性平衡复用性与灵活性，行业特性可灵活演进;

强化核心能力，重点打磨行业特性，形成优势;

业务架构与组织设计相协调。

最后，

行业特性，要通过独立体系来承接。

行业能力要做深做透，这是行业的立身之本。