分区定价就是将同一个场次的座位分割成不同的区域，以不同的价格进行售卖。不同的座位，不同的价格，在上座率和价格之间求得一个平衡，帮助影院实现收入的最大化。同时，通过异业合作或者绑定会员权益等手段，将权益与座位“对号入座”，实现更加精细化的运营策略。
一、技术挑战-不仅仅是改个价格
“同场同价”-在线选座系统的地基
分区定价要想落地，对于技术来说，并非是改个价格那么简单。
自 2010 年，电影行业出现在线选座业务以来，场次都是定价的最小粒度，影院会根据影厅及放映影片、放映时间等对整个场次的座位进行统一定价，这就是所谓“同场同价”。这个思维定势一直贯穿在在线选座系统的设计实现和升级过程中。在线选座系统的基础数据、交易、网关、营销等核心服务模块，都是基于上述思路进行搭建。
发展到今天，在线选座的业务绝非仅仅是锁座-下单-出票那么简单，如果说 2010 年的系统规模是一栋平房，那如今的规模可以称得上是 500 层的高楼了，那么要改动从系统搭建初期就已定下的规则，就如同重新打造这幢高楼的地基一般，这个挑战可想而知。
怎么做分区定价，不同系统商有不同的说法
淘票票作为领先的观影购票平台，中国电影市场的很大一部分票房是由淘票票的用户贡献的。然而，淘票票并非电影票的最终出票者，影院才是。淘票票通过对接影院安装的具有售票资质的售票系统，完成出票。
目前，具有售票资质的系统商有七家，如凤凰云智、佳影、鼎新等，在系统商的基础上，还有搭建自己售票能力的电商，如大地、万达等等。上述提到的系统商加电商（下文统称合作商），代表全国近万家影院，定义了影院本地售票系统的接口协议和标准。对于分区定价，他们接口层面有不同的诠释。这就为我们带来了第二个挑战，如何适配众多结构不一的分区定价接口。
如何快速响应？
时间是个永恒的话题。如何在较短的时间内，面对较大的技术复杂性，去支撑业务的急速变化，这也是我们在实现分区定价过程中遇到的问题。
二、方案-控边界，以不变应万变
思路
我们从业务建模出发，构建问题空间模型，然后落实到系统上，逐个击破，用系统建模的方式产出解决方案模型，最后用技术手段实现。根据第二章节的阐述，我们抽象出分区定价的两个核心问题：
1）售票的定价维度从场次精确到座位；
2）适配各个合作商不同的分区定价接口。
按照领域建模的沉淀内聚的原则，尽量将变更收敛控制在相关的业务域内。因此接下来我们针对上述两个问题进行抽解、推理：
a）将座位的定价维度精确到座位，分区定价，核心就是价格，价格属性是贯穿整个服务集群的重要属性。基础数据、交易、营销甚至网关系统都依赖价格。然而价格本身并不是一个独立的模型，而是商品模型的一个属性，这里的商品模型也可以认为是场次或者排期模型。基础数据、交易、营销等各个业务域所依赖的是商品模型，并非价格。一个普通场次对应一个商品，而对分区定价场次来说，可能一个场次可能对应多个商品。因此针对这个问题我们的解决思路是：抽象分区定价数据到商品模型，交易、营销等模块依赖商品中的价格属性去实现收单、交易履行等模块，尽量不感知分区细节逻辑；
b）适配各个合作商的分区定价接口，我们的原则是尽量减少其对上层业务的侵入，将其差异屏蔽到底层模块，并对上层提供统一的接口。虽然各个合作商提供的分区定价服务有所差异，但是基本上可以抽象为排期拉取、锁座、解锁座位、出票等模块，而这些底层模块与上层的交互是统一且确定的。因此针对这个问题我们的解决思路是：网关域适配个合作商的分区定价接口，组装统一结构的基础数据，暴露统一标准的锁座、出票等服务，将分区定价的基础服务能力沉淀内聚到网关层。
架构与实现
综上所述，淘票票对于分区定价的实现方式可总结为以下几点：
1）网关层沉淀封装排期拉取、座位图拉取、锁座、出票、解锁座位等能力，并对外暴露统一标准的基础服务；
2）抽象分区定价的数据到商品及排期模型中，对外提供统一结构的数据模型；
3）上层模块基于底层的基础数据和服务，以通用逻辑进行适配，尽量减少对上层业务的侵入。
具体如下图所示：
最终答卷
通过上述的解决方案，淘票票在较短的时间内完成了对分区定价业务的支撑，覆盖了行业内多数合作商和影院，同时系统具备一定的可扩展性和复用性，能够以较低成本实现合作商的对接。
四、思考
快速的业务变化，如何应对，并沉淀技术能力？
快速变化是互联网行业一个无法回避的问题，由于技术人员距离业务前线相对较远，在应对过程中难免显得被动和疲倦。“面向复制-粘贴的编程模式”“先 run 起来”“赶一下进度，后面再重构”、“必须马上上线”等等这些传统应对方式就会大显身手。然而，这些手段纵然能够“快速”支撑业务，也造成了一些恶果。其一，代码的可复用性和可扩展性极差；其二，技术债高垒，影响开发效率，增加变更风险，降低技术竞争力，甚至反过来影响业务和团队。在快速交付的前提下，在分区定价项目的实践过程中，我们总结出以下几点经验：
1）规范技术债的管理机制，对于需要优化的模块，在项目上线之初，就要确定迭代计划。这是最简单却很容易见效的手段；
2）定位核心变更，并将核心模块收敛到尽量少的业务域中，沉淀能力，便于统一管理、复用和扩展。比如在分区定价架构设计中，我们把核心模块落地在基础数据域和网关域，在不影响业务交付的前提下，也使得系统具备一定的扩展和复用能力；
3）拉进业务距离，尽可能多的理解业务诉求、未来规划等等，在设计阶段，把这些信息带入思考，能够使我们在面对变化时更加从容。
业务技术，做业务还是做技术，技术性体现在哪里？
在业务开发的角色上，面对纷繁的业务需求，很多人会产生困惑，到底是在做技术，还是在做业务，其技术含量体现在哪里？
通过上文所述，一些业务需求的复杂性未必就逊色于底层技术。我们产生困惑的原因，更多的还是面对的问题不一样。业务技术面对的问题变化更快、领域横向上更广；底层技术面对的问题更加稳定，领域纵向上更加深入，但是大家解决问题的能力是共通的，比如编程能力、抽象建模能力、结构化思维能力、落地能力等等。
因此业务开发并不简单，只是大家想“简单”了，或者说在用“简单”的方式做业务开发。我们认为，尊重业务需求，夯实编程、抽象建模、落地等能力，并在项目实践中充分思考和应用，业务一样可以做的很“技术”。
作者简介：
阿里文娱开发工程师 暮平
相关链接
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论