Restful comunicação entre aplicativos locais, é uma boa idéia?

Question

Gostaria de saber se é uma boa idéia deixar que as aplicações locais (no mesmo servidor) comunicar-se uns com os outros inteiramente através da API Restful?

Eu sei que isso não é uma coisa incomum, porque nós já tem aplicativos como o CouchDB que está usando HTTP DESCANSO para a comunicação, mesmo com aplicativos locais.

Mas eu quero levá-la para um nível superior, através da criação de aplicativos que funcionam como módulos para aplicações maiores, o que também pode ser um módulo para outro aplicativo e assim por diante.Em outras palavras, lá vai ser um monte de aplicativos locais/módulos que estão a comunicar com a API Restful.

Desta forma, estas aplicações/módulos podem ser em qualquer idioma, e eles poderiam se comunicar através de fios entre os servidores.

Mas tenho algumas dúvidas:

• É uma boa idéia?
• Será que a transferência de dados entre eles ser lento?
• Se eu fizer isso, então cada aplicação/módulo tem de ser um servidor HTTP certo?Então, se meu aplicativo usa 100 aplicações/módulos, cada um destes tem que ser um local de servidor web HTTP cada um executando em uma porta diferente (http://localhost:81, http://localhost:82, http://localhost:83 e assim por diante) certo?
• Qualquer melhores práticas/estratégias que eu deva conhecer?

Answer 1

• É uma boa idéia?

Certo, talvez.

• Os dados transferência entre eles ser lento?

Yup!Mas comparado com o que?Comparado com nativas, chamadas internas, absolutamente -- será glacial.Em comparação com alguns outros API de rede, eh, não, necessariamente, mais lento.

• Se Eu fazer isso, então cada aplicação/módulo tem que ser um servidor HTTP certo?Por isso, se meu aplicativo usa 100 aplicações/módulos de eu ter 100 HTTP local, servidores web e a execução de cada um com diferentes porta (http://localhost:81, http://localhost:82, http://localhost:83 e assim por diante)?

Nah, não há motivo para atribuir uma porta por módulo.Todos os tipos de formas para fazer isso.

• Qualquer melhores práticas/estratégias que eu deveria conhece?

A única maneira que isto vai ter sucesso é se os serviços de que você está falando são grossas o suficiente.Estes têm de ser grandes, pretas quadradão tipos de serviços que tornam a despesa de chamá-los de que vale a pena.Você estará incorrendo em custos de ligação, custos de transferência de dados, e dados de empacotamento de referências de custo em cada transação.Então, você quer que as transações para ser tão raro quanto possível, e você deseja a cargas de ser tão grande quanto possível para obter o melhor benefício.

Você está falando, na verdade, usando a arquitetura REST ou apenas o envio de material e para trás através do HTTP?(Estas são coisas diferentes) RESTO incorre em suas próprias despesas, incluir incorporado ligações, onipresente e tipos de dados comuns, etc.

Finalmente, você simplesmente não precisa fazer isso.Ele pode muito bem ser "legalzinho", um "bom para", "parece bom no quadro branco", mas, realmente, não precisa dele, então não fazê-lo.Basta seguir as boas práticas de isolamento de seus serviços internos, de modo que você deve decidir mais tarde para fazer algo como isso, você pode inserir apenas a camada de cola necessária para gerenciar a comunicação, etc.A adição de distribuição remoto irá aumentar o risco, a complexidade e desempenho inferior, (dimensionamento != de desempenho), então deve haver uma Boa Razão para fazê-lo em tudo.

Que, sem dúvida, é a de "melhor prática" de todos eles.

Edição -- Resposta ao comentário:

Então você quer dizer que eu execute UM servidor web que lidar com todos os pedidos de entrada?Mas, em seguida, os módulos não ser stand-alone aplicações, o que frustra toda a propósito.Eu quero que cada um dos módulos para ser capaz de executar por si só.

Não, ele não anule o objectivo.

Aqui está o negócio.

Digamos que você tem 3 serviços.

• http://store.example.com/service1

• http://blog.example.com/service2

• http://forum.example.com/service3

De relance, que seria justo dizer que esses são três serviços diferentes, em 3 máquinas diferentes, sendo executado em 3 diferentes servidores da web.

Mas a verdade é que estes podem ser executados na MESMA máquina, no MESMO servidor web, até mesmo para (levar isso ao extremo) executando exatamente a mesma lógica.

HTTP permite mapear todos os tipos de coisas.HTTP si é um mecanismo de abstração.

Como um cliente tudo o que você se preocupa é o URL a utilizar e a carga enviar.O que a máquina acaba falando, ou o código real, ele executa não é o problema clientes.

Em uma arquitetura de nível, você tem conseguido uma forma de abstração e modularização.As URLs lhe permitem organizar o sistema é qualquer esquema LÓGICO que você deseja.A implementação FÍSICA é distinta da visão lógica.

Os 3 serviços podem ser executados em uma única máquina servido por um único processo.Por outro lado, eles podem representar 1000 máquinas.Quantas máquinas você acha que responder "www.google.com"?

Você pode facilmente host todos os 3 serviços em uma única máquina, sem o compartilhamento de qualquer código de salvar o próprio servidor web.Tornando mais fácil para mover um serviço a partir de sua máquina original para alguma outra máquina.

O nome do host é a maneira mais simples para mapear um serviço para uma máquina.Qualquer um moderno servidor web pode estar a serviço de qualquer número de hosts diferentes.Cada "host virtual" pode servir qualquer número de pontos de extremidade de serviço dentro do espaço de nome de host.O "host" do nível de seus trivial para realocar o código de uma máquina para outra, se e quando necessário.

Você deve explorar mais os recursos de um moderno servidor web para direcionar arbitrário pedidos a lógica real no servidor.Você vai encontrá-los muito flexível.

Answer 2

isso é uma boa ideia?

Sim. Está feito o tempo todo. É assim que todos os servidores de banco de dados funcionam, por exemplo. O Linux está cheio de aplicativos de cliente/servidor que se comunicam através do TCP/IP.

A transferência de dados entre eles será lenta?

Não. localhost como um pouco mais curto para economizar a E/S de rede real.

O protocolo HTTP não é a melhor coisa para conexões dedicadas, mas é simples e bem suportado.

Se eu fizer isso, cada aplicativo/módulo deve ser um servidor HTTP, certo?

Não necessariamente. Alguns módulos podem ser clientes e não ter um servidor.

Portanto, se meu aplicativo usa 100 aplicativos/módulos, cada um deles deve ser um servidor Web HTTP local, cada um em uma porta diferente (http: // localhost: 81, http: // localhost: 82, http: // localhost: 83 e assim por diante) certo?

Sim. É assim que funciona.

Alguma prática recomendada/pegadinha que eu deveria conhecer?

Não "codifique" números de porta.

Não use os números de porta "privilegiados" (abaixo de 1024).

Use uma biblioteca WSGI e você ficará mais feliz, transformando todos os seus módulos em aplicativos WSGI. Você pode usar um servidor HTTP trivial de 2 linhas para envolver seu módulo.

Leia isso. http://docs.python.org/library/wsgiref.html#examples

Answer 3

Ao usar soluções RESTful para integração de aplicativos, acredito que essa é uma boa idéia e professou visualizações semelhantes em outra pergunta.

• Como compartilhar dados em uma organização

Answer 4

Para ser franco, acho que você não precisa de 100 servidores para 100 aplicativos, talvez apenas use 100 portas no mesmo servidor.

Além disso, a interface RESTful fornecerá a flexibilidade de expandir os servidores e ativar o balanceamento de carga, se você quiser ter o potencial de aumentar a escala.

Answer 5

Não - não é uma boa ideia se você não tiver um bom motivo. É uma boa ideia colocar o código do seu aplicativo para que possa ser "descansado" em um estágio posterior, caso você precise dele. (Ou qualquer melhoria de desempenho é considerada necessária.) O aumento da complexidade da implantação de "camadas baseadas em servidor" é um bom motivo para não fazê -lo. Eu sugeriria:

• Escreva um aplicativo bem estruturado com código bom e limpo.
• Teste com cargas de produção esperadas
• Se necessário - refatorar em camadas que são servidores - mas .....

Uma abordagem melhor é o equilíbrio de carga todo o aplicativo. Se você estiver fazendo algo como trilhos sem estado no servidor de aplicativos, não deve ser um problema executar várias instâncias em paralelo.

Se você está procurando complexidade - desconsidere minha resposta. :-)