Prima di tutto mi dispiace per il titolo, non sapevo come spiegarlo. Quindi ecco che arriva la storia;
Siamo un gruppo di programmatori, front-end e back-end, e creeremo questo nuovo sistema, basato sull'architettura di micro-servizi per la nostra azienda. Quindi abbiamo già un paio di micro-servizi e la nostra attuale applicazione centrale (basata su symfony 1.4) sta comunicando con loro, tuttavia vogliamo eliminare questa vecchia applicazione centrale e crearne una nuova. Fondamentalmente abbiamo deciso di crearlo con uno dei famosi framework JS senza fare molto codice HTML. Ecco i dettagli sul sistema imminente / pianificato
- Ogni microservizio è protetto con OAuth2
- L'applicazione centrale è ovviamente responsabile per l'accesso e la gestione di token e richieste a questi micro-servizi.
Quindi puoi chiedere, OK, questo sembra buono ma qual è il problema? Il problema è questo,
(BE rappresenta gli sviluppatori di backend, FE rappresenta gli sviluppatori di frontend)
BE dice, 'OK ragazzi, non abbiamo bisogno di mettere il vostro codice di frontend in un contenitore (diciamo Spring MVC) e non abbiamo bisogno di gestire le sessioni ecc. perché voi ragazzi registrerete questo utente in via il nostro fantastico servizio OAuth2, manterrai il token con te e ogni volta che vorrai colpire quegli endpoint di micro-service aggiungerai quel token alla tua richiesta e il micro-servizio ti fornirà la risposta che desideri '
FE dice, "OK, ragazzi, perché non facciamo così, mettiamo il nostro codice JS negli ambienti MVC primaverili che eseguono la gestione delle sessioni e il login e agiscono come un ROUTER , router significa questo, il nostro codice JS conosce solo un endpoint in Sprint MVC e invia tutte le richieste a tale endpoint e quindi quell'endpoint funge da router e reindirizza le richieste a determinati endpoint di micro-servizio aggiungendo token, quindi JS non esegue "Devo preoccuparmi di tutte queste cose"
Quindi, diciamo, il nostro approccio ci darà alcuni vantaggi come
- Non abbiamo bisogno di gestire la sessione per macchine diverse, perché c'è un servizio di bilanciamento del carico di fronte ai server e più macchine dietro dobbiamo sempre mantenere sincronizzate le sessioni tra loro
- Dato che non dobbiamo inserire il tuo codice JS in un contenitore, non abbiamo bisogno di un server fisico in esecuzione sul cloud, possiamo solo mettere il tuo codice su S3 in un bucket e nessun auto-ridimensionamento e nessun costo del server
- Dato che si desidera utilizzare per creare un endpoint router per le chiamate JS che causerebbe un "Single point of failure", significa che se questo endpoint del router non funziona, il sistema completo non funzionerà affatto, ma se utilizziamo il JS statico puro anche se un micro-service fallisce, ma funzionerà ancora. '
I ragazzi FE prendono la loro occasione e rispondono,
- Prima di tutto il tuo approccio renderà pubblico il nostro codice sorgente
- Il tuo approccio renderà i nostri micro-servizi visibili a tutti, sappiamo che questi endpoint sono protetti tramite oauth2 ma che non fermerebbe gli attacchi DDOS
- Questo probabilmente finirà in un flusso di autenticazione più complesso
Ecco anche il modo in cui entrambi i team suggeriscono come un diagramma. In che modo vorresti che andassimo e la domanda più importante è PERCHE '?
Grazie per i tuoi suggerimenti.
