Velocità dell'architettura web orientata ai servizi

Question

Velocità dell'architettura web orientata ai servizi

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

1

Immagina una semplice architettura dell'architettura di servizio: server singolo in cui ho un servizio che funge da API REST (PHP), un altro servizio per il rendering di frontend (nodejs) e forse un servizio di database.

Tutti comunicano attraverso le richieste localhost, quindi ad esempio il frontend riceve i dati dall'API chiamando http://localhost:{API PORT}/v1/products . Ora il flusso della richiesta dovrebbe essere front-end - > resto api - > database - > resto api - > frontend - > risposta al cliente.

C'è una penalità di prestazioni quando si utilizza questo approccio rispetto all'utilizzo di un'applicazione monolitica, in cui tutto è insieme? O è meglio utilizzare qualcosa come RabbitMQ per questo tipo di installazione?

architecture web-development performance rest microservices

posta d1001001 22.09.2015 - 13:57

fonte

3 risposte

Leggi altre domande sui tag architecture web-development performance rest microservices

Finite Element Shader Utilizzo di traduttori esterni in .NET

score 1 · Answer 1

Qualsiasi forma di astrazione ha una penalizzazione delle prestazioni. Ad esempio, le richieste HTTP tra diversi livelli ti costerebbero ogni micro o millisecondi ogni volta. La domanda che dovresti porci è piuttosto quanto sono importanti quei microsecondi di runtime rispetto al beneficio finale ottenuto dai micro-servizi (o una semplice architettura multitier). Ne vale la pena?

Di solito, le applicazioni più grandi che dovrebbero essere scalate sono candidati migliori per i micro-servizi. Piccole applicazioni che non hanno bisogno di scalare rapidamente tra più server si adattano meglio a un modello monolitico (qui monolitico significa una singola applicazione e un database, questo non impedisce di impostare un'architettura multitier corretta!)

score 0 · Answer 2

C'è un sovraccarico nel chiamare i servizi sullo stesso server, ma non è enorme. Qualsiasi problema di prestazioni che dovresti affrontare sarebbe correlato a una scarsa logica in uno dei livelli, oppure il server viene tassato dal peso combinato di tutti i processi.

La facilità di consentire al sistema di espandersi generalmente supera i costi generali minori a livello di singolo server. Anche la sua buona pratica per costruire app in questo maniero, perché è un modo comune per le architetture aziendali di essere architettato e averne familiarità fa bene alle opportunità di lavoro.

score 0 · Answer 3

Perché non costruire alcuni semplici servizi che comunicano in una catena per testarlo? La cosa più importante da testare è quanti utenti può supportare prima che inizi a impantanarsi.

Personalmente ritengo che triplicare il traffico http su un singolo server sia una penalizzazione delle prestazioni più grande di quanto molti pensino, ma dipende da cosa è il tuo SLA e se l'architettura lo soddisfa. Se si tratta di utenti che fanno richieste web per visualizzare una pagina web, è probabile che incontrerà lo SLA per un carico di utenti piuttosto elevato. Se si tratta di un servizio automatizzato che richiede migliaia di richieste in un breve lasso di tempo, è molto più probabile che diventi un collo di bottiglia prima degli altri livelli. Ma è anche probabile che sia possibile lanciarlo in una web farm e rimuovere quel collo di bottiglia con praticamente nessun ulteriore sforzo.