摘要:在使用的时候,发现文档中的一些功能并不能满足构建测试服务的需求,需要自己开发一些功能。使用场景的话小游戏的里面的抽奖,订单提交,耗时较长的功能等。在实际的业务逻辑中,很可能会有短时间内不允许提交多次,请求多次的需求。
在使用moco API的时候,发现文档中的一些功能并不能满足构建测试服务的需求,需要自己开发一些功能。之前两篇主要讲了moco本身的补充,本篇说说moco文档之外的功能:limit。
主要是用于限制访问次数,并不针对某个session或者同一个用户(本人暂时没有这方面的需求,故没有开发)。
使用场景的话:小游戏的里面的抽奖,订单提交,耗时较长的功能等。在实际的业务逻辑中,很可能会有短时间内不允许提交多次,请求多次的需求。
下面上代码:
package com.fun.moco.support; import com.fun.utils.Time; import com.github.dreamhead.moco.HttpRequest; import com.github.dreamhead.moco.MocoConfig; import com.github.dreamhead.moco.ResponseHandler; import com.github.dreamhead.moco.handler.AbstractResponseHandler; import com.github.dreamhead.moco.internal.SessionContext; import com.github.dreamhead.moco.model.MessageContent; import com.google.common.base.Function; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; /** * 循环的responsehandle */ @SuppressWarnings("all") public class LimitHandle extends AbstractResponseHandler { private final ResponseHandler limit; private final ResponseHandler unlimit; private Maptatal = new ConcurrentHashMap<>(); private int interval; private LimitHandle(final ResponseHandler limit, final ResponseHandler unLimit, int interval) { this.limit = limit; this.unlimit = unLimit; this.interval = interval; } public static ResponseHandler newSeq(final ResponseHandler limit, final ResponseHandler unLimit, int interval) { return new LimitHandle(limit, unLimit, interval); } /** * 返回响应 * * @param context */ @Override public void writeToResponse(final SessionContext context) { HttpRequest request = (HttpRequest) context.getRequest(); String uri = request.getUri(); MessageContent content = request.getContent(); (limited(uri + content) ? limit : unlimit).writeToResponse(context); } @Override public ResponseHandler apply(final MocoConfig config) { if (config.isFor(MocoConfig.RESPONSE_ID)) { return super.apply(config); } return new LimitHandle(limit, unlimit, interval); } private Function applyConfig(final MocoConfig config) { return new Function () { @Override public ResponseHandler apply(final ResponseHandler input) { return input.apply(config); } }; } /** * 判断是否被限制 * * 通过记录每一次响应的时间戳,判断两次请求间隔达到limit目的 *
* * @param info * @return */ public boolean limited(String info) { long fresh = Time.getTimeStamp(); long old = tatal.containsKey(info) ? tatal.get(info) : 0L; tatal.put(info, fresh); return fresh - old > interval; } }
使用方法如下:
/** * 限制请求频次,默认1000ms * @param limit * @param unlimit * @return */ static ResponseHandler limit(String limited, String unlimited) { limit contentResponse(limited), contentResponse(unlimited) } static ResponseHandler limit(JSONObject limited, JSONObject unlimited) { limit jsonResponse(limited), jsonResponse(unlimited) } static ResponseHandler limit(ResponseHandler limited, ResponseHandler unlimited) { limit limited, unlimited, 1000 } /** * 限制请求频次 * @param limit * @param unlimit * @param interval 单位ms * @return */ static ResponseHandler limit(String limited, String unlimited, int interval) { limit contentResponse(limited), contentResponse(unlimited), interval } static ResponseHandler limit(JSONObject limited, JSONObject unlimited, int interval) { limit limited.toString(), unlimited.toString(), interval } static ResponseHandler limit(ResponseHandler limit, ResponseHandler unlimit, int interval) { LimitHandle.newSeq(limit, unlimit, interval) }
groovy是一种基于JVM的动态语言,我觉得最大的优势有两点,第一:于java兼容性非常好,大部分时候吧groovy的文件后缀改成java直接可以用,反之亦然。java的绝大部分库,groovy都是可以直接拿来就用的。这还带来了另外一个有点,学习成本低,非常低,直接上手没问题,可以慢慢学习groovy不同于Java的语法;第二:编译器支持变得更好,现在用的intellij的ide,总体来说已经比较好的支持groovy语言了,写起代码来也是比较顺滑了,各种基于groovy的框架工具也比较溜,特别是Gradle构建工具,比Maven爽很多。----此段文字为了撑字数强加的,与内容无关。
欢迎有兴趣的童鞋一起交流
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/75420.html
摘要:在使用做接口虚拟化的过程中遇到一个比较棘手的问题,就是根据官方文档提供的案例,并不能跑通请求在处理传参格式的虚拟化。的绝大部分库,都是可以直接拿来就用的。此段文字为了撑字数强加的,与内容无关。欢迎有兴趣的童鞋一起交流 在使用moco API做接口虚拟化的过程中遇到一个比较棘手的问题,就是根据官方文档提供的案例,并不能跑通post请求在处理json传参格式的虚拟化。经过查询源码,发现了一...
摘要:我在使用框架过程中,遇到一个问题,在官方文档中给出了的方法,表示循环返回一个数组里面的,但是在查看的时候并没有发现这个方法,所以觉得自己写了一个,并且重写了方法。方法主要用在请求次数相关的内容,比如订单提交资源删除等场景。 我在使用moco框架过程中,遇到一个问题,在官方文档中给出了cycle的方法,表示循环返回一个数组里面的response,但是在查看API的时候并没有发现这个cyc...
摘要:虽然前后端分离已经流行很多年了,仍有很多团队不能够充分的利用前后端分离的优势。主要体现在前端过分依赖服务环境将高效的约定分工合作模式理解很浅。在这里推荐一种的解决方案。不支持简洁的文件格式不符合的标准。所以使用集成,参考前后端分离方案整合 虽然前后端分离已经流行很多年了,仍有很多团队不能够充分的利用前后端分离的优势。主要体现在前端过分依赖服务环境, 将高效的约定分工合作模式理解很浅。 ...
摘要:虽然前后端分离已经流行很多年了,仍有很多团队不能够充分的利用前后端分离的优势。主要体现在前端过分依赖服务环境将高效的约定分工合作模式理解很浅。在这里推荐一种的解决方案。不支持简洁的文件格式不符合的标准。所以使用集成,参考前后端分离方案整合 虽然前后端分离已经流行很多年了,仍有很多团队不能够充分的利用前后端分离的优势。主要体现在前端过分依赖服务环境, 将高效的约定分工合作模式理解很浅。 ...
摘要:事件风暴事件风暴就是把所有的关键参与者都召集到一个很宽敞的屋子里来开会,并且使用便利贴来描述系统中发生的事情。一张桔黄色的便利贴代表一个领域事件,在上面用一句过去时的话描述曾经发生过什么事情,格式一般是已。 一周前,参加了公司的一个架构设计与建模的工作坊——『事件风暴』。从某种意义上来说,这是一个关于架构设计与软件建模的工作坊。于是便闪现了一个灵感,便有了 Stepping.js。 当...
阅读 2374·2021-09-01 10:41
阅读 1402·2019-08-30 14:12
阅读 459·2019-08-29 12:32
阅读 2813·2019-08-29 12:25
阅读 2903·2019-08-28 18:30
阅读 1666·2019-08-26 11:47
阅读 916·2019-08-26 10:35
阅读 2550·2019-08-23 18:06