Qual a melhor maneira de separar um serviço da Web de seus nomes de domínio disponíveis publicamente?

Question

Estou tentando projetar um sistema que permita vários pontos de extremidade públicos que se difundam em um único serviço da web. O serviço da Web deve ser capaz de determinar qual ponto de extremidade foi o destino pretendido da solicitação. Veja uma pequena configuração de amostra que pode se encaixar na fatura:

Nessesistema,os"proxies reversos" (por falta de um termo melhor) adicionam um cabeçalho HTTP às solicitações recebidas antes de atingirem o serviço da web. Caso contrário, os proxies são totalmente transparentes para o pedido e a resposta.

Somos uma loja do Windows que usa o IIS7 / WCF.

O objetivo é 1) manter apenas um único serviço da web, em vez de um por domínio, e 2) dissociar o gerenciamento de domínio / site da lógica de negócios no serviço da web. Ou seja, se soubermos que o contexto sempre será especificado com uma chave no cabeçalho HTTP, não precisaremos nos preocupar com a alteração de domínios ou o conteúdo específico de Request.Headers["HOST"] .

Minhas perguntas são: esta é uma abordagem razoável? Em caso afirmativo, existe um aplicativo lá fora que fará o trabalho dos "proxies reversos"? (Squid? IIS em si?)

Obrigado pela ajuda!

    

Answer 1

Parece-me que o que você está tentando fazer é ter um único aplicativo que faça duas coisas totalmente separadas. Em um determinado ponto, haverá sobreposição na base de código e na funcionalidade, mas não conheço seu aplicativo o suficiente para ajudá-lo com isso. Eu tenho 2 soluções possíveis para você:

1. Eu tentaria separar o código relacionado à visualização de seus controladores e modelos se você estivesse indo na direção do MVC. Isso lhe daria uma separação mais clara da lógica de negócios. Uma maneira possível de fazer isso é colocar suas exibições em dois diretórios separados, mas incluir o código de um terceiro diretório compartilhado. Isso fornece uma biblioteca compartilhada que lida com a lógica de back-end ao separar com clareza a lógica de apresentação.

2. Eu não teria medo do cabeçalho do host HTTP. É exigido pelo HTTP / 1.1 e todos os navegadores modernos o usam. Heck, hospedagem virtual é totalmente dependente dele e você seria duramente pressionado para encontrar um administrador do IIS ou Apache que lhe diria para não usar hosts virtuais em produção. A grande desvantagem é claro, se você está fazendo a verificação de cabeçalho no lado do aplicativo, é possível executar algumas declarações if / case bastante feias. A única coisa que uma configuração de proxy reverso faz é procurar por um host e adicionar outro cabeçalho além do host. Então você está apenas adicionando mais cabeçalhos e complexidade à sua arquitetura com o proxy reverso.

Answer 2

Em primeiro lugar, o campo do seu host HTTP deve ser preservado pelo seu proxy reverso conforme ele passa pela solicitação. Se não for, então seu proxy está errado (e estranhamente!) Configurado.

Em segundo lugar, passar cabeçalhos extras e identificar o tráfego é a maneira padrão e aceita de identificar o tráfego manipulado por um balanceador de carga. Por exemplo, é como os balanceadores de carga geralmente são configurados para informar aos servidores da Web que o tráfego está chegando por SSL (pois o SSL não pode ser intermediado por proxy nesse nível).

Finalmente, acho que você pode estar complicando demais o seu problema. Realisticamente, com que frequência os nomes de domínio mudam em comparação com o conteúdo por trás deles? Não é exatamente assim que a Web deve funcionar ... Não há nada errado com seu aplicativo veiculando conteúdo com base no nome de domínio no cabeçalho do Host HTTP, é uma prática muito comum.

    

Answer 3

Uma maneira de fazer isso seria ter um pequeno conjunto de balanceadores de carga em nuvem, cada um destinado ao seu serviço da web. A Rackspace fornece LBaas e possivelmente outros também.

link

Divulgação completa: Eu trabalho para a Rackspace, mas não para vendas.