主要缺点是您无法轻松调试此接口（对于大多数 Internet 协议，您只需 telnet 到服务器侦听的端口并运行几个命令并查看结果）。 此外，如果您因任何原因必须更改界面，则还必须更改每个客户端。 当您需要在其他地方使用此服务时，例如在 mashup。
所以如果你想更灵活，可以使用像HTTP和JSON这样的协议作为数据格式。 这不像二进制那么紧凑，因此回答时间会更糟。 糟糕程度取决于数据的大小。 如果您可以将 JSON 编码的响应放入标准 IP 包（大约 1500 字节）中，您可能不会注意到其中的差异。
A daemon will be faster in the short term at the price of flexibility. The advantage of the daemon is that you can just send the reply back in a compact form, in your case as a stream of binary integer values. This will be as fast as you can get.
If the number of requests increases beyond a certain limit, you can use DNS with Round Robin to spread the load over several machines, so there is no advantage of using a HTTP server.
The main drawback is that you can't debug this interface easily (with most Internet protocols, you can just telnet to the port on which the server listens and run a couple of commands and see the result). Also, if you have to change the interface for any reason, you will have to change every client as well. This gets worse when you need to use this service somewhere else, for example in a mashup.
So if you want to be more flexible, use a protocol like HTTP and JSON as the data format. This is not as compact as the binary, so answer times will be worse. How much worse depends on the size of the data. If you can fit the JSON encoded response into a standard IP package (about 1500 bytes), you probably won't notice the difference.
If you develop a daemon server, what interface you are providing clients to connect? You would be implementing sockets or RMI or something else. Not a very flexible and easy to maintain solution when it comes to scalability.
您没有提及服务器正在使用什么技术。 如果是Java那就没问题了。 如果不是的话，它会变得更有趣。 如果是这种情况，您可能需要考虑使用 Google Protocol Buffers 构建一些内容，这是一种高性能二进制交换格式，并受 Java、C++ 和可能的其他平台支持。
就我个人而言，我并不是 Web 服务的忠实粉丝，因为它们不是事务性的（从某种意义上说，它们无法注册分布式事务）。 这对您来说可能是问题，也可能不是问题。 另外，不同技术堆栈（例如Java 和.Net）之间的互操作性充其量仍然是个问题。
If performance is that much of an issue I suspect you well need to go for some kind of grid of cluster solution. I wrote an overview of Java grid/cluster libraries awhile back that is useful background.
If commercial software is an option I'd suggest looking at GigaSpaces (or some freeware JavaSpaces implementation if not). It'll allow you to do:
FIFO ordering of messages, if that's important to you (although that comes with a performance cost);
Sub-millisecond transactional grid updates;
It comes with a JMS implementation built on top if you want to use that queueing API; and
Messages are defined by class so you can just read/write the appropriate operations.
GigaSpaces (and any serious grid/clustering technology really) scales well. Much better than a pure queueing solution, which either doesn't scale with publish-subscribe (since all listeners receive a message; not typically what you want) or request-response (where you have to make sure the queue isn't blocked by a bad message).
You don't mention what technology the server is using. If it's Java then you're OK. If not it gets a little more interesting. If that is the case you may want to consider building something using Google Protocol Buffers, which is a high-performance binary interchange format and is supported on Java, C++ and possibly other platforms.
Personally I'm not a huge fan of Web services because they're not transactional (in the sense that they can't enrol in distributed transactions). That may or may not be an issue for you. Plus interoperability between different technology stacks (eg Java and .Net) is still problematic at best.
unless you have tried multiple methods, you wont know which one is "better". The best way is to prototype each, and try it! it doesnt even have to do all you want to do, just do the basic bits (like returning predefined data), and you can load test it to see which one is better.
i suspect that these days, modern machines will perform fast enough for http to work reasonably well, and with the added benefit of being more standardized, other services can take advantage of your server without needing a specialized client.
发布评论
评论（6）
守护进程在短期内会更快，但代价是灵活性。 该守护程序的优点是您可以以紧凑的形式发送回复，在您的情况下作为二进制整数值流。 这将是您能达到的最快速度。
如果请求数量增加超过一定限制，您可以使用DNS with Round Robin进行传播多台机器上的负载，因此使用 HTTP 服务器没有任何优势。
主要缺点是您无法轻松调试此接口（对于大多数 Internet 协议，您只需 telnet 到服务器侦听的端口并运行几个命令并查看结果）。 此外，如果您因任何原因必须更改界面，则还必须更改每个客户端。 当您需要在其他地方使用此服务时，例如在 mashup。
所以如果你想更灵活，可以使用像HTTP和JSON这样的协议作为数据格式。 这不像二进制那么紧凑，因此回答时间会更糟。 糟糕程度取决于数据的大小。 如果您可以将 JSON 编码的响应放入标准 IP 包（大约 1500 字节）中，您可能不会注意到其中的差异。
A daemon will be faster in the short term at the price of flexibility. The advantage of the daemon is that you can just send the reply back in a compact form, in your case as a stream of binary integer values. This will be as fast as you can get.
If the number of requests increases beyond a certain limit, you can use DNS with Round Robin to spread the load over several machines, so there is no advantage of using a HTTP server.
The main drawback is that you can't debug this interface easily (with most Internet protocols, you can just telnet to the port on which the server listens and run a couple of commands and see the result). Also, if you have to change the interface for any reason, you will have to change every client as well. This gets worse when you need to use this service somewhere else, for example in a mashup.
So if you want to be more flexible, use a protocol like HTTP and JSON as the data format. This is not as compact as the binary, so answer times will be worse. How much worse depends on the size of the data. If you can fit the JSON encoded response into a standard IP package (about 1500 bytes), you probably won't notice the difference.
我知道这是一个一般性的答案，但你说的是守护进程和网络服务之间的毫秒差异。
话虽如此，请选择更灵活的架构。 好的设计将远远超过你用来执行它的技术。
如果几毫秒真的很重要，那么问题不在于使用哪种技术，而在于如何使用缓存和负载平衡来扩展它。
I know this is kind of a general answer, but you're talking a difference of milliseconds between a daemon and a web service.
With that said, go with the more flexible architecture. Good design will FAR outweigh the technology you use to execute it.
If a couple milliseconds really counts, then the question is not which technology to use but how you can use caching and load balancing to scale it.
如果您开发守护程序服务器，您为客户端提供什么连接接口？ 您将实现套接字或 RMI 或其他东西。 就可扩展性而言，这不是一个非常灵活且易于维护的解决方案。
使用网络服务。
If you develop a daemon server, what interface you are providing clients to connect? You would be implementing sockets or RMI or something else. Not a very flexible and easy to maintain solution when it comes to scalability.
Go with webservice.
您可以跟随领导者和用户 HTTP :)
例如在他们的 AJAX API 中，他们将其与 JSON 结合使用（或者是纯 JavaScript ？）
这里是一个例子。
对于以下查询：
完整的输出是这样的：
当然测试非常简单，但是使用 java 实现再简单不过了。
当然，这取决于您的项目需求、安全性、访问控制等，但通过使用 HTTP，您可以中继经过超级测试的协议。
You could follow the leader and user HTTP for that :)
For instance in their AJAX API, they use it in conjunction with JSON ( or is it plain javascript ? )
Here is an example.
For the following query:
The complete output is this:
Of course the test is very simple, but using java the implementation could not be simpler that that.
Of course it depends on your project needs, security, access control etc, but by using HTTP you can relay on a super tested protocol.
如果性能是一个很大的问题，我怀疑您很需要寻求某种集群网格解决方案。 我写了一个 Java 网格/集群库概述 不久前这是有用的背景。
如果可以选择商业软件，我建议查看 GigaSpaces（如果没有，则查看一些免费软件 JavaSpaces 实现）。 它将允许您执行以下操作：
GigaSpaces（以及任何真正的网格/集群技术）可以很好地扩展。 比纯粹的排队解决方案好得多，后者不能通过发布-订阅（因为所有侦听器都会收到消息；通常不是您想要的）或请求-响应（您必须确保队列不会被阻塞）进行扩展。一条坏消息）。
您没有提及服务器正在使用什么技术。 如果是Java那就没问题了。 如果不是的话，它会变得更有趣。 如果是这种情况，您可能需要考虑使用 Google Protocol Buffers 构建一些内容，这是一种高性能二进制交换格式，并受 Java、C++ 和可能的其他平台支持。
就我个人而言，我并不是 Web 服务的忠实粉丝，因为它们不是事务性的（从某种意义上说，它们无法注册分布式事务）。 这对您来说可能是问题，也可能不是问题。 另外，不同技术堆栈（例如Java 和.Net）之间的互操作性充其量仍然是个问题。
If performance is that much of an issue I suspect you well need to go for some kind of grid of cluster solution. I wrote an overview of Java grid/cluster libraries awhile back that is useful background.
If commercial software is an option I'd suggest looking at GigaSpaces (or some freeware JavaSpaces implementation if not). It'll allow you to do:
GigaSpaces (and any serious grid/clustering technology really) scales well. Much better than a pure queueing solution, which either doesn't scale with publish-subscribe (since all listeners receive a message; not typically what you want) or request-response (where you have to make sure the queue isn't blocked by a bad message).
You don't mention what technology the server is using. If it's Java then you're OK. If not it gets a little more interesting. If that is the case you may want to consider building something using Google Protocol Buffers, which is a high-performance binary interchange format and is supported on Java, C++ and possibly other platforms.
Personally I'm not a huge fan of Web services because they're not transactional (in the sense that they can't enrol in distributed transactions). That may or may not be an issue for you. Plus interoperability between different technology stacks (eg Java and .Net) is still problematic at best.
除非您尝试过多种方法，否则您不会知道哪一种“更好”。 最好的方法是对每个原型进行原型设计，然后尝试一下！ 它甚至不必做您想做的所有事情，只需执行基本操作（例如返回预定义的数据），您就可以对其进行负载测试以查看哪一个更好。
我怀疑如今，现代机器的运行速度足以让 http 正常工作，而且由于更加标准化，其他服务可以利用您的服务器而无需专门的客户端。
unless you have tried multiple methods, you wont know which one is "better". The best way is to prototype each, and try it! it doesnt even have to do all you want to do, just do the basic bits (like returning predefined data), and you can load test it to see which one is better.
i suspect that these days, modern machines will perform fast enough for http to work reasonably well, and with the added benefit of being more standardized, other services can take advantage of your server without needing a specialized client.