Facciata dell'API pubblica con Micro Services

Naviga le tue risposte
5

Considerare un'infrastruttura di servizi micro in cui ciascun servizio è responsabile di un insieme di attività e espone un'interfaccia RESTful alle sue funzionalità. Ad esempio, supponi un'applicazione di chat.

Potremmo avere un servizio responsabile della creazione di utenti e un secondo servizio responsabile della creazione di messaggi.

Ora vogliamo creare un'interfaccia REST pubblica per l'applicazione. Esistono buone pratiche per creare questa facciata pubblica per i micro servizi? Sono interessato a un paio di cose, principalmente:

  1. Quale livello deve gestire l'autenticazione / l'autorizzazione (se i servizi sottostanti - condividono questi dati o ciascuno implementa la propria autenticazione)
  2. Chiaramente in questa applicazione i messaggi vengono inviati dagli utenti agli utenti. Tuttavia, il servizio messaggi può essere facilmente scritto in modo tale da essere utilizzabile per qualsiasi cosa. Dovrebbe essere il proxy pubblico a determinare le informazioni dell'utente e quindi delegare a un servizio messaggi?
posta Colin M 06.09.2014 - 22:24
fonte

1 risposta

4

  1. Esistono due modelli di autorizzazione comuni: sottosistemi affidabili e delega.

    • Sottosistemi attendibili è un'architettura in cui la creazione dell'utente e amp; i servizi di creazione di messaggi si affidano all'applicazione API per eseguire l'autenticazione utente & autorizzazione. In questo modello, l'applicazione API è affidabile (tramite ACL di rete, token, certificati x509, ecc.) E può interagire con entrambi i servizi in una capacità illimitata.
    • Delega è un'architettura alternativa in cui l'API chiama il microservizio per conto dell'utente; in tale modello, sia l'API che l'amp; i microservizi gestiscono l'autorizzazione, con i microservizi che convalidano sia l'identità dell'applicazione API sia i reclami dell'utente che effettua la richiesta originale. L'API convalida che l'utente è autenticato e amp; autorizzato a fare la richiesta, mentre il microservizio "message" convalida che sia l'applicazione sia attendibile sia l'utente sia autorizzato a creare messaggi.

    Ci sono dei compromessi tra questi due approcci; i sottosistemi affidabili sono un'architettura più semplice da implementare, ma la delega consente funzionalità di sicurezza più avanzate. Per la tua applicazione, è molto più facile seguire la strategia del sottosistema fidato, quindi dovrei prendere in considerazione la possibilità di creare authn / authz sulla "facciata" dell'API (forse il gateway è una parola migliore qui?).

  2. MODIFICA: la risposta dipende in gran parte da ciò che il servizio messaggi sta facendo e da quali dati è richiesto per svolgere i suoi compiti. Se il servizio messaggi si limita a instradare i messaggi in tempo reale a websocket, i requisiti potrebbero essere diversi rispetto a se i messaggi vengono mantenuti su un database. In generale, tuttavia, è possibile che il servizio interagisca con gli ID utente senza essere direttamente accoppiato al servizio utente (ad esempio, memorizzando i messaggi in una tabella come sender_id, recipient_id e message).

Dai un'occhiata a questo post per ulteriori informazioni sulla delega e sui livelli di movimento .

    
risposta data 11.09.2014 - 23:52
fonte

Leggi altre domande sui tag

Come evitare "tipi di dispatcher" quando si lavora con SOLID Come introdurre il codice di Google Analytics in modo modulare?