An image to describe post 从软件设计角度看携号转网

“携号转网”的事情已经谈了很久很久了,但看看我们四周,真正成功办理了携号转网的人少之又少。即便办理成功,似乎也有这样那样的问题。

那么,到底有什么问题?

网上有不少文章,看起来云山雾罩,语焉不详,实在难以令人满意。身处IT行业,凡事都应该摆事实讲道理,能说得清楚。虽然我没做过移动网络和运营商的相关业务,但查查资料还是能得到不少信息。“携号转网”之所以难办,似乎不只是运营商偷懒,还有技术上的难点。如果从软件设计的角度来看看携号转网这回事,应当会有许多新的发现。

携号转网的问题其实在世界上普遍存在,它有个专门的名称叫Mobile Number Portability(MNP,移动号码迁移),其中主要涉及三个概念:原运营商(donor)、新运营商(recipient)、转网需求(number portability request,NPR)。对应的,它的技术方案也是现成的,主要有两种技术方案。

第一种是美国、欧洲以及国际通行的方案,叫recipient-led。用户在转网时,先向新运营商提出申请,然后新运营商会联系原运营商,经过数据校验之后完成资料转移,将原号码“调过来”。

第二种是英国和印度用的方案,叫donor-led。用户在转网时,先向原运营商提出申请,获得对应代码(英国叫PAC,porting authorisation code,印度叫UPC,unique porting code)之后转交给新运营商,新运营商据此完成转网。

第二种方案虽然看起来麻烦,但可以避免欺骗,因为原运营商有机会直接核实号码所有者的身份。但是,这也会导致不公平竞争,因为原运营商可能会借此机会故意拖延,想各种办法挽留用户。

An image to describe post 从软件设计角度看携号转网

完成了运营商迁移,还只是迁移了移动用户和运营商之间的关系,问题还没完。要知道,移动通讯不只是发生在运营商和用户之间,还发生在用户和用户之间。所以还要让呼入的电话(其他用户)知道,这个号码已经迁移到了新的运营商,这样呼入的电话、发来的短信才能正确抵达新运营商承载的用户。这种抵达的专业叫法是routing,也就是“路由”。

路由的实现方式同样不止一种。国际和欧洲通行的方案是集中式号码库CDB(Central Database)。简单说,它就像一张大表,详细记录了每个号码属于哪个运营商。相应的,每次发生携号转网,都必须在CDB中新增对应的记录。运营商会维护CDB的副本,在外呼电话或者外发短信时先查询它,然后直接联系对应号码的当前运营商。

根据RFC3482,这个查询叫ACQ(All Call Query)。合起来的整套方案就叫做ACQ/CDB routing,美国用的也是这套方案,只是美国的管理机构叫NPAC(Number Porting Administration Center)。

上面说的只是路由方式之一,英国的携号转网流程不同,路由方式同样独树一帜。英国没有采用ACQ/CDB,即便用户已经携号转网,呼入的电话或发来的短信仍然会首先抵达原运营商,原运营商再将它转发给新运营商,这就是“间接路由”(indirect routing),它类似Unix中的符号链接。

这种方案避免了对集中式号码库的依赖,将携号转网的信息分散给运营商各自维护,问题第一是增加了无谓传输,第二是已经转网的用户仍然无法摆脱对原运营商的依赖——所谓“打断骨头连着筋”,如果原运营商故障或者倒闭,已经转网的用户仍然会受影响,这样用户可能很难理解。

An image to describe post 从软件设计角度看携号转网

现在来说国内移动运营方案。按照目前国内运营商公布的携号转网流程,用户携号转网时,必须先向当前运营商咨询资格,并获得授权码,然后才能到新运营商处办理转入手续。据此可以猜测出,国内应当采用的是donor-led方案。不过,因为国内的手机号可能还有捆绑套餐,转网时需要进行复杂的业务确认。通过询问办理过携号转网的伙伴得知,这个“复杂的业务确认”过程,恰恰是原运营商极力挽留用户的过程。

好玩的是,虽然转网是donor-led方案,而且国内之前似乎是没有集中式数据库的。这个事情也不难理解,很长时间里似乎只有三大运营商,各运营商自成一体,工信部更多的是行使管理职能,而没有基础系统的建设和维护。

携号转网对任何一家运营商来说,似乎都是“得不偿失”的。如果用户要转出去,相当于自己流失了用户;如果用户要转进来(按照目前看到的报道,携号转网的用户比例极低),又要额外增加系统建设,其实相当不划算。所以看来看去,还是工信部牵头最合适,也最有可能。

按照我看到的技术文档,现在我国正在采用类似ACQ/CDB的方案来完成转网用户的路由。具体来说,工信部会维护统一的中心携号转网数据库(CNPDB),还有管理全国NP业务中心CSMS。联通、电信、移动三家会维护各自的LNPDB和LSMS,数据与CNPDB保持一致。

An image to describe post 从软件设计角度看携号转网

中国联通携号系统架构。来源:张伟强,杜忠岩,李嵩泉,肖禄《移动号码携带核心网部署方案探讨》

用户每次外呼时,运营商先查询自己的LNPDB,判断外呼号码对应的运营商(进行NP查询),然后将外呼信号做对应路由。整套技术方案看起来没有问题,但是之前并没有集中式的数据库,所以CNPDB的建设,以及整套流程的理顺都需要时间。

An image to describe post 从软件设计角度看携号转网

运营商呼叫流程。来源:张伟强,杜忠岩,李嵩泉,肖禄《移动号码携带核心网部署方案探讨》

那么目前,携号转网遇到的最大问题是什么呢?我觉得是短信的路由问题。这一点也被许多携号转网者的经历所证实——客服会告知,转网之后许多短信可能收不到了。为什么会这样呢?

目前大量的短信服务提供商判断用户所属的运营商时,完全是按照线下约定的规则。比如“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在某种意义上可以称为“分布式”方案,即必须通过原服务商来中转,这时候转网信息碎片其实是由运营商各自维护的。这种方案不需要花大力气建设中心节点,缺点则是职责不清晰,多了不必要的中转,已迁移用户仍然会受原运营商服务质量的影响。

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

An image to describe post 从软件设计角度看携号转网

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

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

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

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

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

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

不过现在,随着软件的复杂度越来越高,随时在线变得越来越普遍,这种“线下共识”已经越来越多地被替代了。不信你可以看看各大电商的订单号,早年还可以从中看出下单日期、当日序号等等,但是现在,已经基本看不出任何编号规律了。但是手机号处理起来很麻烦,手机号绑定的线下规则很多,不只有判断运营商,还有归属地……

总之,从携号转网这么个“简单直观”的事情中我们可以看到,软件设计要解决的问题原型往往简单,但这些问题往往牵连众多因素,而且没有放之四海而皆准的方案,不同的方案各有利弊,必须根据具体环境来取舍和抉择——许多时候,这恰恰是架构设计中最重要的因素,也是架构人才的核心竞争力。

P.S. 高春辉、胡姝琦对本文亦有贡献,在此表示感谢。

An image to describe post 从软件设计角度看携号转网

如果您认为本文说的有道理,欢迎长按识别上面二维码订阅。

“余晟以为”虽是个人号,但只用心做原创,不虚张声势,不故弄玄虚,不带节奏,力求定期更新,只为和你共同探索世界,分享致中平和的观点。