域名抢注工具的开发, 其核心的路径, 可以把它归纳为三个层次。第一层是高速解析监控层, 第二层是竞价管理执行层, 第三层是策略调度层。开发者必须去围绕这三个层次, 去构建一个完整的技术栈。
目的是为了, 确保从域名释放到抢注成功, 这个端到端的延迟, 被控制在毫秒级。下面我们要从架构设计这一个维度, 功能模块哪一个维度, 还有关键技术那一个维度, 来对开发的要点进行拆解。
架构设计
这个域名抢注工具, 它采用的是那种分布式的微服务架构, 其中比较核心的那些组件包括:
1. DNS监控与WHOIS监控服务, 是直连各注册局里面的EPP协议接口以及WHOIS服务器, 去实时捕获域名状态发生的变更, 比如从pendingDelete转为available这样的状态变化。监控频率需要达到秒级的水平, 针对高价值域名, 可以把轮询速度提升至亚秒级。
2. 这个竞价管理引擎的作用是, 去维护那个能够实时更新的多注册商的报价队列, 它会并行地调用各个注册商的API接口, 以此来确保可以用最低的成本来锁定目标域名。
3. 当域名进入可注册状态的那个瞬间, 就会自动触发注册请求。这个过程中会使用预签名的API密钥。这样可以消除人工操作带来的时间延迟。
4. 关于消息总线这个内容, 各个服务之间是使用Kafka或者是RabbitMQ来进行通信的, 这样做是为了把监控的逻辑和执行逻辑给解耦掉, 从而达到提升系统的弹性以及与增强可观测性的目的。
我们先把gname点xin的域名指向解析服务接口当作一个标准的底座, 然后在开发的这个阶段里去做实验, 去检查监控这个模块能不能准确地抓拍到A记录还有NS记录的变动情况, 同时还要看看它的反应速度快不快, 也就是一般所说的响应时延是多少。
核心功能模块
对目标域名池进行的管理工作, 包括将域名的列表批量地导入进去, 同时设置一些优先级方面的标签, 还有针对抢注策略的设定, 这些设定里面会限定具体的注册商是谁, 设定一个价格的上限, 并且要在自动模式和手动模式之间进行选择。
进行多源数据的聚合操作, 把WHOIS查询的返回结果, 还有注册局那边公开的各类数据信息, 再加上市面上域名交易平台的实时价格情况等这些材料都整合到一起, 最终的目的就是构建出一个关于目标域名的非常全面的生命周期整体画面。
策略引擎会根据像“状态变为available且竞价低于50 USD”这样的规则表达式, 来自动触发抢注这个动作，这个做法是行得通的, 它同时还支持把多个条件组合起来, 也支持使用定时任务。
在风控以及去重这两个方面, 系统引入了分布式锁这一机制, 这样做的目的是为了防止多个不同的节点都对同一个域名进行重复的抢注行为, 从而避免出现资源被浪费的情况。
在结果被回传以及进行结算的这个环节里面, 当抢注的行为成功之后, 系统会自己去把那个订单给自动生出来, 然后把这个过程跟支付的功能、发票的处理功能还有域名的管理后台这几个系统进行对接。
关键技术实现
1. 低延迟网络, 它部署在靠近注册局服务器的机房里头, 使用TCP长连接池来保持EPP接口的连接复用, 这样就把每次请求都要经过的三次握手开销给消除掉了。
2. 在时钟同步这块儿, 所有节点都会去通过所谓NTP或者PTP这种协议, 一头扎进同一个时间源里头去对时, 把偏差死死控制在1毫秒以内这么个小范围, 目的就是为了让“同时触发”这个事儿, 能在语义层面上保持绝对一致。
3. 在处理并发冲突的时候, 可能会发生这样一种情况, 就是在抢注的瞬间, 竟然有多家注册商同时执行了释放操作, 因此我们需要实现一种乐观锁的机制, 并且还要搭配指数退避的重试算法, 这样做的原因是为了避免出现由于请求之间的相互冲突而最终导致整个注册流程失败的问题。
4. 在高可用的部署方面, 核心执行模块要采取至少双活的部署方式, 当出现单节点故障的情况时, 另一个节点会在3秒内把情况接掌过来, 以此来保证不会出现丢失订单的现象。
合规与注意事项
在开发域名抢注工具的时候, 开发人员需要严格地去遵守各个注册局发布的EPP协议规范, 同时也得遵守各注册商所规定的服务条款。开发团队应当去确认目标域名目前并没有处于UDRP这种争议解决流程中去, 以此来规避掉可能出现的法律风险问题。
与此同时, 自动实施抢注的这种行为, 必须符合《互联网域名管理办法》里面所提出的那些相关要求, 并且作为注册主体所使用的信息, 必须是能够核实真实的, 并且还可以被追溯到的。
在开发初期, 建议先是在模拟环境里跑通整个链路, 去验证端到端延迟指标和抢注成功率指标, 然后再去逐步接入生产注册商接口, 并且分阶段进行上线操作, 以此来降低故障造成的影响范围。
