Prima di iniziare a suddividere il tuo progetto, vorrei fare un'osservazione sui test di carico:

• Il limite di Tomcat è di circa 1.000-4.000 utenti simultanei al minuto, per una singola istanza
• Tomcat è il server Web predefinito per le app Spring Boot, a meno che non lo modifichi in modo specifico nel tuo POM.
• Aggiungendo semplicemente un'altra istanza con un servizio di bilanciamento del carico in primo piano è possibile aumentare il numero di utenti simultanei al minuto, presupponendo che il servizio sia veramente idempotente e non ci sono altre limitazioni

I tuoi limiti potrebbero essere il tuo server web, server di database, RAM, ecc. Assicurati di comprendere appieno la natura della limitazione della velocità. Il concetto di dividere la tua app di avvio primaverile in più app di avvio a molla (servizi micro o almeno più piccoli) non è una garanzia per migliorare le prestazioni. Stai introducendo una complessità che non hai adesso.

Is it correct to use a project with both domain and service layer, as a library?

Sì. In realtà non è raro avere il tuo livello di astrazione dei dati come una libreria e includerlo semplicemente come dipendenza.

Tuttavia, se si persegue l'obiettivo dei microservizi, è più comune che ciascun microservizio rimanga il più isolato possibile da altri servizi.

Is it correct to access the same database with more than one application?

C'è un po 'di dibattito su questo, ma in questo caso opterei per un approccio molto pragmatico, sì.

Se stavate iniziando un nuovo progetto di microservizi, potreste sostenere che database separati per servizio sono più corretti. Non sono personalmente così risoluto su questo, e nel tuo caso stai modificando un sistema legacy che funziona. Mantieni il più piccolo possibile i tipi di modifiche e le dimensioni delle modifiche, in modo da avere la speranza di essere terminato.

If not, what is the correct form of acessing data (read and write) from instances of an api project (to load balance)?

Onestamente, la salsa segreta alla capacità di scalabilità dell'architettura dei microservizi ha a che fare con la possibilità di far ruotare le istanze di servizio per soddisfare la domanda, e quindi farle roteare quando non ne hai più bisogno. Ciò ti consente di scalare su richiesta e di risparmiare, laddove possibile.

La differenza tra il microservizio in scala e un servizio monolitico ha a che fare con la granularità. Se è solo una piccola parte della tua app che viene martellata, puoi far ruotare il microservizio (i) che si riferisce a quella piccola parte invece dell'intera cosa.

C'è un'intera infrastruttura per monitorare e gestire i tuoi servizi, che aggiungono ulteriore complessità. Non ottieni qualcosa per niente.

Il fatto di voler riutilizzare un livello di servizio come libreria probabilmente significa che il modo in cui i servizi sono stati scomposti non era corretto. Ogni microservizio dovrebbe essere il proprio dominio. Il modello di dominio, supponendo che sia semplicemente DTO, potrebbe funzionare, ma espone un serio rischio di accoppiamento a lungo termine.

Sicuramente no, in questo modo è solo dolore e di nuovo punta alla scomposizione dei servizi che non si trovano lungo le linee di dominio corrette.

Se il servizio A vuole interagire con il servizio B, effettui chiamate Web.