Архитектура для захвата результатов веб-сервиса и отправки результата в другие веб-сервисы
Start не поддерживает длинные имена путей и пробелы. Вы должны преобразовать его в 8.3 совместимые пути.
import subprocess
import win32api
filename = "C:\\Documents and Settings\\user\\Desktop\file.avi"
filename_short = win32api.GetShortPathName(filename)
subprocess.Popen('start ' + filename_short, shell=True )
Файл должен существовать, чтобы работать с вызовом API.
3 ответа
Я думаю, вам может понадобиться балансировщик нагрузки для архитектуры вашего веб-сервиса. Вы можете использовать raspberry pi или любой другой компьютер, установить linux и запустить nginx в качестве балансировщика нагрузки, как то, что я сейчас делаю.
Вы можете прочитать больше на Как настроить Nginx в качестве балансировщика нагрузки
Если я правильно понимаю, вам нужна управляемая событиями архитектура, в которой запросы могут быть воспроизведены.
SNS похож на SQS в отделении вашей архитектуры и является либо темой, либо очередью. Разница в том, хотите ли вы опросить или отправить эти запросы.
Вариант использования SNS: вы будете отправлять сообщения в тему SNS, где оно будет храниться не более 14 дней. Затем вы можете запланировать тему SNS для доставки сообщений в конечную точку отдыха. Если это не удается, вы можете справиться с этим, поместив сообщение в DLQ (очередь недоставленных сообщений). Если это удастся, сообщение будет удалено из темы.
Вариант использования SQS: вы будете отправлять сообщения в тему SNS, где оно будет храниться не более 14 дней. Затем вы опрашиваете очередь на наличие событий, если процессы обработки событий удаляют ее из очереди. В противном случае вы можете использовать стратегию DLQ или просто оставить сообщение в очереди.
Хорошее чтение - Стратегии разветвления SNS
.Некоторые вопросы, которые вам, возможно, придется задать, прежде чем углубляться в архитектуру. Я предполагаю, что WS1 и WS2 принадлежат вам / вашей команде.
- Как долго вы хотите ждать, пока WS2 снова включится и будет работать после его отключения?
- Какое время ожидания ответа от WS1 и WS2?
- Есть ли какой-либо другой нисходящий сервис, который использует WS1, и если этот сервис имеет SLA / ожидаемое время ответа?
- Как WS1 ожидает получить ответ от WS2?
Короче говоря, подход, основанный на событиях, выглядит здесь как нельзя лучше. то есть вы можете иметь очередь между WS1 и WS2, так что WS1 отправляет сообщение в очередь запросов, WS2 забирает его, когда готово, и помещает ответ в очередь ответов, откуда WS1 может его прочитать. Пример. AWS и Azure .
Это может работать, а может и не работать, исходя из того, как вы можете отвечать на предыдущие запросы. Иногда лучше использовать обычный вызов на основе REST со стратегией повторения (например, стратегия экспоненциального отката в примере ). Благодаря этому вы также сможете быстрее получать отзывы о сбоях. Можно выбрать это, если ответы на вышеупомянутые вопросы
- Если время ожидания короткое, то есть в секундах
- Существует ожидание действительно быстрого времени ответа. В этом случае лучше сразу сообщить о сбое, чем ждать его.
- Если есть нисходящие приложения, которые имеют синхронную зависимость от WS1, следовательно, WS1 не может бесконечно ждать, пока WS2 обработает запрос
- Не существует предсказуемого канала ответа от WS2