短网址服务的设计及实现的所有关键特性

01 摘要


本文主要介绍了短网址营销方向,对外对内传播短链接,短网址的最优配置,不同短网址数据库之间的快速读写操作——短网址通用发放平台的设计及实现,以方便使用和接入,降低开发成本,集中管理。


02. 背景


随着短网址和其他第三方联合运营的不断推广和合作,短网址服务对内对外的合作发放虚拟or实物物品的需求越来越强烈:比如合作发短网址外链、短网址优化过的二维码等,或者外卖发糯米代金券、爱奇艺vip码等。在发放的基础之上又融合了各种发放的策略,而种类多样的策略设计每次都需要重新设计和开发。除此以外,查询和统计等需求并没有可靠方便的机制进行保证,无疑又增加了开发的工作量。


为了更好的服务联合运营需求,降低各业务方接入各类发放通道的开发和工作量,通用发放系统的需求也就应运而生:建立一个功能完善、易扩展、方便接入和使用的通用发放平台,服务于整个短网址服务的对内对外的各类发放需求。


03. 系统设计

整体系统流程架构图如下:


短网址服务的设计及实现的所有关键特性 短网址资讯 第1张


整个系统主要包括四层,接入层,策略层,服务层,数据层

? 接入层:主要对接入方的访问做权限校验,对请求频次做流量控制。

? 策略层:主要是做一些策略抉择,如发放类型,组合发放控制。

服务层:下游服务,对接内部和外部基础服务,如代金券发放,余额发放等。

数据层:将整个调用过程使用消息队列,异步记录日志,方便做问题追踪和实时监测。


3.1 权限设计

3.1.1 授权


内部授权平台设计两种权限:创建者和管理员的权限。


一、创建者可以由短网址服务内部程序进行创建,但没有审批授权上线的权限,创建后需通知给管理员进行审批。创建者在非上线状态可以进行编辑,上线后则不可编辑。创建者可以下线自己的授权活动。


二、管理员可以直接创建授权并审核生成的短链接是否可以上线,同时也可以进行下线操作

整个授权过程无需研发再次介入,可由管理人员在界面直接操作,进行整体控制;同时设计测试的联调活动用于外界联调测试。

授权主要分为对外业务授权和对内授权,对外授权需要生成通用des加密的对应token。授权信息保存在redis中,降低检验耗时,同时在db中冗余一份。


短网址服务的设计及实现的所有关键特性 短网址资讯 第2张


3.1.2 策略配置


目前接入了多个业务方向的代金券,后期可接入组合发放等其他需求。


3.1.2 活动创建原型图


活动状态流转图:


短网址服务的设计及实现的所有关键特性 短网址资讯 第3张


详细功能点说明:

1.普通创建人只能看到自己创建的活动和状态,看不到别人创建的活动;管理员则可以看到所有生成的短链接。

2.活动保存后可以编辑的信息:基本信息中的活动名称,结束时间;策略的编辑只能由管理员进行,如增删批次id,授权新的api等。

3.活动授权上线后只能由管理员进行批次的添加和修改;授权前可以由创建人自由修改。

4.活动下线后,可重新编辑后进行保存,并由管理员再次审核上线。

5.策略信息中点击批次id可以跳转至批次信息详情页面。


3.2 系统稳定性

3.2.1 流量控制


短网址服务的设计及实现的所有关键特性 短网址资讯 第4张


流量控制,使用脚本定时监控接口调用qps,平衡各接入方的接口qps,检测到qps到了预警值,根据各接入方的最高允许qps,按比例设定当前时间各个接入方的调用qps来进行调控,保证整体qps在预警值之下,保证系统的正常访问。

3.2.2 短网址服务隔离设计


最理想的服务隔离设计,是在包括域名、集群、数据库、缓存等进行完全的隔离,保证服务的稳定性,降低与其他服务的依赖,具体设计如下:


1.申请独立域名和独立部署模块,包括机器集群,数据库,缓存等等。

2.qps总压力限制分内外部设计,内部调用方优先级高于外部调用方。

3.接入压力实时反馈,流控算法进行防御式限流。

4.内外接入方的统计信息消息进行隔离,消息队列拆分单独维护,异步统计。


3.3 可视化数据平台和监控


3.3.1 短网址数据查询



目的:效果的分析,问题的追查,流量的监控等

短网址服务的设计及实现的所有关键特性 短网址资讯 第5张


3.3.2 实时调用可视化


在可视化平台,可以查看各个接入端的调用情况,做到实时监控,目前只做到监控各端调用频次,后期可以接入调用响应的字段统计,超时等等性能数据。


短网址服务的设计及实现的所有关键特性 短网址资讯 第6张


图为测试环境模拟实时调用效果图,如图为三个调用方同时调用短网址服务,第一个交叉点检测到流量超过预制,脚本自动干预调控流量保证整体流量可控;第二交叉点检测到流量下降,恢复各接入方调用。


3.4 通发重入的考虑


接口重入考虑,短网址服务大部分接口是写入性接口,在一些重要业务场景如余额,高额代金券的发放必须要考虑到接口重入性,防止多发。由于通发平台,不做具体业务,重入的保证很大程度依赖业务下游来保证;通发平台再次基础上再次做了优化:


1. 第一次调用在下游上锁之后,把锁同步到通发平台,锁采用单线程模式的redis来实现。

2. 再次调用时验证锁的存在,这样在调用下游之前能够截住很大一部分不必要调用下游的重入流量,解决重入的同时,较低了对下游的压力。


发表评论:

Copyright ft12.com All Rights Reserved.