余晟：从软件设计角度看携号转网

目前大量的短信服务提供商判断用户所属的运营商时，完全是按照线下约定的规则。比如“130 开头是联通的，135-139 开头是移动的，189 开头是电信的”。短信服务商在收到短信数据包之后，会首先按照号段把任务分开，对接到不同的运营商通道进行发送。对于携号转网的用户，会被首先按照号码分配到原有的运营商通道，而该运营商已经不负责该用户了，短信就无法发送——当然反过来看，它也可以屏蔽大部分垃圾短信。

这个问题在充值时也存在。许多充值网站会根据用户输入的手机号来自动选择运营商，它看起来方便，但携号换网的用户也会出现错误。此外，在一些需要判断用户归属运营商的场合，也会有同样问题，如果你输入的手机号“看起来”是联通的，其实已经转到了移动，而系统又是根据号段来判断运营商的，就会报错，无法继续使用。

如果我们暂时放下对运营商的评价，单纯聚焦在携号转网的技术方案，就会发现这其实是开发中很常见的问题：资源迁移的要如何设计？

狭义的迁移很简单，只是 donor（原资源持有方）对 recipient（新资源持有方）做数据传输而已。但是安全的系统必须要解决一个问题：如何判断这种迁移真的可信的？

携号转网的 recipient led 方案中，recipient 可以直接发起资源迁移请求，donor 会信任这种请求，这看起来足够简单直接，但它有一个前提条件，运营商数量不多，成立门槛很高，追责也很方便。如果不具备这个前提条件，资源持有方很多，成立门槛也很低，那么直接由 recipient 向 donor 申请数据迁移就会面临安全问题。

这个问题要怎么解决？我们可以想想如今网上流行的 OAuth 是怎么做的？当 recipient 向 donor 发出申请时，多了一道“donor 与用户确认”的手续，因为有用户的直接参与，就解决了“信任”的问题。

当然办法不止一种，也可以借鉴 donor led 的方案，由用户先向 donor 获得许可及验证码，再完成迁移——实际上，域名迁移正是采用的这种方案，它解决了“众多服务商”环境下建立信任的问题。

但是只做到这一步，并不算资源迁移方案。称职的工程师一定不能只看到眼前的这一点，还必须做完整的方案，保证迁移完成之后，所有相关的业务都保持平稳顺利，不受影响。你看了上面的 ACQ/CDB 方案，大概会觉得“这不是显然的事”嘛，但现实未必如此，这是有无数痛苦教训的。

许多年前我开发过电商的物流系统。有一天，业务的人问：“为了节省成本，同一个收件人的两件货品，是不是可以合并发货？” 负责开发的程序员一听：“这个没问题呀，这个简单，我马上就可以做好”。

没两天真的就开发完成了，拣货、打包、出仓、挂号分配和录入，确实都没有问题，于是顺利上线。刚开始一切正常，他俩正打算为这个”透明“的方案邀功，前方传来大量投诉，相关人员叫苦不迭。

一问才发现，这个工程师根本没考虑异常情况。两件货可以拼单，那么三件货，四件货呢？合并的最小单位到底是货物还是订单？如果用户要发票，到底是开一张票还是两张票？和供应商结算的时候，运费怎么分摊？最麻烦的是逆向流程——如果用户要针对其中某件商品退款或者退货，到底要如何操作？费用又如何计算？

轻率决定的后果就是，一定要踩了大坑才知道，“合并发货”真不是看上去那么简单，远比想象的要麻烦得多。它也不是程序员或者小产品经理能搞定的，还必须加上物流、财务等等一大圈人。程序员想当然“没问题”，造成了很多问题，给所有人都挖了个大坑……

回到数据迁移问题，我见过好些数据迁移方案，完全就是想当然，“我知道这里数据迁走了”，拍拍脑袋就做了，拍拍屁股就迁了。设计者根本不考虑其他人，完全没想过“其他人或业务知不知道数据迁走了”，也不关心其他人或其它业务后来会怎么办。

在“携号转网”的方案里，要解决这个问题，就必须保持数据的同步更新。一种方案是提供集中式记录（ACQ/CDB）方案，这种方案职责清晰，能保持通话路径最短，但是对中心节点的稳定性、响应速度、复杂能力都提出了很高的要求。

另一种 indirect routing 在某种意义上可以称为“分布式”方案，即必须通过原服务商来中转，这时候转网信息碎片其实是由运营商各自维护的。这种方案不需要花大力气建设中心节点，缺点则是职责不清晰，多了不必要的中转，已迁移用户仍然会受原运营商服务质量的影响。

中转还会带来其它问题：如果用户多次迁移就会形成“中转链条”，链条一长，不但影响效率，排查问题也异常麻烦。这还没完，如果设计不当还可能形成环路……

最后我们不妨再深挖一点——所谓“携号转网”，真正跳出来看，核心就是一个函数问题。

函数最简单的方式是 f(x) = y，这大家都知道。对携号转网来说，关键也是根据手机号查询运营商，它可以看作 f(x) = y，其中 x 就是“具体的手机号”，y 就是“运营商”。只要掌握了这个信息，其它都好办。

虽然大家都默认有 f(x) = y 这个函数，但许多人也知道函数f的内部到底是怎么做的，而且这个函数并没有官方版本，所以基本所有人都自己实现了一遍：130~133 号段是联通，135～139 号段是移动，189 号段是电信……

同时我们也知道，软件设计中提倡“暴露接口而不暴露实现”。为什么呢？因为接口是关于抽象行为的定义，比如“输入手机号，得到运营商”就是抽象行为，它包装了 f(x) = y，至于哪个手机号（x）对到哪个运营商（y），规则可能不停变化，甚至有一些特例。不过这都不要紧，因为外部不必知道细节，只要放心调用这个接口既可以，外部原有业务流程照跑。相反，如果暴露的是实现，你就需要在各处不停更新号段规则，如果遇上携号转网这种特例，维护难度更是上了几层楼。

那么“根据手机号查询运营商”的功能，为什么暴露的是实现而不是接口呢？这大概有历史原因，缺乏顶层设计，一开始没有权威公用接口，实现这种接口要承受巨大的负载，技术上有挑战……

所以，早期许多技术问题，确实都是采用“线下共识”来解决的。比如早期不少电商的订单号，上面就承载了很多信息，单纯看订单号就可以识别出下单日期、所属仓库、商品种类等等。

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!