Ridimensionamento dell'approccio alla riprogettazione?

Non è chiaro per me che mettere ogni sito venditore sulla propria applicazione sia vantaggioso. In effetti, ho potuto vederlo causare un notevole peggioramento delle prestazioni, oltre alla complessità tecnica non necessaria. Suppongo che tu voglia seguire questo approccio perché sembra interessante, non perché abbia qualche tangibile beneficio prestazionale.

Ora, dare a ciascun venditore il proprio DB è probabilmente più vantaggioso e più facile da implementare. Allo stesso modo in cui hai un metodo di repository per inserire una nuova riga, puoi avere un metodo che inserisce nuove tabelle. Non è necessario progettare una meta-base contorta o altro; sqlserver, ect, ha già tutte le funzionalità necessarie. I DB specifici del venditore offrono molti vantaggi in termini di prestazioni, come evitare il blocco non necessario durante le transazioni, limitare il numero di righe in una singola tabella e consentire il ridimensionamento senza problemi di sincronizzazione costosi.

La tua attenzione dovrebbe essere la seguente:  1. minimizzare l'accesso alla memoria dell'app-server con richiesta incrociata.  2. Isolamento di funzionalità distinte.

Se non immagazzini cose nella memoria di sessione, diventa molto facile creare un server web aggiuntivo quando la domanda lo richiede.

Il modo classico per isolare funzionalità distinte consiste nell'avere webapp, lavori batch e database in esecuzione su server diversi. Le opzioni più avanzate possono includere la presenza di uno specifico server cert che si occupa della crittografia, di server di file / immagini di grandi dimensioni per il contenuto statico o di un server per le transazioni di vendita. Osservando le specifiche della tua applicazione, potresti trovare funzionalità ancora più isolabili.

Ci sono due modi per ridimensionare: scalare verso l'alto (verticale) e ridimensionare (orizzontale).

Scalare comporta il far sì che una singola macchina faccia di più, ad es. aggiungendo CPU o architettando il software in modo che esegua solo una gamma molto ristretta di funzioni.

Il ridimensionamento comporta l'architettura del software in modo che possa essere supportato da più macchine ("nodi") senza alcun impatto negativo sulla logica. Ad esempio, una serie di 10 server Web con codice identico può essere utilizzata con un bilanciatore del carico per aumentare la capacità di dieci volte.

Il ridimensionamento è generalmente superiore perché è possibile continuare a ridimensionare per sempre (è possibile aggiungere 10, 20, 100 nodi). Il ridimensionamento verticale generalmente avrà un limite rigido.

Quindi, in questo spirito, ti suggerirei di abbandonare l'idea di "un venditore, una sola applicazione" e invece mettere tutti i venditori su una sola applicazione, ma progettare l'applicazione in modo che possa essere eseguita in un ambiente con carico bilanciato su un numero di macchine. I passaggi di base per questo sono:

1. Elimina o controlla la dipendenza dallo stato specifico del processo (ad esempio le variabili di sessione mantenute in-proc). È possibile farlo rendendo l'applicazione stateless, offloadando lo stato in un server di stato separato (ad esempio AppFabric) o (in un pizzico) applicando il client vischiosità .

2. Il ridimensionamento del database tende ad essere la parte più difficile a causa del requisito di ACID . Per ridimensionare le tue app Web, ti consigliamo di ridurre il carico del database il più possibile.

3. Sviluppa per multi-tenancy in modo che i venditori possano tranquillamente coesistere sulla stessa applicazione mantenendo la loro indipendenza logica.