WCF:限制每个用户每小时的调用次数

发布于 2024-08-29 04:31:31 字数 377 浏览 10 评论 0原文

我有一个 WCF 服务(basicHttpBinding、基本身份验证、IIS 6.0),我想限制每小时的调用次数 - 基于用户。例如,每个用户每小时最多 1000 次呼叫(如 Google 地图等)。

我还想实现某种订阅机制,以便用户可以在各种“价格计划”中升级其通话限额。

我知道我可以通过自定义 Inspector 来实现此目的,由包含某种“订阅”表和计数器的数据库,但我想避免重新发明轮子。

有人有这样做的经验吗?是否有第三方项目/库支持开箱即用?

谢谢。埃里克

I've got a WCF service (basicHttpBinding, basic authentication, IIS 6.0) on which I want to restrict the number of calls per hour - on user basis. For example, max 1000 calls per user, per hour (a la Google Maps, etc).

I also want to implement some sort of subscription mechanism, so that users can upgrade their call-limit across various 'price plans'.

I know that I could achieve this with a custom Inspector, backed by a DB containing some sort of 'subscription' table and a counter, but I'd like to avoid reinventing the wheel.

Does anyone have experience doing this? Are there 3rd party projects/libraries that support this out of the box?

Thanks. Eric

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

意中人 2024-09-05 04:31:31

我不知道是否有任何现成的软件包可以做到这一点(有人在听?可能是一个机会!),但以下是我对这个问题的快速想法:

  1. 您的要求是“在最后一小时内” “——让我们说“时间段”而不是小时,因为它可以很容易地改变。您必须跟踪该用户在该时间段内的所有呼叫,并采用某种机制来滚动或存档此数据。如果您存储在数据库中,这可能是一个重大的性能问题,具体取决于您的数据库、用户数量、每个时间段的调用次数等。设计一个通用接口非常容易,它可以让您如果您需要的话,可以在缓存中拼接 - 但您还需要跟踪检索 API/服务限制信息所花费的总时间。

  2. 如果可能,在服务级别对“有限功能”进行分区,而不是单个操作或方法。如果您可以将限制应用于整个服务的使用以及特定或单独的方法,那么一切都会变得更容易:代码、跟踪、用户的理解等。一般,即...

  3. 拦截和拦截的正确位置恕我直言,检查不在消息检查器中,而是在 OperationInvoker 中。通过服务范围的行为安装自定义操作调用程序,您将锁定整个服务。此外,您还可以访问消息后处理信息,例如经过身份验证的用户名等。请参阅 Skonnard 在 MSDN 上的文章“通过行为扩展 WCF" (http://msdn.microsoft.com/en-us/magazine/cc163302.aspx#S6)。

希望这有帮助。如果您决定自己做,请确保处理并发性(多个线程同时调用您的服务)!如果您有更多问题,人们了解您情况的基本参数可能会有所帮助,例如用户量、呼叫量、可扩展性问题(例如网络场或单个服务器?)。 ——基思

I don't know if there are any off-the-shelf packages to do this (anyone listening? could be an opportunity!), but here are my quick thoughts on the issue:

  1. Your requirement is "within the last hour" -- let's say "time period" instead of hour, since that can be changed easily. You'll have to keep track of all the calls by that user within the time period, as well as have some kind of mechanism to roll off or archive this data. If you're storing in a database, this can be a significant performance issue, depending on your database, the # of users, the number of calls made per time period, etc. It's pretty easy to design a generic interface that will let you splice in caching if you need it -- but you will also need to track the total time spent retrieving API/service limit info.

  2. Partition the "limited functionality" at the service level if possible -- not the individual operation or method. If you can make the limits apply to use of an entire service and to just specific or individual methods, everything will be easier: the code, the tracking, the user's understanding, etc. In general, that is...

  3. The proper place to intercept & check is not in a message inspector IMHO, but in the OperationInvoker. Install a custom operation invoker via a service-wide behavior, and you will lock down the entire service. In addition, you will have access to post-message-processing info, like the authenticated user name etc. See Skonnard's article on MSDN "Extending WCF via Behaviors" (http://msdn.microsoft.com/en-us/magazine/cc163302.aspx#S6).

Hope this is helpful. If you decide to do it yourself, make sure to handle concurrency (multiple threads calling into your service at the same time)! If you have more questions, it would probably be helpful for folks to know the basic parameters of your situation, like volume of users, calls, scalability concerns (e.g. web farm or single server?). -- Keith

婴鹅 2024-09-05 04:31:31

最简单的方法是将代码添加到您的服务中,它所做的第一件事是检查它是否已达到限制,然后更新计数器。

如果你从架构的角度来看,它就是你的业务逻辑,通常应该在业务层实现。

The simplest is to add code to your service, the first thing it does is to check if it has hit the limit, it then updates the counter.

If you look at it from an architecture point of view, it is your business logic and that should normally be implemented in the business layer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文