Quanto è davvero scalabile un'architettura basata su servizi Web?

Question

Ogni volta che qualcuno parla di un'architettura basata sui servizi, spesso menziona la scalabilità, spesso nello stesso respiro. Tuttavia, sembra che l'utilizzo dei servizi aggiunga più sovraccarico, anziché ridurlo, poiché ora è coinvolto un protocollo, come SOAP o REST. Quindi, un'architettura basata su servizi Web aggiunge davvero vantaggi in termini di prestazioni in quanto il numero di utenti, ad esempio, di un'applicazione Web, scala forse di un ordine di grandezza? Oppure i requisiti di scalabilità sono semplicemente scaricati sui servizi, piuttosto che sull'applicazione principale?

Answer 1

Scalabilità e prestazioni sono due cose separate. Sì, un approccio basato sui servizi aggiunge il sovraccarico di un protocollo di rete, ma questo è un sacrificio minimo per i vantaggi di poter adottare rapidamente servizi ben collaudati in qualsiasi applicazione nel dominio.

Se l'overhead della rete è un punto di rottura per il sistema che si desidera costruire, chiaramente SOA è la scelta sbagliata per te. Ricorda che non è mai necessario accedere al servizio tramite HTTP. Penso che rimarrai sorpreso dalla velocità con cui alcuni protocolli (come net.tcp ) possono essere.

Answer 2

Ricorda che puoi ridimensionare un servizio Web per l'esecuzione su più server, senza influire sui client. Non funziona così bene con un sistema strettamente accoppiato.

Answer 3

Una SOA adeguatamente progettata consente a ciascun componente del sistema di funzionare indipendentemente da tutti gli altri e di funzionare in modo asincrono in parallelo, quindi sia le prestazioni che la scalabilità (due cose diverse) vengono limitate solo dal pezzo più lento / meno scalabile del sistema , piuttosto che il tempo totale impiegato per l'esecuzione di tutti i componenti in serie.

La SOA non è appropriata per tutte le soluzioni, quindi se non vedi alcun chiaro vantaggio per il tuo caso particolare, allora potrebbe non essercene nessuno.

Answer 4

I servizi Web non ti offrono scalabilità gratuitamente. In effetti è abbastanza facile creare un servizio che non si ridimensioni.

Quello che ti danno sono le opportunità per aumentare la scalabilità. E, avendo interfacce di servizio ben definite, puoi scambiare un'implementazione non scalabile rapida e sporca di un servizio con una migliore implementazione quando ne hai bisogno.

L'importante è non dimenticare la "A" in "SOA". Puoi fare un casino enorme semplicemente creando un sacco di servizi. Assicurati di avere un'architettura.

Un enorme passo verso la scalabilità si sta allontanando dai servizi di base, sincroni, di tipo query / risposta (come SOAP RPC), verso servizi asincroni. Vedi 'Enterprise Integration Patterns' di Hohpe e Woolf

Answer 5

RESTafarians ti ricorderà che REST non è un prototipo, è uno stile architettonico. REST è un modo per utilizzare HTTP direttamente, senza i wrapper utilizzati da SOAP, per fornire un modello di servizi. REST è molto più vicino al filo di SAPONE. Quello da solo non rende uno migliore dell'altro, entrambi hanno il loro posto.

La scalabilità di un modello di servizi non è così direttamente correlata a "servizi" (come nei servizi Web con la S maiuscola e la S maiuscola) rispetto alla natura apolide di questi servizi. Anche le app Web ben costruite sono scalabili e si potrebbe sostenere che siano scalabili come qualsiasi architettura basata sui servizi.

Una delle differenze tra i due modelli è che l'app Web senza "servizi" sta interagendo con i moduli di riferimento che vivono nello stesso processo a livello binario - non è necessaria la serializzazione. I servizi Web (SOAP o REST) ??introducono un certo livello di serializzazione che aggiunge sovraccarico. Questo sovraccarico, tuttavia, è spesso considerato degno dato il ripristino che fornisce (ovvero, gli stessi servizi Web che guidano le tue app internamente possono essere utilizzati anche per rendere felici i partner commerciali).

Una buona architettura è quella di esporre le classi di servizio (non i servizi Web, può creare confusione rapidamente! I servizi in questo contesto indicano le classi che servono processi aziendali di basso livello) alle tue app locali direttamente nel processo - sfruttando il capacità di parlare binariamente a questi servizi. Ma poi, per gli usi dei partner commerciali e di altri servizi, metti un sottile livello di servizi Web su queste classi di servizi già testate per offrire lo stesso livello di servizi disponibile dei servizi Web.

Answer 6

Ok, quindi definiamo " scalabilità " primo. Quasi tutto verrà ridimensionato : se hai bisogno di più capacità, ad una prima approssimazione, puoi semplicemente lanciare più hardware. Ma alcune architetture sono "più scalabili" & # 8212; cosa significa? Ha a che fare con il costo: un'architettura è "più scalabile" se il costo per unità di capacità aggiunta è inferiore.

La scalabilità in generale ha tre intervalli in qualsiasi architettura: c'è un costo fisso per la prima parte, quindi su un intervallo è lineare con una pendenza di 0; oltre quel punto la pendenza aumenta e ad un certo punto l'aggiunta di capacità è molto costosa.

Diciamo che un sistema è "scalabile linearmente" se la funzione che descrive il costo per unità di capacità aggiunta è approssimativamente lineare su un ampio intervallo. Ovviamente, è auspicabile che quella pendenza sia inferiore.

Quindi, ora, quando qualcuno chiede della "scalabilità" " di una SOA, SOAP o REST o altro, ecco di cosa stanno parlando.

Si dice che le architetture orientate ai servizi siano "più scalabili" perché l'aggiunta di più capacità è relativamente economica, anche se, come dici tu, potrebbe esserci un sovraccarico che ti rende necessaria una maggiore capacità per servire un singolo utente. Questo perché gran parte del costo e della complessità della gestione di un grande sistema deriva dalla necessità di mantenere lo stato della sessione, ovvero tenere traccia di ciò che accade tra le chiamate. Le architetture orientate ai servizi evitano ciò rendendo ogni chiamata relativamente indipendente dalla successiva, con architetture RESTful come caso limitante: tutto lo stato della sessione è codificato nella rappresentazione, quindi il resto del sistema non ha bisogno di conoscerlo. Quando si desidera aggiungere capacità, è sufficiente aggiungere un altro server; un semplice bilanciamento del carico sarà sufficiente per instradare i messaggi a quello nuovo.

(Notate che questo è intrinsecamente più tollerante agli errori: se un server muore, l'altro riceve più o meno automagicamente le richieste e non c'è alcuna sessione da perdere.)

Le architetture che richiedono molto stato della sessione, come alcuni sistemi J2EE, tendono a ridimensionarsi meno bene, poiché è necessaria molta ulteriore complessità per gestire lo stato della sessione.

Il tipo di caso limite, che si è visto nelle vecchie architetture basate su CGI, è quello in cui ogni sessione utente richiede un processo completo; Ho visto sistemi sul campo in cui fork / exec rappresentava il 40-50 percento del carico, dove c'era bisogno di un complicato impianto di bilanciamento del carico software per assicurarsi che le richieste arrivassero sempre alla macchina che teneva la sessione, e dove semplicemente esaurire gli slot di processo è stato un grosso problema. Uno di questi sistemi richiedeva l'acquisto di un nuovo server Starfire di fascia alta per aggiungere capacità.