机票分享第六篇 机票搜索系统演进的经验

机票业务非常复杂，我们不得不应对这些复杂，也不断的想出一些招数演进系统。我回顾所做的事，再次思考并归纳核心思路，完成了本篇。

一、最大化统一，最小化变化

业务复杂，更不能随意新增接口、流程，思考如何将不同场景的流程融合在一起。

图例：逐级搜索机票展示结果

航班页、低价页、填写页没人会拆成三个流程分别实现，尽可能提取出不变的部分，将变化降到最低。低价页支持填充坑位的需求之前，排序层统一做合并；之后，排序层统一做坑位填充。

配图：低价页需要支持填充坑位，那航班页也采用填充方式

流程所经过的分层、步骤是统一的，一些细节的操作是变化的。

表格：每一层变化的部分

二、标准化，模块化，配置化

随着不断新增的业务场景，被动引入各种类型的变化，流程越改越乱，配置纠缠不清。直到有一天老板也看不下去了：“你们只会加那不叫本事，敢于删才叫本事”。但要怎么删呢？

配图：各种if、else，各种配置，乱作一团

不同来源对应不同变化，将散乱的来源标准化，用以规范变化的引入。

将同类变化提炼到一起，固化成业务上内聚的模块。

将提练后剩下的真正变化采用配置的形式。

配图：变化来源的三大类别，渠道、人群、搜索模式；变化行为属于平台控制的各个业务模块

渠道的定义“端、容器、入口”并不是包含关系，而是组合。像改签搜索、机票宝贝搜索相关的一类需求，我们称作入口。

这样一来，航司限价的代码是通用的，变化的只是对“API-MTOP-外采”设置所有航司不限，对“无线-APP-小搜”配置限价航司。流程是通用的，变化被配置化。

三、产品化

航司限价有了针对不同渠道、人群的配置，配置是否对业务方足够透明，使其完全了解业务含义，并独立修改呢？由研发人员修改的配置只是另外形式的代码，被业务方使用的配置才是可控的产品。

曾经排查线上特定商品不展示问题，有段业务逻辑把该商品干掉了，运营根本不知道有这个功能，只有代码自己知道。

不断迭代的需求，不断引入的变化，缺少输出、无法控制，代码静静的躺在那里，有多可怕。

前面提到的都是引入变化的技巧。复杂的业务往往对应更多的模块、分层、系统，后面谈谈边界及交互的思路。

四、明晰边界

做划分通常会遵从高内聚、低耦合的标准，实际操作时往往没那么简单，时不时会遇到些模棱两可的情况。

1、改签流程中，交易与搜索系统的边界

计算改签费用放在哪做成为争论的焦点。只返回将改签到的商品的官方指导价，还是算出改签客户要付的费用来？最终结论是计算改签费用放在交易。因为搜索系统是无状态的，而订单是有状态的，所以和状态相关（比如二次改和一次改手续费算法不同）的逻辑放在交易系统更合适。也许这次的需求只支持一次改，只是一个固定的手续费，但一定要把潜在引入的变化考虑进去。对于本例，我们找出了两个系统不同的本质特性“状态”，从而判断出功能适合内聚到哪。

配图：搜索要支持改签按航司规定的过滤（蓝色），该不该支持改签费用计算（绿色）？

2、特殊优惠展示成划价，放在搜索还是营销系统？

营销已经实现了用划价展示已减优惠（营销系统知道）；新增的特殊优惠（搜索系统知道、营销系统不知道）希望展示成划价的形式。如果只考虑工作量，让营销系统把特殊优惠也作为一种优惠来处理，复用划价展示的逻辑。另外的做法是搜索也支持划价展示，相当于展示层需要感知搜索、营销两者的划价展示。是否放到营销的关键点是确定系统边界，是不是以后所有的减价形式都算营销？

配图：最终采用的方案，搜索告诉营销系统动态新增特殊优惠的活动（绿色）

直到项目做完我心里也没有定论，用的是不是最合理的方案。似乎放在搜索合理一些，但如果仅仅为支持这一个业务场景去改动，考虑的还不够全面。

五、统一交互

交互时始终使用同一种语言才方便，机票搜索本质是商品的搜索，需要统一的商品模型，我们实际做的还不够。

1、搜索系统在填单页把商品快照给交易系统，商品模型不够完善，不包含“是否验价”、“验价的office号”、“是否自动占座”等信息，交易系统需要自己判断从哪个基础数据上获取相应信息。

配图：商品快照，一半是商品模型，一半是数据库对象

2、国内与国际搜索商品模型不统一，造成营销需要分别为国际国内提供二方包。

配图：营销分别提供国内、国际工具，来匹配不同格式的机票商品

试想如果有统一的机票商品模型，这些流程会方便很多，国内与国际的联程拼接实现起来也会简单许多。