Esistono dozzine di soluzioni per l'esecuzione del servizio di rilevamento nell'ambiente Mesos.
Possiamo dividerli in 3 gruppi in base al modo in cui il cliente trova i servizi:
- Basato su proxy
- Quando tra client e servizio si trova un proxy, ad esempio HAProxy (basato su marathon-lb), fabio, traefik, nixy) che si occupa del bilanciamento del carico dei tuoi servizi in base al percorso HTTP, intestazione, dominio ecc. Questa soluzione è facile da sviluppare e offre l'opportunità di ottimizzare il bilanciamento del carico in base alla richiesta. D'altra parte aggiungiamo ulteriore hop e come proxy abbiamo la situazione MitM.
- DNSlike (chiedi a un endpoint noto speciale per la posizione del servizio)
- Rete definita dal software:possiamo utilizzare l'IP per container con SDN in modo che ogni container sia esposto con un IP univoco e presenti i suoi servizi utilizzando le porte predefinite 80 per HTTP, 443 per HTTPS e così via. Questa è la tecnica più avanzata e relativamente nuova, sebbene utilizzi un semplice DNS vecchio per trovare l'IP del servizio. Potrebbe essere più difficile introdurre il proxy, ma funzionerà con qualsiasi tipo di traffico.
- Record di servizio - in cui ogni contenitore è registrato nel DNS globale e il client ottiene il suo IP e PORT utilizzando le query DNS SRV. Consul Mesos DNS fornisce questo tipo di server DNS. Anche alcuni altri protocolli si basano su questa idea (dai un'occhiata a Bonjure). Cerca di ottenere il meglio da SDN e proxy. È relativamente facile da configurare ed è indipendente dal protocollo.
- Altro
- Tutto ciò che non rientra in altri tipi, ad es. soluzione sviluppata internamente, etcd o Eureka. Potrebbe essere molto stretto con l'infrastruttura e l'applicazione che forniscono alcune ottimizzazioni. Vale la pena ricordare che ci sono alcuni tentativi di utilizzare il servizio di rilevamento basato su DHT - Meta Service Discovery
Puoi trovare maggiori dettagli sugli strumenti che potrebbero essere utilizzati per creare il servizio Discovery qui
Possiamo dividere i Discovery Services in base al modo in cui sono popolati con voci di servizio:
- Collegamento
- Mesos/Marathon viene periodicamente interrogato sullo stato. Ecco come funziona Mesos DNS. Questo è il metodo più semplice, ma causerà un enorme ritardo tra l'avvio/arresto del servizio e le modifiche al rilevamento del servizio. Questo potrebbe essere ridotto al minimo utilizzando il controllo dello stato.
- Basato su eventi
- Marathon ha la capacità di inviare eventi con informazioni sui cambiamenti di stato (c'è un'iniziativa per includere anche il bus dell'evento int Mesos - design doc. In questo modo funziona maratona-lb. Un lavoro simile viene svolto da Marathon-consul ma i dati vengono passati a console.
- Nell'app/contenitore
- Le soluzioni di cui sopra sono asincrone, quindi potrebbe esserci un intervallo di tempo in cui lo stato di rilevamento del servizio non è aggiornato, ad es. il servizio è stato avviato ma non è pronto per soddisfare le richieste oppure il servizio è appena terminato. Anche con l'Healthcheck non possiamo presumere che tutte le cose accadano con 0 tempi di inattività. La soluzione per ridurre al minimo i tempi di inattività consiste nel consentire all'applicazione di registrarsi quando è pronta per soddisfare le richieste e di annullare la registrazione prima che si interrompa (ovvero arresto regolare).
