大麦网架构入淘史

大麦网票务系统是它得以在市场立足的基石，由于发展多年，系统中已沉淀了很多业务逻辑。

但早期的大麦网其实是单体系统，内部虽然有一些模块拆分，但整体看还没有满足服务化拆分的效果。所以单体系统所需要面对的问题都会遇到，如维护性差、系统伸缩性差、特别是围绕于票务库存的查询与扣减功能是整个系统的瓶颈。

好的系统不止需要跟得上业务迭代，还需要跟得上技术的发展节奏，只有这样才不会随着时间发展慢慢恶化。

随着阿里对大麦的收购，大麦原有的交易平台开始入淘，商品与交易底层全部是基于阿里共享电商平台实现，入淘之前的架构情况可以看：从大麦网架构学到的东西。

阿里电商平台主要包括用户、商品、营销、交易、支付等全链路的交易能力，经历过高并发、高流量的真实场景验证，同时对于不同业务的多品类、多场景也有很好的支持。

在原有大麦网架构到阿里共享电商平台迁移过程中存在很多挑战。比如既要了解共享电商交易平台的模型，还需要将大麦网业务进行匹配与映射，这块梳理需要消耗非常大的人力，但长远看，基于阿里共享电商平台可以享受很好的稳定性与高性能保障，同时和淘系商品联动，对未来带来了很大的想象空间。

整个架构入淘过程并不是静止的，在入淘的同时还需要支持业务的迭代开发。这个过程的主要做法是，对于经常变化的、行业性较强的业务诉求，大麦倾向于自建体系承接；将变化可能性较小的地方，可以尽量复用集团技术体系。

确定了这个迭代融合节奏，就需要考虑哪些是需要定制化的。这就需要看整体行业发展阶段和特点了。

随着私域流量的兴起，很多场馆都可以通过衍生自己的内容获取自己的用户，整个票务市场正在向着这个方向发展，未来势必有很多ToB的定制化需求。

怎么解决呢？需要在体系化迭代过程中将相关因素考虑进去，可以通过开放平台方式部分解决定制化问题。同时可以借助低代码平台方向，提供工具解决定制化需求。

大麦网的票务系统在承接最热活动时商详页面秒级峰值可以达到大促级别的量级。因此对大麦网架构来说，售票链路需要可以承接高流量同时具备高性能。

大麦网的选票、售卖流程是基于阿里共享电商中台做的，在票务售卖场景下有两个非常重要的环节需要具备高性能和一致性：选座和库存。

选座有三个系统问题需要解决，即高并发、大数据量、高冲突。

对于高并发，大麦网采用并发转串行的方式。比如针对于每个秒级数据生成相应快照，将快照存储在缓存中，请求访问时按照秒级时间戳映射到相对应的时间片缓存上。这样可以减少高并发量级，在满足了座位一致性的同时保证了系统可用性。对于快照缓存的生成，可以控制到秒级以下的分片，依参数灵活控制。

对于大数据量，采用两级压缩方式减小数据量大小。第一级压缩采用自研算法将座位相关的数据进行自定义压缩，类似于座位ID之类的数据可以压缩成偏移量的形式，会出现很多类似于“012”之类的重复字符串，然后采用类似zip、7z之类的通用压缩算法对这类重复字符串进行压缩，这样可以达到很好的压缩比。通过大量测试发现客户端的解压耗时可以忽略不计，大大提升了用户体验。

对于库存链路，做了围绕于性能提升和稳定性保障的工作。首先进行了核心链路与非核心链路的解耦，进行库存读取和库存扣减模块的分离，这也是非常多高并发电商场景的解决方案。同时对于核心链路上的弱依赖进行了降级管理，这样可以提高核心链路的稳定性。

针对于库存场景还存在一个问题，就是数据热点问题，采用了热点离散算法，根据业务数据将相关的库存记录分散到多个库的多个表中，分散单库的行锁压力。同时在某个数据库存扣减达到一定量级触发阈值时，会将额外的并发扣减请求降级为串行扣减请求，保障数据库的高稳定性。

因为票务库存是对物理世界作为的映射，具有比较大的稀缺性，一旦出现不一致问题，在现实世界中就很难解决。所以采用了大事务拆分及实时对账方式保证数据库操作的一致性，防止任何数量的不一致情况发生。

由于日常流量和大促流量差异较大，所以需要具备流量感知并实时扩容的能力，所以通过流量数据、IP热度数据等对大促项目进行预测分析其可能达到的量级，针对于量级给出相应的资源配置，最终决定是否进行扩容或保持现状。

由于大部分故障是由于变更引起的，而变更每天都在发生，如何持续保障系统线上稳定呢？

对于可能产生大事故的事情，做了安全生产红线。线下对红线相关修改进线cr及测试度覆盖，线上对红线相关功能进行实时巡检。同时组织定期全链路压测、故障演练以持续保障线上链路稳定可靠。

在运维层面将所有热门有关的预案执行完全自动化，防止忘记执行预案而产生稳定性问题。对于资源利用、动态扩缩容来说，自动化是最好的方式。但挑战点在于能否准确预测、以及快速扩容，这些都是需要不断探索的。

随着大麦网架构的不断迭代，在解决了基础技术问题及架构问题后，大麦也买入了中台架构阶段。

大麦票务中台主要聚焦于演出票和电影票，在票务视角看，大麦需要支持多个票务类目，但在用户视角看，需要提供一致的最佳体验。对于中台来说肯定先建设通用能力，来支持好大部分类目，会导致一些类目差异点较多，这也是很多中台类系统普遍面对的问题。

一般的解决方案依然是优先服务于通用品类，个别一些具备足够多的个性化特点，其实我们不需要强求必须融入通用体系下，或改变通用体系去迎合，尽可能降低造轮子成本即可。

综上来说，做好一个领域的架构，不仅需要在技术上有很好的积累，还需要从管理到业务都有非常好的思考。

技术上需要有架构能力、中台建设能力、业务建模能力、架构演进设计能力，可以解决高并发、分布式等技术难题。

最好的了解业务的一种方式就是解决不断出现的问题，并且在解决问题过程中深挖问题本质，这样可以促使你快速了解业务。

技术团队需要对于业务和行业有深刻的理解，这样设计出来的系统才可以适应业务和行业的变化，并且在方案落地过程中，为未来业务的发展空间留有余地。每个研发同学都需要思考几年后系统会变成什么样，促使同学共同思考。