Sono l'autore dell'articolo
Il contesto per il post è in realtà intorno a sistemi distribuiti e in particolare architetture orientate ai servizi (SOA). Le soluzioni vengono solitamente utilizzate da fornitori di servizi software (SaaS) di grandi dimensioni, in cui dispongono di numerosi servizi di back-end utilizzati per fornire la propria offerta di servizi.
Ad esempio, molti provider SaaS hanno un modo per accedere al proprio sistema. In un SOA, potresti avere un servizio di autenticazione nel back-end che gestisce le richieste di accesso. È abbastanza comune avere un livello web di fronte a quei servizi di backend che effettivamente servono la pagina di login e gestisce le richieste HTTP di accesso. Quel livello delegherebbe la richiesta di accesso al servizio di autenticazione. Può anche delegare altre funzioni ad altri servizi nel back-end. Questi backend potrebbero fornire un'API basata su HTTP o qualcos'altro ma è comunemente un servizio distribuito su più host.
Why can't you put a web service in front of everything?
Puoi e questo è fatto comunemente. L'aspetto della scoperta del servizio arriva quando provi a mantenere http://my-data-service.example.com puntando agli host giusti quando i servizi non funzionano, non stanno funzionando, sono aggiornati, scalati, ecc.
Se my-data-service.example.com è solo una voce DNS round robin, e hai tre istanze che forniscono il servizio e una scende, avrai alcune richieste non riuscite mentre quell'host viene riportato in linea. Con DNS, anche i TTL devono essere presi in considerazione in modo che i client che hanno memorizzato nella cache tali voci continuino a provare l'host abbattuto fino alla scadenza dei TTL e all'aggiornamento. Se aggiungi degli host, dovrai aspettare che scadano anche i TTL prima che inizi a servire le richieste.
Un'alternativa è puntare my-data-service-example.com su un bilanciatore del carico o fare in modo che le applicazioni client implementino il bilanciamento del carico stesso.
Questo presenta un nuovo problema:
How do you keep the backend hosts configured in your load balancer up to date?
In un ambiente come AWS, gli host possono essere spostati su e giù frequentemente e i loro IP possono cambiare. Se si utilizza la finestra mobile, gli IP e le porte di solito sono diversi quando viene avviato un nuovo contenitore. Cercare di mantenere questo configurato manualmente non è generalmente possibile in questi tipi di ambienti ... specialmente quando si hanno più servizi e centinaia o migliaia di host.
Per mantenere un bilanciamento del carico automaticamente aggiornato, è necessaria una qualche forma di rilevamento dinamico dei servizi.
Questo di solito comporta avere:
- Un registro per tenere traccia di ciò che è su / giù, le sue posizioni, ecc.,
- Una procedura di registrazione per registrare i percorsi dei servizi quando sono online
- Un processo discovery per scoprire servizi e mantenere aggiornate le informazioni di routing.
L'articolo originale descrive come diverse aziende hanno implementato tali componenti in modi diversi. Ci sono molti altri modi per farlo.
Per un esempio più concreto, ho scritto un altro post che mostra un modo di fare discovery dei servizi con la finestra mobile usando etcd e haproxy . Potrebbe essere utile capire il contesto dell'articolo.