Ответ 1
На этот вопрос нет правильного ответа, но вот несколько вещей, о которых следует помнить:
При правильном масштабировании по горизонтали вполне возможно, что вы сможете продолжать масштабирование использования сервера отладки навсегда. Когда именно вам потребуется начать масштабирование (или перейти на использование "настоящего" веб-сервера), это также будет зависеть от среды, в которой вы размещаетесь, ожиданий пользователей и т.д.
Основная проблема, с которой вы, вероятно, столкнетесь, заключается в том, что сервер является однопоточным. Это означает, что он будет обрабатывать каждый запрос по одному, последовательно. Это означает, что если вы пытаетесь обслуживать более одного запроса (включая значки, статические элементы, такие как изображения, файлы CSS и Javascript и т.д.), Запросы будут выполняться дольше. Если какой-либо заданный запрос занимает много времени (скажем, 20 секунд), тогда все ваше приложение не отвечает на это время (20 секунд). Конечно, это только значение по умолчанию: вы можете увеличить количество потоков (или обрабатывать запросы в других процессах), что может облегчить некоторые проблемы. Но еще раз, он все еще может быть медленным при "высокой" нагрузке. То, что считается "высокой" нагрузкой, будет зависеть от вашего приложения и ожиданий максимально приемлемого времени отклика.
Еще одна проблема - это безопасность: если вас беспокоит ВСЕ о безопасности (и не только о безопасности данных в самом приложении, но и о безопасности устройства, на котором оно будет запущено), вам не следует использовать сервер разработки. Он не готов противостоять какой-либо атаке.
Наконец, сервер разработки может просто выйти из строя. Он не предназначен для использования в качестве длительного процесса (дни, недели, месяцы), и поэтому он не был хорошо протестирован для работы в этом качестве.
Так что да, у него есть ограничения. Да, вы все еще можете использовать его в производстве. и да, я все равно рекомендовал бы использовать "настоящий" веб-сервер. Если вам не нравится идея установить что-то вроде Apache или Nginx, вы все равно можете воспользоваться решением, которое по-прежнему так же просто, как "запустить скрипт на python" с использованием некоторых автономных серверов WSGI, который может запускать сервер, предназначенный для работы, с чем-то таким же простым, как запуск python run_app.py в командной строке. Обычно вам просто нужно создать сценарий Python из 4-5 строк, чтобы импортировать и создать объект сервера, указать его на свой флакон app и запустить его.
gunicorn может быть запущен с использованием только следующего в командной строке, дополнительный сценарий не требуется:
gunicorn myproject:app
... где "myproject" - это пакет Python, который содержит объект app Flask. Имейте в виду, что один из разработчиков gunicorn, вероятно, рекомендовал бы против такого подхода. Смотрите https://serverfault.com/questions/331256/why-do-i-need-nginx-and-something-like-gunicorn.