Qual è il modo migliore per scalare un sistema CQRS?

Naviga le tue risposte
5

Nei mesi precedenti ho fatto molte domande sull'architettura di un'applicazione su cui sto lavorando. Grazie alle risposte, la progettazione architettonica è cambiata, infatti è stata semplificata come mostrato nel seguente grafico:

Internamente ho due servizi ( NOT WCF! ) che seguono i principi CQS. Significa che il servizio di query restituisce semplicemente le viste del database; mentre il servizio di comando ha un modello di dominio completo che contiene tutta la logica aziendale e repository per accedere al database (nessun meccanismo di eventi o altro schema complesso qui). Entrambi i servizi utilizzano lo stesso database. Questi servizi sono librerie di classi, NO servizi WCF, perché vengono utilizzati solo internamente quindi non ho bisogno del sovraccarico di WCF (non distribuire i tuoi oggetti, la prima legge di Martin Fowler).

Queste operazioni interne sono utilizzate dal sito MVC di ASP.NET e dal PartnerService. Questo servizio Partner è un servizio WCF che espone le funzionalità che vorrei essere esposto ai partner.

Se dovessi mai scalare a causa del traffico intenso, potrei aggiungere server web e / o migrare parti a un sistema CQRS completo (i miei contratti sono già stati progettati per questo).

Qualcuno vede qualche problema con questo?

Una cosa che vedo è che se la query o il servizio di comando cambia, questo influisce direttamente sul sito web e sul servizio partner, quindi devo distribuire le modifiche su entrambi. Ma non so se questo è un problema ...?

Ogni feedback è apprezzato! Grazie!

    
posta L-Four 06.09.2011 - 17:38
fonte

3 risposte

4

Penso che tu abbia un vincitore qui.

Hai diverse opzioni per il ridimensionamento (dal più semplice al più impegnativo).

  1. Acquista una macchina più grande.
  2. Esegui ogni componente sul proprio server.
  3. Esegui più server per ciascun componente (tranne per il database)
  4. Replica il database e gestisci le query "visitatori" dalla replica.
  5. Partizionare il database con "id membro" ed eseguire diverse istanze separate del database per servire quel gruppo di membri.

Se hai bisogno di scalare di più, sei "facebook" e puoi permetterti una riscrittura.

    
risposta data 07.09.2011 - 06:14
fonte
2

Una cosa che potresti fare per consentire un po 'più di flessibilità sul lato interrogativo delle cose, è definire i tuoi contratti con i punti di estensione. Fowler lo discute qui:

link

In sostanza ti consente di aggiungere proprietà che vengono esposte attraverso il servizio senza rompere i consumatori esistenti, quindi se il sito web ha bisogno di un'altra proprietà esposta, puoi fornirla attraverso il servizio senza interrompere il servizio partner.

"This allows the ProductSearch service to return results that include product descriptions, and consumers using the new schema to validate the entire document. Consumers using the old schema will not break, though they will not process the description."

L'intero articolo è una buona lettura dei servizi che si evolvono nel tempo.

    
risposta data 06.09.2011 - 18:01
fonte
2

L'unica domanda che vorrei è come il comando comandi elabora i tuoi comandi. Sono gestiti in modo asincrono o il client è in attesa del comando per elaborare il comando e completare la scrittura nel repository prima di restituire un ack / nack? Se stai cercando la scalabilità, quella potrebbe essere un'area su cui potresti concentrarti per migliorare la scalabilità.

Oltre a questo, ha un bell'aspetto in superficie.

Buona fortuna !!

    
risposta data 06.09.2011 - 20:47
fonte

Leggi altre domande sui tag

Accesso ai dati per applicazioni componibili Quali sono i vantaggi e gli svantaggi delle varie modalità git disponibili per emacs?