Risposta.

La minimizzazione del coupling tra microservizi è uno dei principi principali dell'architettura moderna. Questo si ottiene attraverso l'interazione asincrona (tramite code di messaggi o bus di eventi), evitando chiamate HTTP sincrone dirette senza necessità e definendo esplicitamente i contratti API.

Un modo popolare è utilizzare broker di messaggi (RabbitMQ, Kafka, NATS), dove i microservizi pubblicano eventi sul loro stato e gli abbonati reagiscono a questi eventi.

Esempio di pubblicazione e gestione di eventi in Kafka su Node.js:

// producer.js
const { Kafka } = require('kafkajs')
const kafka = new Kafka({ clientId: 'order-service', brokers: ['kafka01:9092'] })
const producer = kafka.producer()
await producer.connect()
await producer.send({ topic: 'orders', messages: [ { value: JSON.stringify({orderId: 123}) } ] })
await producer.disconnect()

// consumer.js
const consumer = kafka.consumer({ groupId: 'payment-group' })
await consumer.connect()
await consumer.subscribe({ topic: 'orders', fromBeginning: true })
await consumer.run({ eachMessage: async ({ topic, partition, message }) => {
  const order = JSON.parse(message.value.toString())
  // gestione dell'ordine
}})

Caratteristiche chiave:

• I microservizi comunicano tramite API formalizzate o un intermediario (coda, bus)
• Ogni servizio ha il proprio database (Database per Servizio), per evitare lock e concorrenza
• Possibile aggiungere nuovi servizi al volo senza modificare gli esistenti

Domande trabocchetto.

Domanda: È possibile utilizzare un database comune per più microservizi se si tratta di un grande progetto?

No, ciò viola il principio di indipendenza, porta a tight coupling, e peggiora la scalabilità e la manutenibilità. È necessario utilizzare database separati o schemi.

Domanda: È una pratica accettabile l'interazione HTTP sincrona tra servizi durante la scalabilità del sistema?

Le richieste HTTP sincrone si scalano male e possono diventare un collo di bottiglia. Si raccomanda di applicare meccanismi asincroni e di ricorrere a chiamate sincrone solo in caso di assoluta necessità.

Domanda: È possibile scalare un microservizio solo aumentando il numero delle sue istanze, senza cambiare l'architettura del sistema?

No, un semplice aumento del numero delle istanze non risolve i problemi di coupling o collo di bottiglia nell'architettura. È necessaria un'analisi dei collo di bottiglia, l'implementazione di code, caching e la separazione delle responsabilità dei servizi.