RESTful Web 服务与数据密集型应用程序的套接字编程 [英] RESTful web services vs Socket Programming for a Data Intensive Application

问题描述

我正在使用 Ruby on Rails 构建一个需要高度可扩展的 Web 应用程序.在此应用程序中，移动客户端每秒生成数据(大约 20 个字节).所有这些数据必须在某个时候传输到服务器，最好是尽快.

I'm building a web application with Ruby on Rails which needs to be highly scalable. In this application, data is produced by a mobile client (approximately 20 bytes) every second. All of this data must be transferred to a server at some point, preferably as soon as possible.

为了完成这项任务，我希望服务器充当 RESTful 服务.客户端可以缓冲位置(比如每 5 到 30 秒)，然后将它们作为 HTTP 放置请求发送出去，然后服务器可以将它们存储在那里.我相信这个模型更容易实现，并且可以更好地处理大量流量，因为客户端可以一直缓冲数据，直到他们听到来自服务器的响应.

To accomplish this task, I want the server to act as a RESTful service. The client could buffer locations (say every 5 to 30 seconds) and then shoot them off as a HTTP put request, where the server could then store them. I believe this model is simpler to implement, and better handles high volume traffic, as the clients could keep buffering data until they hear a response from the server.

另一方面，我的老板想要使用套接字编程来实现服务器.他认为套接字编程将导致传输的数据更少，这将提高系统的总效率.在这一点上我不能不同意，但我认为考虑到现代带宽，HTTP 的额外开销是值得的.另外，我认为试图与用户保持数千(或数百万)个同时连接会导致其自身的问题并大大增加服务器的复杂性.

My boss, on the other hand, wants to implement the server using socket programming. He believes socket programming will result in less data being transferred, which will increase the total efficiency of the system. I can't disagree on this point, but I think given modern bandwidth the extra overhead with HTTP is worth it. Plus, I think trying to maintain thousands (or millions) of simultaneous connects with users will cause its own problems and greatly increase the complexity of the server.

老实说，我不知道解决这个问题的正确方法，所以我想我会在这里发布它并听取比我更聪明的人的意见.如果任何答案包括所提议解决方案的利弊，我将不胜感激.

Honestly, I don't know the right approach to this problem, so I thought I'd post it here and get the opinions of much smarter people than myself. I'd appreciate it if any answers included the pros and cons of the proposed solution.

谢谢.

更新

我们现在有一些额外的要求.首先，移动客户端每月上传的数据量不能超过 5 GB.在这种情况下，我们每个月每天八小时，每秒谈论一条消息.其次是我们希望尽可能少地组合消息.这是为了确保如果移动客户端出现问题(比如车祸)，我们会尽可能少地丢失数据.

We now have a few additional requirements flushed out. First, the mobile client cannot upload more than 5 GB of data per month. In this case, we're talking one message a second for eight hours a day per month. Second is we want's to combine messages as little as possible. This is to ensure if something happens to the mobile client (say a car crash), we lose as little data as possible.

推荐答案

你的老板似乎过早地优化，这不是一个好主意.

Your boss appears to be optimizing prematurely, which is not really a good idea.

与其在开始编写代码之前就试图与想象中的性能怪物作斗争，不如检查应用程序的需求并针对它们进行设计.不要让感知问题驱动您的设计.

Instead of trying to fight an imaginary performance bogeyman before you've even started writing your code, you should examine your application's requirements and design to them. Don't let perceived problems drive your design.

如果涉及到它，请让您的老板准确地概述他如何通过套接字连接封送数据，然后进行一些快速计算，看看您是否可以使用 HTTP 匹配或击败它们.他会使用 Google 的 Protocol Buffers 之类的东西，还是编写自己的封送协议?如果是这样，它会自我描述吗?像您在 HTTP 中免费获得的应用程序动词"怎么样?他的关系会持久吗?套接字"不仅仅是打开一个连接并向下喷射字节.

If it comes to it, have your boss outline exactly how he'd marshal data across his socket connection and then do some quick calculations to see if you could match or beat them with HTTP. Will he use something like Google's Protocol Buffers, or write his own marshaling protocol? If so, will it be self-describing? How about application "verbs" like what you'd get for free in HTTP? Will his connections be persistent? There's a lot more to "sockets" than just opening a connection and spewing bytes down it.

您还正确地指出，您的老板似乎更喜欢套接字的原始速度，而不是其他一切:可扩展性、可维护性、开发和测试工具的可用性、协议嗅探器、HTTPS 动词的有用语义等等.HTTP 被负载平衡器和防火墙等很好地理解.您的专有套接字协议不会那么幸运.

You've also correctly noted that your boss seems to be favoring raw speed of sockets over everything else: scalability, maintainability, availability of development and testing tools, protocol sniffers, the helpful semantics of the HTTPS verbs, and so on. HTTP is well understood by load balancers and firewalls and the like. Your proprietary socket protocol will not be so lucky.

我的建议是您查看所有选项，并通过测试、原型设计和基准测试从性能角度评估它们.然后将这些数字与使用该技术构建和维护应用程序的难度进行权衡.

What I'd suggest is you look into all the options out there and evaluate them from a performance perspective through testing, prototyping and benchmarking. Then weigh those numbers against the difficulty of building and maintaining the application with that technology.

这篇关于RESTful Web 服务与数据密集型应用程序的套接字编程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！