Como devo organizar vários servidores Express no mesmo sistema?

Question

Estou usando um servidor para hospedar vários aplicativos da web Node.js, que são distribuídos em vários domínios. Minha prática atual é executar um servidor Express para cada aplicativo em uma porta diferente e executar um servidor base que simplesmente roteia (redireciona) as solicitações para a porta / servidor Express correto. Isso funciona, mas significa que meu servidor de base está roteando cada solicitação HTTP (e redirecionando-a manualmente) e que meus usuários veem meus aplicativos como hospedados em [hostname.com]: 8000.

Depois de um pouco de pesquisa, descobri que posso usar http-proxy para minhas necessidades de roteamento, mas ainda gostaria de saber se há uma prática recomendada para executar vários servidores Express no mesmo sistema. É assim que estou planejando fazer isso:

Cada aplicativo da web terá sua própria pasta, com uma estrutura de pasta Express completa (app.js, rotas, visualizações etc.) Os aplicativos serão agrupados por domínio, portanto, um exemplo de estrutura de pasta seria:

    hostname.com/
        app.js
        routes/
        views/
        ...
        app1/
            app1.js
            routes/
            views/
            ...
        app2
        ...
    hostname2.com/
        app.js
        routes/
        views/
        ...

Terei que executar cada app.js separadamente com node (ou com para sempre , que Estou usando atualmente), e cada um terá que usar uma porta diferente internamente, com redirecionamentos entre aplicativos sendo apontados para a porta do aplicativo de destino.

Então, esse é o meu plano atual. Quais são os problemas com ele e quais armadilhas devo tentar evitar? Mais importante ainda, existe uma solução estabelecida para este problema - o problema de hospedar vários aplicativos da web no mesmo sistema com Node.js / Express?

EDITAR: Eu planejo eventualmente usar WebSockets e HTTPS, e a quantidade de largura de banda que minha configuração pode suportar é de pouca importância para mim - este é um servidor de desenvolvimento (pelo menos por agora). Obrigado a David Ellis por trazer à tona a questão dos WebSockets.

SEGUNDA EDIÇÃO: Obrigado a EhevuTov e David Ellis por suas respostas, que ajudaram muito. Ainda estou definindo uma estrutura geral para meu aplicativo e parece que essa questão foi abordada com alguns detalhes por esta questão StackOverflow

TERCEIRA EDIÇÃO: Percorri vários caminhos desde a postagem desta pergunta (embora ainda tenha muito a fazer). Verifique este arquivo em meu repositório GitHub , que aproveita o que Aprendi com as respostas a esta pergunta!

Answer 1

Como o Express usa Connect , tenho certeza de que você pode usar o middleware de host virtual do Connect.Ele opera de forma semelhante a outros módulos vhost em outros produtos.Não tenho vários domínios para testar e mostrar o código adequado, mas acho que é algo assim:

express.createServer()
.use(express.vhost('hostname1.com', require('/path/to/hostname1').app)
.use(express.vhost('hostname2.com', require('/path/to/hostname2').app)
.listen(80)

Se você chegar ao ponto em que um servidor Express não é suficiente, procure usar o Node.Cluster da API.Se isso também não for suficiente, a prática atual é colocar um proxy reverso asnyc, como o Nginx, na frente de seus servidores Express e apontar os proxies para seus servidores Express.

Answer 2

Se você não precisa usar WebSockets (ou qualquer recurso HTTP 1.1, na verdade), você pode usar o NginX como seu proxy .

A vantagem é que a carga total que o NginX pode manipular em relação ao Node é maior (sendo compilado estaticamente e especializado para esse tipo de coisa, basicamente), mas você perde a capacidade de transmitir quaisquer dados (enviando pedaços menores por vez).

Para um site menor, ou se você não tiver certeza de quais recursos precisará no futuro, provavelmente é melhor ficar com node-http-proxy e apenas mudar para NginX se puder demonstrar que o proxy é o gargalo em seu servidor.Felizmente, o NginX não é difícil de configurar se você precisar dele mais tarde.