Делегирование задач для критического приложения миссии

Question

Я работаю над критически важным приложением. Приложение извлекает данные фондового рынка с разных фондовых рынков, таких как NYSE, NASDAQ и т. Д., Используя стороннюю услугу. Клиенты могут обратиться в заявку и добавить свой Портфолио (какие у них акции у этой компании). И затем установите оповещения. например. Уведомить меня, когда цена AAPL превысит $ xxx на NASDAQ. когда цена на MSFT будет ниже $ zzz на NYSE.

У меня есть работа cron, которая извлекает рыночные данные из стороннего сервиса для всех пользователей тиккеров, добавленных (AAPL, GOOG, MSFT и т. Д.) Каждые 1 мин. После получения данных я получаю все предупреждения, которые были созданы пользователями, а затем отправляет их по электронной почте, SMS, Pushover, Twitter, Facebook-сообщению и т. Д. Также добавьте это уведомление в базу данных приложения, чтобы пользователь мог видеть его в приложении, когда они вступают в систему.

Теперь, поскольку это приложение с интенсивным временем, неспособность получить данные может привести к большим потерям, поскольку клиенты платят за критически важные данные.

В настоящее время я нажимаю все отправители уведомлений на очередь. Рабочий (на моем сервере) отправляет уведомление. Есть ли еще какие-либо другие способы делегирования как можно большей работы сторонним серверам? Вы бы рекомендовали использовать рабочий стол Iron.io, чтобы он также выполнял отправку уведомлений. Возможно также получение данных с рынка.

Спасибо!

Answer 1

Архитектурно существует ряд подходов, но звучит так, как будто вы делаете правильный выбор. Используя queue to decouple, производитель из процесса уведомления имеет смысл. Это позволяет использовать более правильную архитектуру SOA, где вы можете изменять/обновлять/разрабатывать различные части приложения независимо, не беспокоясь слишком сильно о тесно связанном коде.

Тем не менее, ваш вопрос специально касается разгрузки третьим сторонам. Существуют третьи стороны, которые могут абстрагировать часть уведомления из вашего кода. Я не очень хорошо знаком с ними, но есть много вариантов: PubNub, Pusher, Twilio, SendGrid, Mailgun, AWS SNS и т. Д.

Я работаю для Iron.io. У нас есть много клиентов, которые делают именно то, что вы пытаетесь выполнить: создание рабочих, которые становятся маленькими мини-сервисами и называя их либо из push-событий, либо по запланированным задачам, либо по запросу. Это освобождает вас от необходимости работать с очередью, маршрутизацией, планированием и рабочим/фоновым сервером.

Мы будем рады помочь вам с нуля с самого начала, просто протяните руку support@iron.io.