面向系统内部的访问频率限制服务模型.docxVIP

面向系统内部的访问频率限制服务模型 一、 业务维护及管理问题 对于大型开放应用程序，现有服务接口经常被外部调用。在不添加访问频率的控制策略上，这些接口可能会被过度调用。给系统带来额外的负担。 过度调用,会导致两方面的后果:接口调用者通过对服务接口的多次调用间接获取系统安全信息,对系统造成隐患,常见的有:短时间内对登陆服务接口,通过枚举组合,破解用户系统密码。另一方面,因为用户个体数量庞大,单个用户对接口大量的调用,会影响其他用户的服务质量,降低系统的有效负荷。 用户访问数达到一定量级的系统平台均会遇到上述问题,并各自都有相应的解决方法。但现成的方法是,把访问限制功能作为独立的模块,系统内部需要使用此功能的业务,就把该模块的拷贝纳入作为业务的子模块。这种系统组织方式既不利于维护,也不利于管理。而且访问约束所适用的类型往往是固定的,不易于扩展。用户访问数据的存储方面,已有的方式主要分两种:客户端记录,或在服务端用数据库存储。前者的访问数据可能被篡改,有安全隐患;作为一种基础功能模块,后者的做法代价较为昂贵,可能会占用大量的数据库连接,降低业务处理能力。 针对上述问题,本文提出一种轻型的访问频率限制服务模型(Access Frequency Restrict Service Model,AFRSM)。此模型本身是一种面向平台内部的私有服务接口。系统边界以内的一切需要进行访问频率限制的模块和对外服务接口均可通过简单的协议共同使用此服务(Frequency Restrict Service,FRS)。最终达到统一管理和使用访问频率限制服务的目的。 二、 fysm总结 2.1 mmap文件群 频率限制服务(Frequency Restrict Service,FRS)作为CGI、Web-Service等公共服务接口的依赖服务,自身对性能有较高的要求。在设计模型时我们偏重其并发处理能力以及轻型的数据存储。 图1是本文提出的频率限制服务模型的简要架构,它由三大块组成:微服务器框架、MMAP文件群以及一组配置文件。其中服务器我们采用了并发度较高的epoll模型,除守护进程外还可配置n个子进程进一步增加其并发性能。服务只处理两种类型的请求:Query和Update,分别对应FRS的查询接口和更新接口。公共服务(记为PS)通过FRS的查询接口可以获知:当前用户/当前IP是否仍对于该服务(PS)有使用权,如有权使用则表示该用户在服务(PS)中没有被限制;反之,则表示该用户在服务(PS)中已被约束。 在FRS的核心处理模块中,包含了一些核心算法,用以访问和更新MMAP文件群。 Config-Cache是FRS的重要组成部分之一,在守护进程启动时,指定配置文件内容机会被缓存在中,之后每次访问配置文件实际上都会在内存中命中需获取的配置项。配置文件在此分两种类型:(1)服务器相关的配置(srv.xml),用于指定服务器的子进程数,所绑定的主机端口等;(2)业务配置(map.xml),用于注册各个业务的频率限制细则:业务标识、时间间隔、间隔内最大访问次数。 2.2 应用层协议的构建 FRS采用TCP协议,并在此基础之上构建应用层协议。由于FRS是内部服务,不对外公开,因此不存在数据包的保密问题;同时FRS属于轻型服务,在一次服务请求过程中不会传输过多数据,因此不需要考虑数据包压缩的问题。应用层协议的构建原则是:简单并易于扩展。 HTTP-XML协议是我们所采用的应用层协议。即,使用HTTP头描述数据包体的长度、请求命令类型等信息。具体请求/响应数据则采用XML协议描述,以便在此基础上进行扩展修改。 图2是一个请求协议包的模板样例。其中cmd_type={“query”,”update”};Key是调用业务的主体标识(用户ID,IP等);而Biz_id则是在FRS中注册的业务标识。 图3为响应协议包的模板样例,其中result标示查询或更新后的结果: (1)Result query={0:”无约束”,1:”已约束”} 由于返回字段Msg中可能包含中文字符,因此响应协议包使用UTF-8编码。 2.3 frs的使用模式 FRS作为一种内部服务,其使用者是位于系统最外层的CGI、Web-Service、其他Server等公开服务接口。通用的HTTP-XML协议使得其它服务的逻辑中可以很方便实现对FRS的调用。 FRS的客户端使用模式相对固定,主要分=两个步骤:a.Query,b.Update,如图4所示: 当且仅当key在服务(BizID)中没有被约束,调用者key才能继续使用该业务,并在使用完毕后,必须更新记录key对这次业务的使用情况。 由于从步骤(02)开始需要依赖步骤(01)的结果,步骤(01)必须使用同步模式请求FRS。如该业务采用异步I/O模型的可能在此