Una buona comunicazione tra le applicazioni locali è una buona idea?

Question

Mi chiedo se sia una buona idea lasciare che le applicazioni locali (nello stesso server) comunichino tra loro interamente tramite l'API Restful?

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

Ma voglio portarlo a un livello superiore creando applicazioni che si comportino 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 Restful API.

In questo modo queste applicazioni/moduli potrebbero essere in qualsiasi lingua e potrebbero comunicare attraverso il cavo tra server.

Ma ho alcune domande:

• questa è una buona idea?
• Il trasferimento dei dati tra di loro sarà lento?
• Se faccio questo, ogni applicazione/modulo deve essere un server HTTP giusto? Quindi, se la mia applicazione utilizza 100 applicazioni/moduli, ognuno di questi 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?
• Eventuali best practice/trucchi che dovrei sapere?

Answer 1

• È una buona idea?

Certo, forse.

• Il trasferimento di dati tra è lento?

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

• Se ho fare questo, allora ogni applicazione/modulo deve essere un diritto server HTTP?Quindi, se la mia applicazione utilizza 100 applicazioni/moduli devo avere 100 server web HTTP locale su e esecuzione ognuno 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.

• Qualsiasi best practice/trucchi che avrei dovuto conoscete?

L'unico modo in cui questo avrà successo è se i servizi di cui si sta parlando sono abbastanza grezzi. Questi devono essere grandi, neri tipi di servizi squisiti che fanno la spesa di chiamarli meritevoli. Si verificheranno costi di connessione, costi di trasferimento dati e costi di marshaling dei dati su ciascuna transazione. Pertanto, si desidera che tali transazioni siano il più rare possibile e si desidera che i payload siano il più ampi possibile per ottenere il massimo beneficio.

Stai parlando effettivamente usando l'architettura REST o semplicemente inviando roba avanti e indietro via HTTP? (Queste sono cose diverse) REST incorre i propri costi, inclusi collegamenti incorporati, tipi di dati comuni e diffusi, ecc.

Infine, potrebbe non essere necessario. Potrebbe essere "abbastanza bello", un "bello da avere", "sembra buono sulla lavagna bianca", ma se, davvero, non ne ha bisogno, allora non farlo. Basta seguire buone pratiche di isolare i propri servizi interni in modo che si dovrebbe decidere in seguito di fare qualcosa di simile, si può semplicemente inserire lo strato di colla necessaria per gestire la comunicazione, ecc Aggiunta di distribuzione remota aumenta il rischio, la complessità e prestazioni inferiori, (scala ! = prestazioni) quindi ci dovrebbe essere un buon motivo per farlo affatto.

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

Edit - Risposta al commento:

Quindi significa che io corro un server web che gestire tutte le richieste in arrivo? Ma poi i moduli non saranno applicazioni standalone , che sconfigge l'intero scopo . Voglio che ognuno dei moduli sia in grado di funzionare da solo.

No, non vanifica lo scopo.

Ecco l'affare.

Supponiamo di avere 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 questi sono tre servizi diversi, su 3 macchine diverse, in esecuzione in 3 diversi server web.

Ma la verità è che questi possono essere tutti in esecuzione sulla macchina SAME, sul server Web SAME, anche fino a (per portare questo all'estremo) con la stessa logica.

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

Come cliente tutto quello che ti interessa è l'URL da utilizzare e il carico utile da inviare. A quale macchina finisce per parlare, o quale codice effettivo lo esegue, non il problema dei client.

A livello di architettura, è stata raggiunta una modalità di astrazione e modularizzazione. Gli URL ti consentono di organizzare il tuo sistema indipendentemente dal layout LOGICO che desideri. L'implementazione FISICA è distinta dalla vista logica.

Questi 3 servizi possono essere eseguiti su una singola macchina servita da un singolo processo. D'altra parte, possono rappresentare 1000 macchine. Quante macchine pensi di rispondere a "www.google.com"?

È possibile ospitare facilmente tutti e 3 i servizi su una singola macchina, senza condividere alcun codice, salvare il server Web stesso. Semplificando lo spostamento di un servizio dalla sua macchina originale ad un'altra macchina.

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

È necessario esplorare più funzionalità di un server Web moderno per indirizzare richieste arbitrarie alla logica effettiva sul server. Li troverai molto flessibili.

Answer 2

Per l'utilizzo di soluzioni restful per l'integrazione delle applicazioni, credo che questa sia una buona idea e ha affermato visualizzazioni simili a un'altra domanda.

• How to share data across an organization

Answer 3

per dirla tutta non credo che avete bisogno di 100 server per 100 applicazioni, forse basta usare 100 porte sullo stesso server.

e inoltre, l'interfaccia RESTful offre la flessibilità necessaria per espandere i server e abilitare il bilanciamento del carico se si vuole che il potenziale sia scalabile.

Answer 4

È una buona idea?

Sì. È fatto tutto il tempo Ecco come funzionano tutti i server di database, ad esempio. Linux è pieno di applicazioni client/server che comunicano tramite TCP/IP.

Il trasferimento di dati tra di loro è lento?

No. TCP/IP utilizza localhost come scorciatoia per salvare l'I/O di rete effettivo.

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

Se faccio questo, 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 poi ognuno di questi deve essere un web server HTTP locale ogni esecuzione su una porta diversa (http: // localhost: 81, http://localhost:82, http://localhost:83 e così via) destra?

Sì. È così che funziona.

Eventuali best practice/trucchi che dovrei sapere?

Non digitare numeri di porta "hardcoded".

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

Utilizza una libreria WSGI e sarai felice di creare tutti i tuoi moduli nelle applicazioni WSGI. È quindi possibile utilizzare un banale server HTTP a 2 righe per avvolgere il modulo.

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

Answer 5

No, non è una buona idea se non si ha una buona ragione. È una buona idea mettere a strati il ​​codice della tua applicazione in modo che possa essere "riposato" in una fase successiva nel caso tu ne abbia bisogno. (O qualunque sia il miglioramento delle prestazioni è ritenuto necessario.) La maggiore complessità di implementazione dei "layer basati su server" è una buona ragione per non farlo. Vorrei suggerire:

• Scrivere un'applicazione ben strutturata con un codice buono e pulito.
• test con carichi di produzione attesi
• se necessario - il refactoring in strati che sono i server - ma .....

Un approccio migliore è quello di caricare bilanciare l'intera applicazione. Se stai facendo qualcosa di simile a rails senza stato nel server dell'app, non dovrebbe esserci alcun problema a eseguire più istanze in parallelo.

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