Messaggistica in un'architettura di micro-servizi

Question

Sto iniziando a esaminare le architetture orientate ai servizi e mi chiedo come sia meglio strutturare la messaggistica tra i processi. Sembra che le chiamate HTTP dirette tra servizi e/o un bus pubub siano due approcci comuni. In quali tipi di situazioni è più favorevole dell'altra? Vedo come pubsub porterebbe a servizi più disaccoppiati ma ho anche l'impressione che sia molto più difficile tracciare il percorso di un messaggio attraverso il sistema.

Quali sono alcune risorse per saperne di più su questo? Sono particolarmente curioso di sapere ciò nel contesto di servizi molto piccoli, "arrotolati a mano" (es. Ruby/Sinatra, Node/Express, Redis pubub, ecc.) In contrasto con uno qualsiasi degli stack/suite SOA prescritti. .. anche se sono sicuro che si applicano gli stessi principi.

Grazie!

Answer 1

Ti darò i miei due centesimi.

but I also get the impression that it becomes much harder to track a message's path though the system.

Hai ragione che PubSub SOA architetture AKA (SOA 2.0) che fornisce una grande quantità di disaccoppiamento, ma anche paga un prezzo, perché questo è esattamente ciò che accade, anche se strumenti come Splunk possono aiutare una sacco.

seems that direct HTTP calls between services and/or a pubsub bus are two common approaches

In realtà se si guardano i quadri più utilizzati .net evento SOA (NServiceBus, mulo e MassTransit) non usano le chiamate HTTP, ma sì è possibile implementare un'architettura microservices e utilizzare http come protocollo di comunicazione.

Capisco che voglia iniziare ad applicare alcuni dei migliori concetti di architettura aziendale, ma direi che è meglio partire con fondazioni più semplici ma più forti. Non vi è alcun punto in cui tu salti all'evento soa, senza sapere se ne hai davvero bisogno. Se stavo iniziando un nuovo sistema e volevo assicurarmi di adattare correttamente i principi DDD e SOA, inizierei identificando i servizi per il mio dominio. Quindi, diciamo che hai 3 servizi, potresti iniziare dichiarando i contratti pubblici per ciascuno di questi servizi, non hai bisogno di nulla di speciale, puoi iniziare con l'API Web WCF/ASP.NET con un'API REST di sincronizzazione. Dovresti quindi assicurarti che ogni servizio ottenga il proprio database, perché stai puntando a un basso accoppiamento e potresti quindi creare di nuovo un livello API (quello visibile al mondo esterno) utilizzando nuovamente API Web WCF/ASP.NET, perché i tuoi microservizi non dovrebbero essere esposti direttamente al mondo esterno. Quindi a questo punto avresti una SOA simile, ma semplice nella progettazione, architettura, ma poiché avresti dei contratti ben definiti, potresti estendere i tuoi servizi aggiungendo loro delle capacità asincrone e per farlo inizieresti ad aggiungere una coda di messaggi a ciascuno dei servizi. Sai, non è necessario iniziare con un sistema complesso, iniziare con qualcosa di base, ben definito, che ti consente di ridimensionare se necessario.

Il sistema che ho descritto potrebbe essere esteso per supportare facilmente gli eventi se lo si desidera, e il fatto che a questo punto avresti già i messaggi di sincronizzazione non ti impedirà di aggiungere anche messaggi asyn al sistema.

Ma questi sono solo i miei due centesimi.