Perché stai cercando di scomporre i componenti del servizio?
A meno che l'applicazione non abbia problemi di inserimento nella memoria, davvero non vuoi farlo. Sul serio. La comunicazione tramite RPC (in particolare se si utilizza XML per la serializzazione) aggiunge un sacco di overhead rispetto alle chiamate ai metodi semplici, che costano un sacco di prestazioni. Inoltre aggiunge un po 'di complessità che rende i problemi di debug molto più difficili. Ho visto gli interni dei siti Web che lo hanno fatto senza una buona ragione, ed è sorprendente quanti problemi di scalabilità siano stati creati senza alcun guadagno. (Ho visto anche gli interni di un noto sito Web che lo ha fatto per un'ottima ragione con ottimi risultati, e sono consapevole di quanta disciplina costante hanno bisogno per impedirle di trasformarsi in un disastro completo. le organizzazioni possono gestirlo.)
Ovviamente dovresti assicurarti che il tuo codice sia modulare con API ben definite, in modo che sarebbe semplice scambiare un'implementazione locale o remota dell'API. Questo è solo un buon design del software. Ma in realtà non farlo fino a quando non è necessario perché la tua applicazione ha problemi di adattamento in memoria ..
Ma quello che devi davvero fare invece è assicurarti di essere scalabile orizzontalmente. Ciò significa che è possibile eseguire più server Web contemporaneamente. E più server di app contemporaneamente. Ma è OK per ciascuno di essere integrato verticalmente.
Per quanto riguarda il database, ci sono diverse strategie comuni per il ridimensionamento che quando raggiungi i limiti. Usa qualsiasi combinazione di questi che abbia senso per la tua applicazione:
- Aggiungi livelli di memorizzazione nella cache (ad esempio memcached) per evitare di dover andare sempre nel database.
- Aggiungi gli slave di sola lettura del tuo database a cui puoi indirizzare alcune query di sola lettura.
- Ottieni un database più grande. (Saresti stupito di quanto puoi scalare il database.) L'ultima volta che ho sentito, tutto di PayPal viene eseguito su un unico enorme database Oracle.)
- Shard i tuoi dati. Sharding data significa che puoi avere più database master, perché ognuno ha solo una parte dei tuoi dati.
- Esamina le soluzioni NoSQL che rilassano le garanzie di coerenza del database in cambio di una scalabilità orizzontale semplice. Vedi link per un rapido confronto tra diverse di queste opzioni.