Valore di Eureka nell'ambiente Cloud Foundry/PaaS?

Question

Stiamo lavorando ad un'applicazione cloud nativa da distribuire in Cloud Foundry e, dopo l'iniziale "usiamo tutti i gadget di Netflix", abbiamo iniziato a chiederci se la sovrapposizione con CF giustifica l'utilizzo dei componenti di Netflix.

Soprattutto nel caso di Eureka, stavamo progettando di utilizzarlo per l'individuazione dei servizi, ma la funzionalità molto simile è fornita immediatamente dalla CF e dalle rotte. Quello che ci mancherebbe è la registrazione dei servizi di runtime (che in caso di architettura che non cambia spesso non è una grande sfida e sarebbe in realtà una mappa statica di serviceID -> percorso CF) e heartbeat (a livello di app, dal Presumo sul livello del contenitore CF si sta accertando che tutto sia a posto).

Così ora mi chiedo: come lo usi nelle tue applicazioni (app di vita reale) quando usi CF? Quali sono i vantaggi di mantenerlo nell'architettura?

Grazie,

Leszek

PS. È interessante notare che se l'eureka memorizza la mappa semplice di serviceID -> CF route, allora se ho ragione, anche il valore di Zuul diminuisce (poiché LB sarebbe fornito da CF e gorouter è un'ottima opzione).

Answer 1

Eureka utilizza gli ID applicazione per eseguire il rilevamento dei servizi, che esiste solo nel contesto della progettazione dell'applicazione. Il routing Cloud Foundry utilizza gli URL per l'indirizzamento, che introducono una dipendenza dal codice sull'infrastruttura sottostante.

Se devo accedere a account-service, mi piacerebbe chiederlo con quel nome. L'URL per quel servizio sarà diverso a seconda che esegua il test sul mio computer locale, eseguendo un'istanza di QA distribuita o in esecuzione nella produzione. Non voglio che la mia app debba sapere dove è in esecuzione e quali URL mappano a quale ambiente. È probabile che tali URL possano cambiare nel tempo, comunque.

Se utilizzo Eureka, quindi chiedo il account-service e i problemi specifici dell'ambiente sono astratti dalla mia app.

Answer 2

Con la fonderia cloud abbiamo anche sentito che l'uso di eureka può essere eccessivo. ma abbiamo fatto una cosa per esternare e rendere noti i nomi del servizio. Avevamo bisogno inizialmente del servizio di configurazioni Spring per gestire la configurazione, ma sentivamo di poterlo usare anche come una fonte centrale di mappe di url di servizio. (il codice personalizzato doveva essere scritto per il caricamento da un'origine dati centrale).

Abbiamo creato un servizio di configurazione Spring con un datastore personalizzato che contiene molte cose come password, URL di servizio ecc. Usando cups, ci colleghiamo al servizio di configurazione Spring e il modello di configurazione contiene un set di token che poi viene tradotto in servizio url al volo.

Abbiamo bisogno del servizio di configurazione Spring inizialmente per gestire la configurazione, ma abbiamo ritenuto che potremmo usarlo come un URL di origine del servizio centrale (il codice personalizzato doveva essere scritto per essere caricato dall'origine dati).

La fonderia di cloud non dispone di porte IP e porte, quindi non è necessario tenere traccia dello stato di integrità di una singola istanza per il bilanciamento del carico. CF lo fa internamente abbastanza bene fuori dagli schemi. Quindi tutto ciò che serve è un'origine dati centrale per mappare il nome host.dominio con chiavi/token. es. membership.v1 = https://membership-1-0-2.

Ma se si desidera una singola transazione che consente a CF di chiamare il servizio ospitato in più data center, sarà necessario eureka o consul.io per superare tale problema. I cluster CF non si estendono su tutti i data center.