Архитектура для захвата результата веб-сервиса и отправки результата на другие веб-сервисы - PullRequest
Новая
       17

Архитектура для захвата результата веб-сервиса и отправки результата на другие веб-сервисы

0 голосов
/ 16 января 2019

Я занимаюсь разработкой приложения на C #. Я звоню в веб-службу (давайте назовем это WS1) и хочу, чтобы результат был отправлен на 1 или более других (внешних) веб-служб (например, WS2 и WS3).

В случае, если один из принимающих веб-сервисов (например, WS2) не работает, я хочу убедиться, что этот вызов не потерян и не будет повторен позже.

Что такое хорошая архитектура для достижения этой цели? У кого-нибудь есть ссылка на онлайн-документ, где описана подобная архитектура?

Ответы [ 3 ]

0 голосов
/ 16 января 2019

Некоторые вопросы, которые вам, возможно, придется задать, прежде чем углубляться в архитектуру. Я предполагаю, что WS1 и WS2 принадлежат вам / вашей команде.

  1. Как долго вы хотите ждать, пока WS2 снова включится и заработает, когда он выйдет из строя?
  2. Какое время ожидания ответа от WS1 и WS2?
  3. Есть ли какая-либо другая нисходящая служба, которая потребляет WS1, и если эта служба имеет SLA / время ожидания ответа?
  4. Как WS1 ожидает получить ответ от WS2?

Короче говоря, подход, основанный на событиях, выглядит здесь как нельзя лучше. то есть вы можете иметь очередь между WS1 и WS2, так что WS1 отправляет сообщение в очередь запросов, WS2 забирает его, когда готово, и помещает ответ в очередь ответов, откуда WS1 может его прочитать. Пример. AWS и Azure .

Это может работать, а может и не работать, исходя из того, как вы можете отвечать на предыдущие запросы. Иногда лучше использовать обычный вызов на основе REST со стратегией повторения (например, стратегия экспоненциальный откат ). Благодаря этому вы также сможете быстрее получать отзывы о сбоях. Можно выбрать это, если ответы на вышеуказанные вопросы

  1. Если время ожидания короткое, то есть в секундах
  2. Ожидается очень быстрое время отклика. В этом случае лучше сразу сообщить о сбое, чем ждать его.
  3. Если есть последующие приложения, которые синхронно зависят от WS1, следовательно, WS1 не может бесконечно ждать, пока WS2 обработает запрос
  4. Нет предсказуемого канала ответа от WS2

На заметку: если вы используете архитектуру, основанную на событиях, WS2 может больше не быть веб-службой:)

0 голосов
/ 23 января 2019

Я думаю, вам может понадобиться балансировщик нагрузки для архитектуры вашего веб-сервиса. Вы можете использовать raspberry pi или любой другой компьютер, установить linux и запустить nginx в качестве балансировщика нагрузки, как то, что я сейчас делаю.

Вы можете узнать больше на Как настроить Nginx в качестве балансировщика нагрузки

0 голосов
/ 16 января 2019

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

SNS похож на SQS в отделении вашей архитектуры и является либо темой, либо очередью. Разница в том, хотите ли вы опросить или отправить эти запросы.

Случай использования SNS: Вы будете отправлять сообщения в тему SNS, где оно будет храниться не более 14 дней. Затем можно запланировать тему SNS для доставки сообщений в конечную точку отдыха. Если это не удается, вы можете справиться с этим, поместив сообщение в DLQ (очередь недоставленных сообщений). В случае успеха сообщение будет удалено из темы.

Вариант использования SQS: Вы будете отправлять сообщения в тему SNS, где оно будет храниться не более 14 дней. Затем вы опрашиваете очередь на наличие событий, если процессы обработки событий удаляют ее из очереди. В противном случае вы можете использовать стратегию DLQ или просто оставить сообщение в очереди.

Хорошее чтение - Стратегии разветвления SNS

...