Der er dusin løsninger til at udføre opdagelsesservice i Mesos-miljøet.
Vi kan opdele dem i 3 grupper ved, hvordan klienten finder tjenester:
- Proxy baseret
- Når der sidder proxy mellem klienter og service, f.eks. HAProxy (marathon-lb er baseret på det), fabio, traefik, nixy), der tager sig af belastningsbalancering af dine tjenester baseret på HTTP-sti, header, domæne e.t.c. Denne løsning er let at udvikle og giver mulighed for at justere belastningsbalancering efter ønske. På den anden side tilføjer vi yderligere hop, og som en proxy har vi MitM-situation.
- DNSlike (spørg et særligt velkendt slutpunkt om tjenestens placering)
- Softwaredefineret netværk - vi kan bruge IP pr. container med SDN, så hver container eksponeres med unik IP og præsenterer sine tjenester ved hjælp af standardporte 80 for HTTP, 443 for HTTPS og så videre. Dette er den mest avancerede og relativt nye teknik, selvom den bruger almindelig gammel DNS til at finde service-IP. Det kan være sværere at introducere end proxy, men vil fungere med enhver type trafik.
- Servicepost - hvor hver container er registreret i global DNS, og klienten får sin IP og PORT ved hjælp af DNS SRV-forespørgsler. Consul Mesos DNS leverer denne type DNS-server. Også nogle andre protokoller er baseret på denne idé (tag et kig på Bonjure). Den prøver at få det bedste ud af både SDN og proxy. Det er relativt nemt at konfigurere, og det er protokolagnostisk.
- Andet
- Alt, der ikke passer ind i andre typer, f.eks. egenudviklet løsning, etcd eller Eureka. Det kan være dybt stramt med infrastruktur og applikation, der giver nogle optimeringer. Det er værd at nævne, at der er nogle forsøg på at bruge DHT-baseret opdagelsestjeneste - Meta Service Discovery
Du kan finde flere detaljer om værktøjer, der kan bruges til at oprette Discovery Service her
Vi kan opdele Discovery Services efter den måde, de er udfyldt med serviceposter på:
- Samling
- Mesos/Marathon bliver med jævne mellemrum forespurgt om tilstand. Sådan fungerer Mesos DNS. Dette er den nemmeste metode, men vil forårsage stor forsinkelse mellem servicestart/stop, og ændringer bliver opdaget. Dette kan minimeres ved at bruge sundhedstjek.
- Begivenhedsbaseret
- Marathon har evnen til at skubbe begivenheder med information om tilstandsændringer (der er initiativ til også at inkludere begivenhedsbus int Mesos — designdokument. På denne måde fungerer marathon-lb. Lignende arbejde udføres af marathon-konsul, men data sendes til konsul.
- I app/container
- Ovenstående løsninger er asynkrone, så der kan være et tidsrum, hvor din serviceopdagelsestilstand er forældet, f.eks. tjenesten er startet, men er ikke klar til at betjene anmodninger, eller tjenesten er lige død. Selv med healtcheck kunne vi ikke antage, at alle ting sker med 0 nedetid. Løsningen til at minimere nedetid er at lade applikationen registrere sig selv, når den er klar til at betjene anmodninger, og afregistrere, før den stopper (også kaldet yndefuld nedlukning).