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

今朝大量的短信处事提供商判定用户所属的运营商时，完满是凭证线下约定的法则。好比“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），法则也许不断变革，乃至有一些特例。不外这都没相关，由于外部不必知道细节，只要安心挪用这个接口既可以，外部原有营业流程照跑。相反，假如袒露的是实现，你就必要在遍地不断更新号段法则，假如赶上携号转网这种特例，维护难度更是上了几层楼。

那么“按照手机号查询运营商”的成果，为什么袒露的是实现而不是接口呢？这或许有汗青缘故起因，缺乏顶层计划，一开始没有势力巨子公用接口，实现这种接口要遭受庞大的负载，技能上有挑衅……

以是，早期很多技能题目，确实都是回收“线下共鸣”来办理的。好比早期不少电商的订单号，上面就承载了许多信息，纯真看订单号就可以辨认出下单日期、所属客栈、商品种类等等。

（编辑：湖南网）

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