Недавно я настраиваю веб-сайт Python, и кажется, что архитектура nginx -> uwsgi -> wsgi application в наши дни очевидный выбор в мире Python. (На самом деле я переношу сайт MoinMoin, поддерживаемый Apache + mod_wsgi, на более новую виртуальную машину с nginx, поэтому мне потребовалось время, чтобы изучить возможности развертывания с поддержкой nginx.)
Я много читал о том, почему там потребности чтобы быть такими косвенными уровнями, и я полностью осознаю, что отдельные задействованные методы - nginx, uwsgi и wsgi - все современные, обладают очень высокой производительностью и все зрелые на сегодняшний день. Но поскольку в такой архитектуре задействовано 2 уровня IPC (nginx -> uwsgi и uwsgi -> wsgi application) Мне всегда было интересно
Я погуглил и не нашел прямого ответа. Достаточно ли малы накладные расходы IPC, или я просто не нашел нужных ключевых слов?
(Кстати, я читал, что сообщество Erlang создало несколько HTTP-серверов, которые принимают HTTP-запрос пользователя. прямо к коду приложения, а также очень высокая производительность. Я googledd, но не смог найти тест, сравнивающий эти 2 подхода)
В части uwsgi-> wsgi нет ipc. Единственное соединение / ipc - от nginx к uWSGI, и оно практически не влияет (помните, даже apache + mod + wsgi в режиме демона использует ipc)
Что касается части Erlang в вашем вопросе, есть высокопроизводительный http-парсер для python, который вы тоже можете встроить в свой код (даже uWSGI можно использовать, что whay), но опыт показал, что это не лучший подход для безопасности, универсальности и масштабируемости ( но, очевидно, вы вольны это делать). Наличие внешнего прокси выглядит наиболее разумным выбором (независимо от сервера приложений или языка)