Cosa c'è di veramente diverso tra SOA e Microservices

Naviga le tue risposte
9

responsabilità

Spero di non calpestare i piedi di nessuno o di offendere gli entusiasti di entrambi i concetti

Sfondo

Ho cercato reali differenze tra Service Oriented Architecture e Microservices, senza trovare alcuna risposta chiara.

Ho letto cose come:

  • gli effetti collaterali di SOA
  • SOA che è anti-pattern
  • I microservizi sono venuti per correggere gli errori di SOA
  • Gli ESB non sono realmente ESB, ma sono EAI
  • Eccessiva dipendenza da Message Broker
  • I venditori abusano della nozione di SOA e cercano di vendere i loro prodotti
  • SOA cresce in modo incontrollabile

Tuttavia, nulla definisce chiaramente le differenze architettoniche tra Service Oriented Architecture (come concetto) e Microservices (come concetto)

Secondo quanto ho capito, entrambi hanno:

  • Fornitori di servizi, facendo solo una cosa
  • Gateway di servizio / ESB che espongono tali servizi ai consumatori
  • Consumatore di servizi, accesso ai servizi tramite ESB / Gateway di servizio

Domanda

Quindi, c'è qualcosa di diverso dal ri-etichettare SOA in Microservices? è un vincolo tecnologico posto per limitare i microservizi a diventare macro?

Nota: non cerco opinioni, solo fatti concreti, si spera nei punti elenco

Riferimenti

Aggiornamento

Sembra che un dibattito simile sia avvenuto in una domanda di overflow dello stack , con opinioni divise sia che i microservizi siano architetture orientate ai servizi sotto mentite spoglie.

Conclusione dalla domanda SO:

  • MS è un caso speciale di SOA
  • MS supporta dimensioni più piccole delle applicazioni che ospitano servizi
  • MS dipende dalla tecnologia (l'uso di HTTP piuttosto che le opzioni del protocollo aperto)
  • MS si affida alla tecnologia per rafforzare la disciplina (distribuzione automatica di servizi)
  • MS considera gli ESB (malvagi), ma utilizza i gateway API che IMHO è un tipo di ESB

Ciò significa che MS è SOA, se è vero quanto segue:

  • MS supporta la nozione di orchestrazione? Uno o più processi principali gestiscono i flussi di lavoro
  • Esiste un livello di broker di messaggi in MS? Una serie di adattatori che traducono i formati dei messaggi dallo spazio dei messaggi dei produttori di servizi ai consumatori di servizi
  • I microservizi possono leggere i dati da applicazioni aziendali monolitiche? Possono essere le API di un'applicazione monolitica? o deve essere autonomo in applicazioni autonome, in grado di operare in modo indipendente?

Se la risposta all'ultima domanda risultasse negativa, i microservizi non sarebbero in grado di gestire sistemi di flusso di lavoro complessi, ad es. Sistemi di gestione delle carte di credito o sistemi di riconciliazione

    
posta A.Rashad 30.08.2017 - 18:35
fonte

2 risposte

2

Ecco la linea di fondo L'unica ovvia differenza tra SOA e Microservices è la nozione di

Smart Endpoints Dumb Pipes

A differenza di SOA , ciò si baserebbe su consumatori e produttori di servizi ignari, delegando la gestione del traffico, la traduzione del formato dei messaggi e l'orchestrazione dei servizi su sistemi esterni, ad es. ESB, orchestrator del servizio, broker dei messaggi.

    
risposta data 14.09.2017 - 15:23
fonte
10

Service Providers, doing only one thing

La differenza principale, che ha conseguenze diffuse del progetto, è che con Microservices questi Service Provider sono indipendentemente implementabili e scalabili .

Questo è fantastico, perché puoi essere più agile. Se un servizio ha bisogno di essere cambiato, devi solo cambiarlo, nessuno dei suoi parenti. Se vuoi provare un nuovo framework o linguaggio, fai una sostituzione drop-in per quel singolo servizio. Se hai improvvisamente bisogno di una capacità di 100x, avvia alcune nuove macchine con quel servizio per gestire quell'afflusso. Se vuoi qualcosa di versione, basta la versione senza toccare l'app intera . E facilita il monitoraggio, lo strumento, la divisione tra i team, obsoleto ...

Ma ha alcune implicazioni pesanti:

  • Il tuo processo di rilascio deve cambiare, perché la distribuzione di alcuni servizi è molto diversa dalla distribuzione di alcune dozzine di servizi.
  • Il processo di rilascio deve essere modificato, perché la distribuzione di un servizio su una macchina è molto diversa dalla distribuzione in poche decine di macchine.
  • È necessario modificare la progettazione, l'utilizzo e la distribuzione del database perché è piuttosto inutile distribuire un servizio se è necessario distribuire questo grande DB condiviso per funzionare (superando tutti gli altri servizi).
  • Il design e l'utilizzo delle librerie devono essere modificati perché è un po 'priva di significato implementare un servizio se è necessario aggiornare questa libreria condivisa (superando tutti gli altri servizi).
  • La tua registrazione / autorizzazione / gestione delle sessioni / ecc deve cambiare perché è piuttosto semplice condividere contenuti quando sei un solo servizio, ma diverso quando hai un po 'di piccoli servizi indipendenti che compongono il prodotto - e loro re andando a voler condividere cose. Oh, e tutte queste cose condivise hanno bisogno di occuparsi potenzialmente di versioni diverse.
  • La tua comunicazione deve cambiare. Con pochi servizi, è possibile rompere le cose lungo le linee in cui la comunicazione non avviene spesso e / o potrebbe accadere lentamente. Con i microservizi, parleranno molto tra loro e l'elevata latenza non la taglierà.
risposta data 30.08.2017 - 19:45
fonte

Leggi altre domande sui tag

Il mio algoritmo che estrae la scatola più grande che può essere fatta da scatole più piccole, è troppo lento Come faccio a mantenere i miei progetti trascinandoli con modifiche e ritocchi infiniti?