Stiamo costruendo una piattaforma web che incorpora più servizi, ognuno con i propri dati sottostanti. Questi servizi vengono creati indipendentemente seguendo i principi dell'architettura orientata ai servizi , ma effettuano transazioni con dati potenzialmente correlati. Stiamo valutando se questi servizi debbano condividere un grande database o ognuno abbia il proprio database. (Stiamo pianificando di utilizzare SQL Server 2008 Enterprise su un cluster Windows 2008.)

Alcuni dei vantaggi di ogni approccio che abbiamo già considerato includono:

Database singolo

• I dati correlati da servizi diversi possono essere associati da vincoli di chiave esterna
• Gli estratti analitici sono più semplici da scrivere e più veloci da eseguire
• In caso di disastro, è più semplice ripristinare la piattaforma in uno stato coerente
• Per i dati a cui fanno riferimento più servizi, è probabile che i dati memorizzati nella cache da un servizio vengano utilizzati poco dopo da un altro servizio
• L'amministrazione e il monitoraggio sono più semplici ed economici in anticipo

Database multipli

• Lavori di manutenzione, problemi hardware, violazioni della sicurezza e così via non incidono necessariamente sull'intera piattaforma
• Supponendo che ciascun database si trovi su un hardware separato, il ridimensionamento di più macchine offre maggiori vantaggi in termini di prestazioni rispetto al ridimensionamento di un grande

Dal punto di vista operativo, è più vantaggioso che ogni servizio in questa piattaforma ottenga il proprio database o che vadano tutti nello stesso database? Quali fattori chiave informano una risposta a questa domanda?

A mio avviso, il principale fattore di differenziazione dei veri sistemi SOA (rispetto alla pseudo SOA, sistemi più nuovi / distribuiti che stanno diventando onnipresenti) è che non dovrebbe esserci alcuna interazione tra servizi discreti. Laddove ciò viene raggiunto, qualsiasi applicazione composta da questi servizi può e deve essere costruita per tollerare il fallimento di qualsiasi parte coerente. Un errore riduce la funzionalità ma il servizio viene mantenuto.

In questo scenario è logico o obbligatorio separare il database sottostante per ciascun servizio. Se tuttavia hai servizi interdipendenti, c'è poco (forse niente) da guadagnare da una scissione.

Consiglierei di leggere siti come HighScalability.com che scavano nelle architetture adottate dai siti Web di tipo ininterrotto. Uno dei miei preferiti di recente è stata la storia della scimmia del caos di Netflix che è stata menzionata in Coding Horror .

Affrontare un paio di punti della tua domanda:

In caso di disastro, è più semplice ripristinare la piattaforma in uno stato coerente.

Questo è vero ma dovresti forse pensare a come disaccoppiare meglio questi servizi in modo che questo smetta di essere un problema. In alternativa, esistono metodi per garantire la sincronizzazione su più database, ad esempio i segni di transazione in SQL Server .

Per i dati a cui fanno riferimento più servizi, è probabile che i dati memorizzati nella cache da un servizio vengano utilizzati poco dopo da un altro servizio.

Le soluzioni di cache distribuita (memcached et al) potrebbero essere utili qui, ma violeresti i principi di indipendenza del servizio. Ciò sarebbe paragonabile ad avere due servizi che comunicano direttamente tra loro, o peggio che avere un servizio acceda a un archivio dati secondario, bypassando completamente l'interfaccia di servizio. Inevitabilmente i dati saranno correlati e saranno distribuiti tra i servizi dalla piattaforma di chiamata, le decisioni difficili tendono a riguardare quale servizio possiederà quali parti di dati. I siti StackOverflow o Programmers potrebbero essere in una posizione migliore per aiutare con i problemi SOA più generali.

Supponendo che ciascun database si trovi su un hardware separato, il ridimensionamento produce maggiori vantaggi in termini di prestazioni.

Certamente può essere più economico ridimensionare su più macchine con specifiche inferiori rispetto a ridimensionare una singola macchina. Tuttavia, i costi hardware inferiori possono essere ridotti nel costo totale di proprietà quando vengono presi in considerazione i costi soft di ulteriori sforzi di sviluppo e complessità operativa.

Se questo non è SOA e hai solo un caso in cui i servizi componenti di questa piattaforma vengono creati da diversi team / fornitori per motivi logistici, mantieni un singolo database e ignora completamente tutto quanto sopra! :)