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

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

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

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

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

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

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

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

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

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

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

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

（编辑：西安站长网）

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