Autonomia dei microservizi

I microservizi basati sulle richieste non possono essere autonomi. Esse dipendono da altri servizi per definizione e presentano i problemi di accoppiamento standard. Per esempio. non può essere distribuito in isolamento.

I microservizi basati su eventi possono essere autonomi. Ecco come funziona. Ogni microservizio pubblica eventi di livello aziendale importanti (ad esempio OrderPlaced, PaymentRejected, ecc.) In un database di streaming condiviso. Ogni microservizio sottoscrive gli eventi a cui tiene e li trasforma nella propria copia locale dei dati di cui ha bisogno. Esempio: l'ordine riceve l'evento CustomerAdded e aggiorna la propria copia locale della tabella clienti, separata da quella conservata dal cliente. Successivamente, quando il Cliente aggiunge un nuovo evento che potrebbe corrispondere ai nuovi dati in una delle sue tabelle, l'Ordine non deve saperlo / curarsene per continuare a svolgere il proprio lavoro. Esiste una duplicazione dei dati, ma una separazione delle preoccupazioni.

Per far sì che ciò accada è necessario un database di streaming. Un database di streaming comune che vedo menzionato per questo è Kafka, che è distribuito, scalabile e tollerante ai guasti. (E molto lavoro da fare.) Su una scala più piccola (normale?), Potresti usare qualcosa come EventStore o Postgres con la tua logica su LISTEN / NOTIFY.

Hai anche bisogno di contratti definiti (vale a dire la struttura che ogni ascoltatore può aspettarsi) per ogni tipo di evento. Ho visto Avro menzionato per questo, e probabilmente qualsiasi schema standard funzionerebbe finché tutte le squadre potessero accedervi. O meglio ancora, prendi una biblioteca e usala. Questa è un'API in sé e per sé, quindi è necessario prendere in considerazione il controllo delle versioni.

I microservizi basati su eventi possono consentire a più team di distribuire continuamente e senza dipendere in gran parte da altri team. Ma se è una squadra unica, la proposta di valore dei microservizi è molto meno, soprattutto a causa dei costi operativi. Seguendo un buon design, un monolite può spesso essere una soluzione migliore per il piccolo e può essere ridimensionato ai microservizi man mano che cresce.

Se i tuoi servizi sono chiacchieroni e hanno bisogno dei reciproci dati, probabilmente questo significa che i loro limiti sono errati.

Per raggiungere l'allineamento Business-IT, è necessario riflettere sulla propria architettura aziendale prima di definire i servizi tecnici. Può essere definito con tecniche di analisi della capacità o della catena del valore . A breve, dovresti considerare i principali passaggi che la tua attività svolge per ottenere il suo valore aziendale. In altre parole, queste sono le funzionalità di livello superiore della tua azienda. Il cliente effettua l'ordine, il cliente paga e l'ordine viene consegnato: questi sono i passaggi principali nell'e-commerce. Questi passaggi sono completamente autonomi, non richiedono a nessun altro di conoscere le loro specifiche. Comunicano solo con eventi. Questi sono i confini con i quali dovresti allineare i tuoi servizi tecnici.

Quindi, anziché i servizi Product, Customer e Order, dovresti avere un servizio di vendita che ha tutti i dati necessari per accettare l'ordine.

E sii consapevole della duplicazione dei dati proposta da Kasey Speakman. Di solito segue la duplicazione delle funzionalità. Di alcune librerie comuni vengono estratti, trasformando il sistema distribuito in un monolito distribuito . Fondamentalmente, gli eventi dovrebbero essere utilizzati per notificare che qualcosa è successo, portando non più dell'identità di qualche entità.

Ecco un esempio che indirizza questo dominio in maggior dettaglio.