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

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

在“携号转网”的方案里，要解决这个问题，就必须保持数据的同步更新。一种方案是提供集中式记录（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），规则可能不停变化，甚至有一些特例。不过这都不要紧，因为外部不必知道细节，只要放心调用这个接口既可以，外部原有业务流程照跑。相反，如果暴露的是实现，你就需要在各处不停更新号段规则，如果遇上携号转网这种特例，维护难度更是上了几层楼。

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

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

（编辑：西安站长网）

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