Развертывание избыточной резервной копии API

#server #webhooks #web-hosting

#сервер #webhooks #веб-хостинг

Вопрос:

У меня есть API, работающий на локальном сервере с нестабильной сетью. Я хочу добавить некоторую избыточность в облаке, но не знаю лучшего / дешевого способа сделать это.

API получает некоторые данные с веб-узла и обновляет устройство в локальной сети.

То, что я обдумывал, — это урезанная версия API, которая просто хранит данные webhook, выполняет пинг основного API, и если он запущен и получил данные, ничего не делает (не сохраняет данные локально, если это так), но если основной API отключен, он отправляет электронное письмо и сохраняет данные, а затем через 12-24-часовые интервалы повторно отправляет данные до тех пор, пока это не удастся (высока вероятность того, что сеть отключена, пока кто-то физически не перезагрузит оборудование, для исправления которого мне требуется $, которого у меня нет). Есть ли лучший способ добиться этого?

Кроме того, какой сервис лучше всего подходит для такого развертывания / какие инструменты доступны, чтобы помочь с чем-то подобным? Для отправки и получения будет не более 100 запросов в месяц, поэтому я бы хотел, чтобы это было дешево / бесплатно. Хотя с 24-часовым таймером я не знаю лучшего способа сделать это. Я использовал Heroku в прошлом и знаю о его возможностях планировщика, но я не использовал их и хотел получить больше информации, прежде чем инвестировать в это как решение. Текущий API не может быть развернут как есть, и мне, вероятно, придется перестраивать с нуля, чтобы заставить его работать в облачной среде, поэтому я хотел бы что-то выбрать заранее.

Ответ №1:

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

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

Я упоминаю AWS, но есть много альтернатив (Google Cloud является наиболее очевидным).

Комментарии:

1. Большинство сбоев в работе Интернета вызваны перебоями в подаче электроэнергии. Сервер расположен на старом заводе с проблемами подключения. Есть резервная батарея, но она предназначена только для периодических отключений. Сервер с API запускается повторно, но часть сетевого оборудования этого не делает. Таким образом, я все еще мог бы, вероятно, выполнить опрос локальной сети, но я также хотел бы, чтобы электронные письма уведомляли меня, когда сеть выходит из строя. Я знал об AWS Lambda, но на самом деле я не знаком с бессерверной архитектурой или использованием Lamda. Я воспользуюсь этим как возможностью изучить их! Спасибо за ответ!