Es gibt Dutzende von Lösungen für die Durchführung von Erkennungsdiensten in der Mesos-Umgebung.
Wir können sie anhand der Art und Weise, wie Kunden Dienstleistungen finden, in 3 Gruppen einteilen:
- Proxy-basiert
- Wenn zwischen Clients und Dienst ein Proxy sitzt, z. B. HAProxy (marathon-lb basiert darauf), fabio, traefik, nixy), der sich um den Lastausgleich Ihrer Dienste kümmert, basierend auf HTTP-Pfad, Header, Domain usw. Diese Lösung ist einfach zu entwickeln und bietet die Möglichkeit, den Lastausgleich auf Anfrage anzupassen. Andererseits fügen wir zusätzlichen Hop hinzu und als Proxy haben wir die MitM-Situation.
- DNSlike (fragen Sie einen speziellen bekannten Endpunkt nach dem Standort des Dienstes)
- Software Defined Network – Wir können IP pro Container mit SDN verwenden, sodass jeder Container mit einer eindeutigen IP verfügbar gemacht wird und seine Dienste unter Verwendung der Standardports 80 für HTTP, 443 für HTTPS usw. präsentiert. Dies ist die fortschrittlichste und relativ neue Technik, obwohl sie das einfache alte DNS verwendet, um die Dienst-IP zu finden. Es könnte schwieriger sein, dann einen Proxy einzuführen, funktioniert aber mit jeder Art von Datenverkehr.
- Dienstaufzeichnung – wo jeder Container im globalen DNS registriert ist und der Client seine IP und seinen PORT mithilfe von DNS-SRV-Abfragen erhält. Consul Mesos DNS stellt diese Art von DNS-Server bereit. Auch einige andere Protokolle basieren auf dieser Idee (siehe Bonjure). Es versucht, das Beste aus SDN und Proxy herauszuholen. Es ist relativ einfach einzurichten und protokollunabhängig.
- Andere
- Alles, was nicht in andere Typen passt, z. intern entwickelte Lösung, etcd oder Eureka. Es könnte sehr eng werden, da Infrastruktur und Anwendung einige Optimierungen bieten. Es ist erwähnenswert, dass es einige Versuche gibt, den DHT-basierten Erkennungsdienst - Meta Service Discovery zu verwenden
Weitere Details zu Tools, die zum Erstellen des Discovery Service verwendet werden könnten, finden Sie hier
Wir können Discovery Services danach unterteilen, wie sie mit Diensteinträgen gefüllt sind:
- Pooling
- Mesos/Marathon wird regelmäßig nach dem Status abgefragt. So funktioniert Mesos DNS. Dies ist die einfachste Methode, verursacht jedoch eine große Verzögerung zwischen dem Start/Stopp des Diensts und Änderungen, die in die Diensterkennung gelangen. Dies könnte durch die Verwendung von Healthchecks minimiert werden.
- Ereignisbasiert
- Marathon hat die Fähigkeit, Ereignisse mit Informationen über Zustandsänderungen zu pushen (Es gibt eine Initiative, den Event-Bus int Mesos einzubeziehen – Design-Dokument. Auf diese Weise funktioniert Marathon-lb. Eine ähnliche Arbeit wird von Marathon-Consul erledigt, aber Daten werden an weitergeleitet Konsul.
- In App/Container
- Die obigen Lösungen sind asynchron, daher kann es eine Zeitspanne geben, in der Ihr Diensterkennungsstatus veraltet ist, z. Der Dienst wurde gestartet, ist aber nicht bereit, Anforderungen zu bedienen, oder der Dienst ist gerade gestorben. Selbst mit Healthcheck konnten wir nicht davon ausgehen, dass alle Dinge mit 0 Ausfallzeiten passieren. Die Lösung zur Minimierung der Ausfallzeit besteht darin, die Anwendung sich selbst registrieren zu lassen, wenn sie bereit ist, Anforderungen zu bedienen, und die Registrierung aufzuheben, bevor sie beendet wird (auch bekannt als ordnungsgemäßes Herunterfahren).
