RFC con l'attuazione di un'architettura modulare

Question

In cerca di pareri sulla modularizzazione di applicazioni web. Già la maggior parte delle applicazioni, indipendentemente dalla lingua hanno un backend DB e supporto tie-in con i loro rispettivi server di applicazioni Web (Apache, IIS, Lighttp, ecc), ma un sacco di sviluppatori che ho affrontato hanno problemi a venire a patti con l'utilizzo di Memcached o niente al di fuori di spazio di processo immediato del web app.

È modularizzazione di un'applicazione web come cosa buona una cosa come credo o c'è qualcosa che mi manca che causa tutti, da Sr. sviluppatori a CTO di essere riluttanti a spostare parti specifiche della logica di business dalla parte anteriore web fine e nei servizi di back-end specializzati?

Per esempio, qualche anno fa, mi hanno sparato verso il basso in un incontro progettazione di un sito web molto elevato traffico quando ho suggerito di strappare la logica ACL intensiva processo fuori del quadro front end e di trasformarlo in un servizio semi-in cluster applicazione nel backend. Per me i benefici era una separazione più pulita del codice e la possibilità di riutilizzare la logica ACL in più luoghi utilizzando REST / JSON come il ponte tra diciamo PHP e Python.

Gli sviluppatori che erano in disaccordo con la mia idea hanno sostenuto che era "troppo complicato", ma io non riuscivo a vedere come? I miei argomenti sono che, così come non ci può essere la zuppa di tag per il livello di presentazione, non ci può e spesso è una zuppa logica del codice che è così a maglie insieme che se un problema si pone potrebbe essere quasi impossibile effettuare una correzione "chirurgica".

Quindi, per ridurre il basso, quali sono del & o con Pro di rottura grandi applicazioni giù in processi indipendenti ma cooperativi (non thread o richieste sotto). MySQL, Memcache, simile processo di servizio sono grandi ... ma perchè non qualcos'altro? Come sta andando questa strada "troppo complicato"?

Answer 1

Beh, a volte "troppo complicato" significa "Non voglio pensare al di fuori della mia zona di comfort".

Il concetto di base suona bene --- si sta parlando di un'architettura orientata ai servizi abbastanza plausibile qui.

Ora, per quanto riguarda i pro ei contro, la prima cosa contro di esso è che fa , infatti, hanno per convincere la gente a pensare fuori delle loro zone di comfort. Una con più tecnica è che è necessario per preservare ciò che è, in effetti, lo stato della sessione. Diciamo che solleva il token di autenticazione dal vostro servizio di autenticazione; come è quella pedina intenzione di rimanere associato alla sessione utente corretto.

Un altro problema è che potrebbe essere più difficile da eseguire il debug, in quanto sta accadendo in modo più dinamico.

Dal punto di vista pro, però, se si può soddisfare la questione dello stato sessione, si ottiene un'architettura altamente scalabile; se avete bisogno di più il servizio, è possibile ingrandire il server o semplicemente aggiungere un altro server.

Answer 2

Io sono un fan di separare la logica di funzionalità di base del server / business dal codice dell'applicazione web. Questo è per diversi motivi:

1. È possibile controllare meglio la logica di business. Non ci sarà alcun modo per mescolare questo con il codice di interfaccia grafica e creare un pasticcio. Si desidera mantenere tutta la logica di business separata in modo da poter poi fare un'API per chiamare la funzionalità di codice e non sperare che nessuna logica di business ha fatto la sua strada nel codice della GUI.
2. Fin dal get-go è necessario progettare un buon API che si deve usare se stessi per comunicare con il server dal client. Il client può essere l'interfaccia web o può essere un utente remoto.
3. Stabilità. GUI codice web può essere facilmente scritta sbagliata e consumare troppa memoria prendendo in tal modo verso il basso l'intera applicazione.
4. Per scalare è possibile spostare questi componenti separati per server diversi. Se si utilizza un sistema di caching che consente già per il clustering scaling up può essere semplice come solo l'aggiunta di ulteriori server di caching.
5. Ho trovato che gli aggiornamenti delle applicazioni sono fatte più spesso per il codice della GUI in modo che il servizio di base non deve essere tirato giù la maggior parte del tempo.
6. Sicurezza. Si può essere sicuri che il codice di sicurezza è implementato nel codice del server quindi se qualcuno usa i tuoi API non saranno in grado di bypassare qualsiasi codice di sicurezza che ha fatto la sua strada nel codice della GUI.

Il nostro sistema dispone di un servizio di base 'motore' implementata come applicazione Java. L'applicazione web è anche scritto in Java e (attualmente) la comunicazione avviene tramite RMI. Il nostro sito / applicazione è in crescita e non abbiamo ancora dovuto iniziare a utilizzare un servizio di caching come memcached o JCS.