Sarei attento a pensare di condividere un database con un altro servizio. Ogni volta che viene apportata una modifica al database, è ora possibile verificare che la modifica non influisca su nessun altro servizio che utilizza tale database. Sei tornato a fare rilasci monolitici in cui i test vengono eseguiti su ogni servizio per vedere se è possibile rilasciare. Questo verrà aggravato se il servizio è di proprietà di un altro team poiché le modifiche al database richiedono ora una comunicazione tra team che rallenta lo sviluppo e crea problemi di pianificazione, ecc.
Uno dei vantaggi di SOA e microservizi è che i confini sono a livello di API che rimane relativamente stabile tra le versioni. Ciò consente a un microservice di rilasciare individualmente senza la necessità di testare l'intero sistema. Avere un database separato per servizio consente a questo tipo di sviluppo di procedere.
In termini di integrità referenziale, dipenderà dal tuo dominio. Se l'integrità referenziale è mission-critical per la tua azienda, allora potrei proporre di trovare luoghi meno granulari per dividere il tuo monolitico. Ad esempio, potresti avere un servizio che rappresenta tutta la logica di dominio e le relazioni delle entità del dominio principale. Potresti avere servizi di supporto, come un servizio di posta elettronica, un servizio di autenticazione, ecc. Il tuo servizio di dominio potrebbe non essere "micro", ma se l'integrità referenziale è importante, non rischiare andando troppo granulare nella progettazione del servizio. p>
Se rilassate la vostra integrità referenziale per essere infine coerente / mantenuta, allora si apre un mondo completamente nuovo. È possibile disporre di servizi che costituiscono il sistema di registrazione per determinati concetti / entità di dominio e quindi denormalizzare i dati per query veloci in altre parti del sistema. Questa condivisione di dati richiede tempo per propagarsi, ma per la maggior parte dei domini non è un problema. Devi decidere se è ok mostrare o eseguire la convalida con questi dati eventualmente coerenti.
Se disponi di regole aziendali che devono essere eseguite andando a più servizi per essere convalidati ed eseguiti, il tuo dominio potrebbe non essere una buona scelta per SOA. Se invece la tua azienda rappresenta flussi di lavoro, in cui ogni servizio compie qualche passo in un flusso aziendale più ampio, questo sarebbe un caso d'uso molto migliore. Ho trovato che il posto migliore per rompere un monolite è in contesti limitati. A volte questi servizi finiscono per essere abbastanza grandi, ma è così che viene modellato il dominio. Sarà doloroso se diventerai troppo granulare poiché genererai un gran numero di richieste di rete per rispondere alle richieste o eseguire una manipolazione dei dati che richiede alcuni join nel tuo monolite. Inoltre, non avrai l'integrità referenziale in quanto potresti effettuare una chiamata per convalidare un record esistente in un altro servizio e farlo eliminare subito dopo il completamento della chiamata.
Modifica:
Un modo per mantenere la coerenza finale tra i record consiste nell'avere un processo che ricerca i record orfani o che collega i record insieme. È possibile fornire agli utenti un posto per pulire questi record orfani nell'interfaccia utente per consentire loro di agire. Al momento della query è possibile rilevare i problemi e informare l'utente per consentire loro di risolvere il problema.
È possibile utilizzare strumenti come rabbitmq o Kafka come meccanismo per servizi di condivisione di dati che alla fine saranno coerenti.
Ad esempio, potrei avere un archivio coerente di nomi completi dell'utente dal servizio utente nel mio servizio, in modo che non sia necessario interrogare costantemente il servizio utente per visualizzare il nome completo. Potrei ascoltare gli eventi che arrivano attraverso kafka dal servizio utente al fine di costruire il mio negozio alla fine coerente. Ora le ricerche complete sul nome sono veloci nel mio servizio al costo della duplicazione dei dati.
L'integrità qui sarà strong in quanto i nomi completi dell'utente probabilmente non cambieranno così spesso. Altri set di dati che cambiano molto potrebbero avere meno integrità in quanto la coda / kafka potrebbe essere dietro.
Ogni servizio che possiede un record è responsabile dell'integrità di quel record. Le relazioni con altri record dovranno essere più flessibili. Come servizio al consumatore di un record di un altro servizio, dovrai ascoltare e adattare i cambiamenti che si verificano al record all'interno del proprio servizio, poiché ha l'ultima parola sullo stato corrente del record.