Come connettere applicazioni di microservice separate?

Question

Sto costruendo un'applicazione enorme utilizzando l'architettura dei microservizi. L'applicazione sarà composta da più microservizi di back-end (distribuiti su più istanze cloud), alcuni dei quali mi piacerebbe connettersi usando le rest apis per passare i dati tra di loro.

L'applicazione esporrà anche api pubbliche per terze parti, ma i suddetti endpoint dovrebbero essere limitati SOLO ad altri microservizi all'interno della stessa applicazione creando una sorta di rete privata.

Quindi, la mia domanda è:

come realizzare che limitato l'accesso API per altri microservices all'interno della stessa applicazione?

Se ci sono modi migliori per connettere i microservizi che utilizzare il livello di trasporto http, si prega di menzionarli.

Si prega di mantenere le risposte server/lingua agnostic se possibile.

Grazie.

Answer 1

Sì, facile. Ogni client di un micro servizio ha una chiave API. I servizi Micro accettano solo richieste da parte dei clienti con una chiave API valida.

Inoltre, è bene sapere che REST è semplicemente un protocollo che consente la comunicazione tra contesti limitati.

Non deve essere su HTTP. Il requisito è che abbia un'interfaccia uniforme (questo è il motivo per cui HTTP viene usato con i suoi metodi PUT, POST, GET, DELETE ...) e che è senza stato (tutto lo stato viene trasferito attraverso un URI).

Quindi, se tutti i servizi di micro eseguiti sulla stessa macchina, tutto quello che dovete fare è qualcosa di simile:

class SomeClass implements RestfulMethods { 

    public function get(params){ // return something} 
    public function post(params){ // add something} 
    public function put(params){ // update something} 
    public function delete(params){ // delete something} 
} 

servizi Micro poi comunicati interagendo con le implementazioni RestfulMethod di altri servizi.

Ma se i servizi micors sono su macchine diverse, è probabilmente meglio utilizzare HTTP come meccanismo di trasporto.

Answer 2

Il modo più semplice è abilitare l'accesso solo dall'indirizzo IP su cui sono in esecuzione i microservizi.

Answer 3

Un modo è utilizzare HTTPS per la comunicazione interna MS. Blocca l'accesso (utilizzando un negozio sicuro) solo ai tuoi servizi. È possibile condividere un certificato tra i servizi per le comunicazioni di back-end. Preferibilmente un certificato con caratteri jolly. Quindi dovrebbe funzionare finché i tuoi servizi possono essere indirizzati allo stesso dominio. Come * .tuaazienda.com.

Una volta che tutto è a posto, dovrebbe funzionare correttamente. Le sessioni HTTPS implicano un sovraccarico, ma questo è principalmente nel processo di handshake. Usando keep-alive nelle tue sessioni, non ci dovrebbero essere molti overhead con i canali criptati.

Naturalmente, è possibile aggiungere semplicemente alcune credenziali anche alle intestazioni http. Sarebbe meno sicuro.

Answer 4

RestAPI non è solo modo per farlo, uno dei alcune idee che ho apparenti è circa l'utilizzo di servizio Registro collegamento Eureka (Netflix), Zookeeper (Apache) e altri.

Ecco un esempio:

• https://github.com/tiarebalbi/qcon2015-sao-paolo-microservices-workshop

Answer 5

... i punti finali di cui sopra dovrebbe essere limitato solo ad altri microservices all'interno della stessa applicazione ...

Quello di cui si sta parlando in senso lato è l'autorizzazione.

L'autorizzazione è la concessione o la negazione di "poteri" o "abilità" all'interno della propria applicazione agli utenti autentici.

Quindi il lavoro di qualsiasi meccanismo di autorizzazione è di convalidare la "rivendicazione" implicita in qualsiasi richiesta API in entrata - che l'utente è autorizzato a fare la cosa codificata nella richiesta.

Per fare un esempio, immagino ho girato al vostro API con una richiesta PUT per Widget 1234:

PUT /widgetservice/widget/1234 HTTP/1.1 

Questo potrebbe essere interpretato come me (Bob Smith, un utente noto) effettuare un reclamo che io sono ha permesso di apportare modifiche a un widget nel vostro sistema con id 1234.

Qualunque cosa tu faccia per convalidare questa affermazione, spero che si può vedere questo deve essere fatto a livello di applicazione, piuttosto che a livello di API. Infatti, l'autorizzazione è una preoccupazione a livello di applicazione, piuttosto che una preoccupazione a livello di API (a differenza dell'autenticazione, che è è molto un problema di livello API).

Per dimostrare, nel nostro esempio di cui sopra, è possibile theoritically mi è permesso di creare un nuovo widget, ma non aggiornare un widget esistente:

POST /widgetservice/widget/1234 HTTP/1.1 

O ancora ho il permesso di aggiornare solo widget di 1234 e le richieste di cambiare altri widget non dovrebbe essere consentito

PUT /widgetservice/widget/5678 HTTP/1.1 

Come raggiungere questo limitato l'accesso API per altri microservices all'interno della stessa applicazione?

Così questo diventa una domanda su come si può costruire l'autorizzazione nella vostra applicazione in modo che è possibile convalidare le singole richieste provenienti da utenti conosciuti (nel tuo caso gli altri servizi nel vostro ecosistema sono solo un altro tipo di utente conosciuto).

Bene, e mi scuso, ma qui verrò prescritto, è possibile utilizzare un servizio di autorizzazione basato sulle attestazioni, che memorizza le attestazioni valide in base all'identità dell'utente o all'appartenenza ai ruoli.

Dipende in gran parte da come gestisci l'autenticazione e se stai supportando o meno i ruoli come parte di tale processo. È possibile archiviare i reclami nei confronti dei singoli utenti, ma questo diventa difficile man mano che aumenta il numero di utenti. OAuth, nonostante sia piuttosto pesante da implementare, è una piattaforma leader per questo.

sto costruendo enorme applicazione utilizzando microservices architettura

L'unica cosa che posso dire qui è leggere this prima.