Configurando un panorama di microservizi, la vista dovrebbe essere monolitica o essere collegata ai servizi di base?

3

Sto migrando la mia applicazione web monolitica a una basata su microservizi. Userò Spring Cloud e ho un servizio di discovery in cui sono registrati tutti gli altri servizi. Qui viene disegnato uno schema semplificato dell'architettura:

Entrambi i servizi Equipment e Task hanno la loro API HTTP RESTful. Si prendono cura di quali operazioni l'utente può eseguire in base ai ruoli, che sono memorizzati in un token OAuth2, che viene fornito da un server di autorizzazione OAuth2 appropriato.

Ora parliamo dei clienti. Per l' app nativa per dispositivi mobili , acquisisce un token dal server di autorizzazione per l'utente. Quindi, i servizi di base sono accessibili direttamente con quel token. Se l'utente finale tenta di eseguire un'operazione per cui non è stato concesso, verrà rifiutato, poiché la sicurezza viene implementata a livello di metodo API.

Per l'accesso al browser , avremmo potuto andare con AngularJS e accedere direttamente all'API REST principale, ma siamo un po 'inesperti e abbiamo scelto di implementare un terzo servizio che ospita Quadro JSF. Le viste saranno renderizzate da JSF, quindi il servizio di interfaccia utente deve parlare con i servizi di base in linguaggio JSON e analizzarlo su java (che è un gioco da ragazzi con la libreria di Jackson).

La decisione di rendere monolitico il servizio di interfaccia utente è che se vogliamo archiviare alcuni dati nella sessione del server, non avremo bisogno del clustering di sessione per condividerlo tra più UI-Services. Se vogliamo eseguire il ridimensionamento orizzontale, potremmo sempre attenerci al pattern session-in-one-instance.

Mi è stato anche detto di non implementare il servizio di interfaccia utente come separato, ma di integrarlo nei servizi di base. Poiché tutto è implementato in Java, in questo modo non dovrei occuparmi dell'analisi di JSON, ma potrebbe accoppiare strettamente l'interfaccia utente e la parte principale.

Qualche suggerimento a riguardo?

    
posta Xtreme Biker 05.02.2016 - 09:28
fonte

2 risposte

0

Sembra che tu abbia già un'interfaccia utente monolitica: l'app mobile nativa è il client dell'interfaccia utente e indipendente. Perché allora vorresti incorporare un'interfaccia utente basata sul web server all'interno dei servizi di base?

L'interfaccia utente del server web deve essere considerata come un altro client, proprio come la tua app nativa, quindi i servizi di base possono essere implementati senza alcuna considerazione per alcuna interfaccia utente, esistono semplicemente per servire qualsiasi UI li chiama e tutte le specifiche dell'interfaccia utente i pezzi sono ben disaccoppiati.

    
risposta data 09.02.2016 - 12:32
fonte
0

Come definito, il tuo 'UI Service' dovrà cambiare ogni volta che uno qualsiasi degli altri due servizi cambia. Questo è l'opposto di incapsulato, e non si ridimensiona man mano che aggiungi altri servizi.

E se non hai intenzione di ridimensionare a qualche decina di centinaia di servizi, probabilmente hai scelto un'architettura inappropriata per il tuo sistema.

Su questo punto, è particolarmente preoccupante che tu consideri di mettere le cose nello stesso processo di "accoppiamento"; questa è una di quelle idee leggermente sbagliate che rischia di finire con un monolite distribuito non gestibile. A volte, il modo migliore in cui due disaccoppiano due elementi interagenti è metterli nello stesso processo; quindi possono utilizzare l'API superiore della lingua madre e gli strumenti di gestione delle dipendenze invece di basarsi su un approccio REST semplicistico.

    
risposta data 09.02.2016 - 12:52
fonte

Leggi altre domande sui tag