La comunicazione riposante tra applicazioni locali è una buona idea?

Question

Mi chiedo se sia una buona idea lasciare che le applicazioni locali (nello stesso server) comunicano tra loro tramite API RESTful?

So che questa non è una cosa insolita, perché abbiamo già applicazioni come CouchDB che utilizza il riposo HTTP per la comunicazione, anche con applicazioni locali.

Ma voglio portarlo a un livello superiore creando applicazioni che agiscono come moduli per un'applicazione più grande, che potrebbe anche essere un modulo per un'altra applicazione e così via. In altre parole, ci saranno molte applicazioni/moduli locali che stanno comunicando con API RESTful.

In questo modo queste applicazioni/moduli potrebbero essere in qualsiasi lingua e potrebbero comunicare oltre il filo tra i server.

Ma ho alcune domande:

• E 'questa una buona idea?
• Il trasferimento dei dati tra loro sarà lento?
• Se lo faccio, ogni applicazione/modulo deve essere un server HTTP giusto? Quindi, se la mia applicazione utilizza 100 applicazioni/moduli, ognuna di queste deve essere un server Web HTTP locale ciascuno in esecuzione su una porta diversa (http: // localhost: 81, http: // localhost: 82, http: // localhost: 83 E così via) giusto?
• Qualche best practice/gotchas che dovrei conoscere?

Answer 1

• E 'questa una buona idea?

Certo, forse.

• Il trasferimento dei dati tra loro sarà lento?

Sì! Ma rispetto a cosa? Rispetto alle chiamate interne native, assolutamente - sarà glaciale. Rispetto ad qualche altra API di rete, eh, non necessariamente più lento.

• Se lo faccio, ogni applicazione/modulo deve essere un server HTTP giusto? Quindi, se la mia applicazione utilizza 100 applicazioni/moduli, devo avere 100 server Web HTTP locali attivo ed in esecuzione ciascuno con porta diversa (http: // localhost: 81,http: // localhost: 82, http: // localhost: 83 e così via)?

Nah, nessun motivo per allocare una porta per modulo. Tutti i modi per farlo.

• Qualche best practice/gotchas che dovrei conoscere?

L'unico modo in cui questo avrà successo è se i servizi di cui parli sono abbastanza grossolani. Questi devono essere grandi tipi di servizi Black Boxy che rendono la spesa per chiamarli utili. Si incorreranno i costi di connessione, i costi di trasferimento dei dati e i costi di marshalling dei dati su ciascuna transazione. Quindi, vuoi che quelle transazioni siano il più rare possibile e vuoi che i payload siano il più grandi possibile per ottenere il miglior vantaggio.

Stai parlando effettivamente usando l'architettura del resto o semplicemente inviando cose avanti e indietro tramite HTTP? (Queste sono cose diverse) Il riposo comporta i propri costi, includono collegamenti incorporati, tipi di dati onnipresenti e comuni, ecc.

Infine, potrebbe semplicemente non aver bisogno di farlo. Potrebbe essere "un po 'bello", un "bello da avere", "sembra buono sulla tavola bianca", ma se, davvero, non ne ha bisogno, allora non farlo. Segui semplicemente le buone pratiche di isolamento dei tuoi servizi interni in modo che se dovessi decidere in seguito di fare qualcosa del genere, puoi semplicemente inserire lo strato di colla necessario per gestire la comunicazione, ecc. L'aggiunta della distribuzione remota aumenterà rischi, complessità e prestazioni più basse (ridimensionamento ! = Performance) Quindi dovrebbe esserci una buona ragione per farlo.

Questa, probabilmente, è la "migliore pratica" di tutti.

Modifica - Risposta al commento:

Quindi vuoi dire che eseguo un server Web che gestisce tutte le richieste in arrivo? Ma poi i moduli non saranno applicazioni autonome, il che sconfigge l'intero scopo. Voglio che ognuno dei moduli sia in grado di correre da solo.

No, non sconfigge lo scopo.

Ecco l'accordo.

Diciamo che hai 3 servizi.

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

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

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

A colpo d'occhio, sarebbe giusto dire che si tratta di tre diversi servizi, su 3 macchine diverse, in esecuzione in 3 diversi server web.

Ma la verità è che tutti possono essere in esecuzione sulla stessa macchina, sullo stesso server Web, anche fino a (per portare all'estremo) eseguendo la stessa identica logica.

HTTP ti consente di mappare tutti i tipi di cose. HTTP stesso è meccanismo di astrazione.

Come cliente tutto ciò che ti interessano è l'URL da utilizzare e il payload da inviare. Con quale macchina finisce per parlare o quale codice effettivo esegue non è il problema dei client.

A livello di architettura, hai raggiunto un modo di astrazione e modularizzazione. Gli URL ti consentono di organizzare il tuo sistema è qualunque layout logico tu voglia. L'implementazione fisica è distinta dalla vista logica.

Quei 3 servizi possono essere in esecuzione su una singola macchina servita da un singolo processo. D'altra parte, possono rappresentare 1000 macchine. Quante macchine pensi che rispondano a "www.google.com"?

Puoi facilmente ospitare tutti e 3 i servizi su un singolo macchina, senza condividere alcun codice Salva il server Web stesso. Facilitando la spostamento di un servizio dalla sua macchina originale ad un'altra macchina.

Il nome host è il modo più semplice per mappare un servizio a una macchina. Qualsiasi server Web moderno può servire qualsiasi numero di host diversi. Ogni "host virtuale" può servire qualsiasi numero di endpoint di servizio individuali all'interno dello spazio di nome di quell'host. A livello di "host" è banale per trasferire il codice da una macchina a un'altra se e quando è necessario.

Dovresti esplorare più funzionalità di un moderno server Web per dirigere le richieste arbitrarie alla logica effettiva sul server. Li troverai molto flessibili.

Answer 2

E 'questa una buona idea?

Sì. È sempre fatto. È così che funzionano tutti i server di database, per esempio. Linux è pieno di applicazioni client/server che comunicano tramite TCP/IP.

Il trasferimento dei dati tra loro sarà lento?

No. usa TCP/IP localhost come un casino per risparmiare eseguendo I/O di rete reale.

Il protocollo HTTP non è la cosa migliore per le connessioni dedicate, ma è semplice e ben supportato.

Se lo faccio, ogni applicazione/modulo deve essere un server HTTP giusto?

Non necessariamente. Alcuni moduli possono essere client e non avere un server.

Quindi, se la mia applicazione utilizza 100 applicazioni/moduli, ognuna di queste deve essere un server Web HTTP locale ciascuno in esecuzione su una porta diversa (http: // localhost: 81, http: // localhost: 82, http: // localhost: 83 E così via) giusto?

Sì. È così che funziona.

Qualche best practice/gotchas che dovrei conoscere?

Non "codifica dura" numeri di porta.

Non utilizzare i numeri di porta "privilegiati" (sotto 1024).

Usa una libreria WSGI e sarai più felice di trasformare tutti i tuoi moduli in applicazioni WSGI. È quindi possibile utilizzare un banale server HTTP a 2 righe per avvolgere il modulo.

Leggi questo. http://docs.python.org/library/wsgiref.html#examples

Answer 3

Usando soluzioni riposanti per l'integrazione delle applicazioni, credo che questa sia una buona idea e abbia professato opinioni simili in un'altra domanda.

• Come condividere i dati all'interno di un'organizzazione

Answer 4

Ad essere sinceri, non credo che tu abbia bisogno di 100 server per 100 applicazioni, forse usa solo 100 porte sullo stesso server.

Inoltre, l'interfaccia RESTful ti darà la flessibilità di espandere i server e abilitare il bilanciamento del carico se si desidera avere il potenziale per aumentare fino a ENORME.

Answer 5

No, non è una buona idea se non hai una buona ragione. È una buona idea stratificare il codice dell'applicazione in modo che possa essere "riposato" in una fase successiva se ne hai bisogno. (O qualunque sia il miglioramento delle prestazioni necessario.) L'aumento della complessità di distribuzione di "livelli basati sul server" è una buona ragione per non farlo. Suggerirei:

• Scrivi un'applicazione ben strutturata con codice buono e pulito.
• Testalo con carichi di produzione previsti
• Se necessario - refactor in strati che sono server - ma .....

Un approccio migliore è caricare il bilanciamento dell'intera applicazione. Se stai facendo qualcosa come i binari senza stato nel server di app, non dovrebbe essere un problema eseguire più istanze in parallelo.

Se stai cercando complessità, ignora la mia risposta. :-)