基于优先级配置矩阵的套餐系统
在数学中，矩阵（Matrix）是一个按照长方阵列排列的复数或实数集合。
有限的因变量与自由发挥的自变量
先设定一下业务场景，假设我们要做电话套餐系统。
一个电话套餐里直接影响客户使用体验的是：
价格
通话
每月免费接听时长
每分钟接听收费
每月免费拨打时长
每分钟拨号收费
短信
每月免费条数
每条收费金额
流量
是否降速无限流量
流量包购买价格
套餐内包含流量
本文称呼上述的内容是一个套餐系统中的因变量，是最终结果，其值由多个自变量联合确定。电话套餐的因变量可能不止于这些内容，但其总是有限可枚举的。
对应的，本文将以下内容称为 自变量：
地域（这个无限流量的套餐只能给广东省客户的）
身份（看在他还在读书的份上，套餐费用给他减几块钱吧）
公司（这个是合作公司，整个公司都用我们的短号，这个套餐必须要优惠点）
客户画像（这货看起来很有钱，对他展示一些高价套餐，同时象征性给他多一点通话时长吧）
营销入口（这个从我们的活动链接进来薅羊毛的，还是给他减点价吧）
使用的客户端（最近在推广APP,在APP申请的套餐给他送点流量吧）
基础套餐定义（这个套餐叫 无线流量卡，客户申请这个套餐时，我们给他一个基准内容吧）
......
导致因变量变化的自变量很多，同时多个自变量也有可能联合使用触发新规则：
地域为广东地区身份为学生的客户购买套餐时 额外送1G
公司为 X 的 领导岗位 免话费
......
相对于因变量，自变量及其组合的数量可能难以想象的庞大。
如果每个自变量的组合等情况都要在我们的系统中通过代码来定义，这是一个难以想象的灾难。
此时此刻产品、渠道等自变量究竟是什么
一个人，在公司里是员工，在父母前是儿子，在老婆前是丈夫，在车里他是司机。
人是多面的，在每个不同的场景有不同的表现，并且在特定的场景也只需要有特定的表现，而不能串场。
我们业务系统里的渠道可能是 APP,小程序，H5,桌面应用等，这些渠道自身有很多其他的特性，但在套餐系统关心的渠道仅仅是：
当渠道为APP时，额外赠送1G流量，减免5块钱
当渠道为小程序时，送100M流量
......
这些对套餐的影响，定义了在 套餐场景下，一个渠道是什么。
同理，我们依然可以通过同样的形式，定义套餐系统里 地域的含义，身份的含义，营销入口的含义，这与NLP中的词向量有异曲同工之妙。
| 自变量类型 | 自变量值 | 流量 | 免费通话时长 | 套餐价格 | 赠送彩铃 |
|---|---|---|---|---|---|
| 营销入口 | 合作公司A | + 1G | null | 95折 | 否 |
| 营销入口 | 合作公司B | null | +10min | 95折 | 否 |
| 渠道 | APP | +1G | null | -5元 | 是 |
| 渠道 | 公众号 | +100M | null | null | 否 |
| 基础套餐定义 | 流量霸王套餐 | 5G | 30min | 58元 | 否 |
| 基础套餐定义 | 通话大咖套餐 | 1G | 180min | 58元 | 否 |
通过自变量确定因变量
要通过自变量（外部套餐，渠道，营销入口等）计算出因变量（最终面向客户的套餐内容），首先要确定的是 计算规则。
一个可供的参考的形式如下：
为每个自变量类型确定整体的执行优先级
为每个因变量类型确定计算的形式
如上一节的表格中，我们可以定义各类自变量计算优先级：
基础套餐定义 低
渠道 中
营销入口 高
那么 合作公司A引流的客户在App中 选择了 流量霸王套餐 ，那么它的流量是
5G + 1G + 1G = 7G
上面的规则很简单，就是简单的加减操作
而赠送彩铃可以选择另外的规则，只要出现过“是”，那就“是”
否 + 是 + 否 = 是
多自变量联合确定的操作内容的场景
如果出现了
“当 营销入口为 A 公司 渠道用的是 APP时，
给我再额外送2G流量”
又或者
“我不管你什么设计，我的这个套餐就是不允许
其他乱七八糟的 渠道、营销入口修改内容”
等需求时，就会打破上述简单的按照单个自变量优先级排序的规则
我们可以额外新增一个更高优先级的自变量，以实现特定的需求
| 自变量类型 | 自变量类型优先级（数字越大越优先） |
|---|---|
| 基础套餐定义 | 10 |
| 渠道 | 20 |
| 营销入口 | 30 |
| 营销入口 + 渠道 | 50 |
| 特殊不可修改套餐 | 100 |
这样我们就可以解决业务的特殊需求。
优缺点分析
我们分析一下，该种解决方案的优缺点。
优缺点是通过比较而得到的，我们对比的解决方案假定上述的套餐最终定义是通过Hard-Code实现的，那么：
优点：
自变量定义显式化
我们可以快速地知道所谓的 渠道、营销入口、省份等概念，在套餐系统中起到的作用是什么
最终套餐表现显式化
只要确定了自变量的值，我们就可以从，配置表中抽取出特定配置，构建出一个按照行优先级排序的矩阵，从而快速得到最终套餐的表现
节约开发资源
在确定套餐内容过程中，可以统一处理所有自变量对应的属性
在没有新增 因变量时，开发工作量极少，甚至免于开发
业务获得了其最大的灵活度
特殊逻辑外置化
业务有时会像上面提出的“这个套餐不能被任何其他自变量配置修改”的需求时，我们可以让其自行通过配置实现，而不用污染我们的代码
至于后续这个业务配置变得怎么乱，其都是由于业务自身思考不合理导致，配置信息由业务主管，其需要为自己的配置负责。
缺点：
可能需要给业务提供一个友好的配置界面，需要点开发工作量
上面的电话套餐只是一个举例，我们可以很容易地将这个简单的设计迁移到其他类似的场景，如汽车定制套餐，贷款套餐等。
关于作者
作者曾在两家排名前三的股份制商业银行工作过，目前在一家排名前二的互联网银行工作，做过业务，做过中间件，做过架构，也带过小团队。
公众号会定期分享个人关于 技术、架构、业务 等的思考，欢迎关注公众号。
同时欢迎添加个人微信skyesx探讨技术相关问题，请备注名字+公司。
本文有任何不妥欢迎留言斧正，若本文能带给你收获，请不吝分享！
推荐阅读
从分治的思想到架构的设计
谈复用的成本与中台的建设