Я опубликовал это в ServerFault, но сообщество Node.js там кажется крошечным, поэтому я надеюсь, что это принесет больше внимания.
У меня есть приложение Node.js (0.4.9), и я изучаю, как его лучше всего развернуть и поддерживать. Я хочу запустить его в облаке (EC2 или RackSpace) с высокой доступностью. Приложение должно работать по HTTPS. Позже я буду беспокоиться о полном отказе Востока / Запада / ЕС.
Я много читал о keep-alive (Upstart, Forever), многоядерных утилитах (Fugue, multi-node, Cluster) и прокси / балансировщиках нагрузки (node-http-proxy, nginx, Varnish и Pound) . Однако я не уверен, как комбинировать различные доступные мне утилиты.
Я имею в виду эту настройку, и мне нужно сгладить некоторые вопросы и получить отзывы.
Общие вопросы:
Мне бы очень хотелось услышать, как люди настраивают текущую производственную среду и какую комбинацию инструментов они предпочитают. Очень признателен.
Шесть долгих лет, и никто не решился на ответ. Что ж, у меня есть немного ретроспективы, чтобы дополнить опыт, поэтому я предлагаю одну.
Q1. Может быть. Если вы не возражаете против добавления сложности кластера в свое приложение и осторожно избегаете всего, что может повлиять на главный процесс, тогда кластер отлично работает. В противном случае вам наверняка захочется, чтобы что-то управляло процессом вашего узла и перезапускало его при сбое приложения. Ваша ОС может предоставлять альтернативы, такие как daemon или systemd.
Q2. Нет. В лучшем случае, в хороший день, когда ветер за спиной, node-http-proxy почти так же хорош, как nginx или haproxy. За исключением SSL, где и haproxy, и nginx намного лучше. Было бы ужасно сложно создать аргумент в пользу того, что он более подходит.
Q3. Да или хапрокси. Пока у вас не возникнет необходимости вводить лак. Когда вы дойдете до этого момента, вам не придется задаваться вопросом, следует ли вам использовать лак. (Или вы будете использовать CDN).
Q4. Ваш звонок. Haproxy - это мой инструмент по умолчанию для завершения TLS и проксирования. Я не настолько ненавижу себя, чтобы поставить что-то столь важное, как балансировщик нагрузки, на чужой сервер, где я не могу запустить tcpdump или другие инструменты для устранения неполадок.
Да. Если вы хорошо знаете nginx, используйте его для обработки завершения HTTPS и проксирования запросов на серверы приложений. Если вы еще не сильно в nginx, рассмотрите haproxy вместо. С таким именем, как haproxy, вы ожидаете, что он действительно хорош в HA и проксировании, и это не разочарует.
haproxy / nginx. Всегда. Лучшее управление сертификатами, листинг на cipherli.stи т. д. Кроме того, обновление прокси-сервера при выпуске уязвимостей openssl меньше влияет на ваше приложение.
haproxy. (nginx теперь поддерживает проксирование веб-сокетов, поэтому срок действия этого вопроса истек).
Несколько сайтов и BGP. Внедрение в ваш стек таких инструментов, как keepalived или других одноранговых механизмов переключения TCP, может стать причиной сбоя с той же вероятностью, что и предотвратить его. Такие инструменты, как правило, используются редко, поэтому человек, знающий о них, не может практиковать, когда возникает необходимость. Делайте стек проще и зависите от навыков вашей сетевой команды. Они хорошо умеют обходить проблемы.