REST или SOAP для большого объема транзакций и большого объема данных проекта - PullRequest
0 голосов
/ 16 января 2012

Требования к проекту:

Мне нужно создать веб-сервис, который будет принимать куски текстовых данных, в любом месте от нескольких килобайт до 10 мегабайт, но в среднем колеблется около нескольких сотен килобайт.Будет много транзакций, и я бы хотел защитить сервис аутентификацией, SSL и, возможно, некоторым шифрованием.

Я бы хотел, чтобы сервис поддерживал XML и JSON, если это возможно, и я хотел бы построить его с использованием инструментов с открытым исходным кодом - скорее всего, PHP / MySQL.

Предложения относительно возможных платформ PHPдобро пожаловать.

Я уже начал путь к созданию веб-службы REST на PHP с платформой Tonic, но я подумал, что могу ограничиться объемом данных, которые я могу публиковать в URI и публиковать так.много данных в URL звучало громоздко.Поэтому я смотрю на SOAP-решения.

Вопросы:

Ограничен ли объем данных, которые я могу публиковать в службе REST?

Существуют ли ограничения данных для протокола SOAP?

Вы рекомендуете использовать SOAP или REST в зависимости от требований проекта и почему?

1 Ответ

2 голосов
/ 16 января 2012

HTTP вообще не ограничен на уровне протокола, независимо от того, используете ли вы архитектуру REST или протокол SOAP, туннелируемый по HTTP.

Основным ограничением будет объем памяти, особенно если вы используете несколько потоков.мультимегабайтные полезные нагрузки.С достаточно умным обработчиком и совместимым запросом вы можете выбрать потоковую передачу меньших запросов только в память и больших запросов непосредственно на диск перед обработкой.

Подобные подробности, вероятно, ограничивают то, сколько может сделать любая выбранная вами средавы, так как большинство, вероятно, будет потреблять прямо в памятьМожете ли вы изменить это вообще или по запросу на основе запроса, зависит от платформы и, возможно, от вашего желания изменить его.

Выбор SOAP в качестве протокола, вероятно, не имеет значения.Это всего лишь простой конверт XML вокруг вашей полезной нагрузки, если только вы не решите кодировать свои сообщения с помощью кодировок SOAP.

Поскольку вы также хотите поддерживать JSON, стек SOAP, скорее всего, будет просто мешатьбэкэнд необработанной HTTP-обработки.

Вы не упоминаете о сложности вашего API, но, скорее всего, для большей части вы могли бы обойтись фреймворком и просто написать собственный обработчик для больших, тяжелых транзакций.

Ваши транзакции в секунду не будут высокими, поскольку сами транзакции будут такими большими.Если вы выполняете потоковую передачу на диск, это также окажет большое влияние на ввод / вывод (в любом случае это произойдет, если вы не конвертируете данные в ОЗУ и не выплевываете их обратно в сокет, а не сохраняете их).,Таким образом, пропускная способность ввода-вывода, скорее всего, станет вашим основным узким местом с точки зрения того, что ограничит вашу общую производительность.

Если вы получаете загрузки от потребителей, вы, вероятно, будете получать около 150 Кбайт в год.второе (много скоростей загрузки потребителя - отстой - мой, например).Если у вас есть канал ввода-вывода, который может поддерживать, скажем, 60 МБ / с, то это 400 одновременных соединений.Так что это должно дать вам представление о масштабировании машины, основанном на ожидаемых объемах транзакций (конечно, вы уже провели этот анализ - я просто готовлю этот материал на ходу).При каждой загрузке транзакции 300 КБ это 2 с на транзакцию, то есть 200 TPS.Это еще одна цифра для игры (возможно, с точки зрения того, что может выдержать ваша база данных и т. Д., Особенно если у вас будет несколько машин, питающих ее).

Современные процессоры отвратительны, поэтому PHP или что-то должно бытьхорошо - это не будет твоей проблемой.

...