WCF-解决方案架构 [英] WCF - Solution Architecture

问题描述

你好，
我正在一个项目中，iOS应用程序将使用WCF服务.在任何给定时间点，Web服务器上预期的命中数约为900-1000.每个请求可能需要1-2秒才能完成.预期每隔24/7会发送相同数量的请求.

这是我的计划:

1.编写WCF RESTful服务(实例上下文模式为percall).
2.请求/响应将在Json中.
3.服务器中需要保留一些信息-该信息实际上是从另一个远程系统接收的-在所有请求之间共享.由于使用数据库可能不是一个好主意(响应时间非常重要-客户可以等待的最大时间为2秒)，因此最好将其保存在服务器内存中(例如静态字典-假设此字典将是一个数据库). 150000个对象的集合-每个对象由5-7个字符串类型及其键组成).我知道，这很不稳定！
4.每个请求都将产生一个新线程(通过使用Threading.Timers)进行清理-此线程还将执行一些数据库读/写操作.

现在，如果稍后某个时间引入了负载均衡器，则无法在通过另一个节点路由的请求之间共享内存中存储的对象-有什么想法吗?

我希望您的专家可以对整个体系结构，WCF节流，对象状态持久性等提出您的意见/建议，从而对我有所帮助.请在所需的硬件上也提供一些建议.我们计划使用Windows 2008 Enterprise Edition Server，IIS和SQL Server 2008 Std Edition数据库.

Hi there,
I am working on a project in which a WCF service will be consumed by iOS apps. The number of hits expected on the webserver at any given point in time is around 900-1000. Every request may take 1-2 seconds to complete. The same number of requests are expected on every second 24/7.

This is what my plan:

1. Write WCF RESTful service (the instance context mode will be percall).
2. Request/Response will be in Json.
3. There are some information that needs to be persisted in the server - this information is actually received from another remote system - which is shared among all the requests. Since using a database may not be a good idea (response time is very important - 2 seconds is the max the customer can wait), would it be good to keep it in server memory (say a static Dictionary - assume this dictionary will be a collection of 150000 objects - each object consists of 5-7 string types and their keys). I know, this is volatile!
4. Each request will spawn a new thread (by using Threading.Timers) to do some cleanup - this thread will do some database read/write as well.

Now, if there is a load balancer introduced sometime later, the in-memory stored objects cannot be shared between requests routed through another node - any ideas?

I hope you gurus could help me by throwing your comments/suggestions on the entire architecture, WCF throttling, object state persistence etc. Please provide some pointers on the required Hardware as well. We plan to use Windows 2008 Enterprise Edition server, IIS and SQL Server 2008 Std edition database.

Thanks in advance!

推荐答案

项目#4是失败的邀请.

对于高可用性服务，不可预知的线程数量是一个很大的禁忌.此外，您已经生成了一个单独的线程来进行清理，为什么还要使用计时器.就可靠性而言，计时器甚至比线程还差.您是否曾经尝试处理过由上一个事件触发的句柄仍在运行时触发计时器事件的情况?这是可解决的，但值得付出努力.

顺便说一句，如果您需要定期轮询数据库，则可以使用结合了计时器和线程的改进模式，其中计时器仅设置共享的EventWaitHandle.请查看我过去的解决方案:
使用计时器轮询数据库 [)使其保持睡眠状态，直到有任务为止.

这样，运行时的线程数不会更改.线程数是固定的，也可以由配置数据定义，并在最开始创建线程后保持固定.请记住，创建线程也非常昂贵.

基于此思想的另一种方法是用于线程间通信的阻塞队列.请参阅我的提示和技巧文章:用于线程通信和线程间调用的简单阻塞队列 [ ^ ].

—SA

The item #4 is an invitation for a failure.

For a high-availability service, unpredictable number of threads is a big no-no. Besides, you already spawn a separate thread for some clean-up, why also a timer. A timer is even worse than thread in terms of reliability. Did you ever try to handle the situations where a timer event if fired when a handle triggered by a previous event is still running? This is solvable, but hardly worth the effort.

By the way, if you need to poll a database periodically or something, I have an improved schema combining timer and thread, where the timer merely sets the shared EventWaitHandle. Please see my past solution:
Polling Database with Timer[^].

This post also illustrates perhaps the best approach to threads on a server: you create just on thread "per-purpose" in the very beginning of the run time and throttle it with some thread synchronization object (in this case, in instance of EventWaitHandle) to keep it sleeping until there is a task for it.

In this way, the number of threads during run-time is not changed. The number of threads is either fixed or defined by configuration data and is kept fixed after the threads are created in the very beginning. Remember that the creation of a thread is also pretty expensive.

Another approach based on this idea is the blocking queue used to inter-thread communicate. Please see my Tips & Tricks article: Simple Blocking Queue for Thread Communication and Inter-thread Invocation[^].

—SA

这篇关于WCF-解决方案架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！