¿Qué es el Service Discovery en Microservicios?

¿Qué es la Descubrimiento de Servicios? ¿Por qué lo necesitas?

En los primeros días de Internet, las personas tenían que ingresar una larga cadena de direcciones IP para acceder a un servicio en línea. Las direcciones IP no eran largas, pero como una cadena de números sin sentido, era un desafío recordar la dirección específica de un servicio en particular, lo que llevó a la invención del sistema de nombres de dominio. Cada servicio en línea registraba un nombre de dominio con un proveedor de nombres de dominio y luego establecía un enlace entre el nombre de dominio y una IP específica a través del DNS (Sistema de Nombres de Dominio). De esta manera, las personas podían simplemente escribir un nombre de dominio memorable y acceder al servicio en línea en una IP específica, lo que era la forma más temprana de descubrimiento de servicios.

Cuando el número de servicios dentro de una empresa alcanza un cierto tamaño (por ejemplo, divididos en microservicios), también existe el problema de que las IP son realmente difíciles de recordar, para lo cual se necesita un sistema de descubrimiento de servicios. Los servicios dentro de la empresa se registran en el sistema, y otros servicios que desean acceder a ellos buscan la dirección IP correspondiente en el sistema, de modo que no es necesario que un servicio "recuerde" una dirección IP compleja y variable.

Los cambios de dirección IP pueden confundir a los visitantes.

Al introducir DNS como un mecanismo de descubrimiento de servicios, los cambios de IP ahora pueden manejarse de manera flexible.

Introducción a los Sistemas Comunes de Descubrimiento de Servicios

Como sistema de descubrimiento de servicios, necesita satisfacer al menos cuatro funciones:

1. API para registro
2. API para consulta
3. Alta disponibilidad: después de todo, el sistema de descubrimiento de servicios es el nervio de todo el sistema y no puede paralizarse o fallar
4. Ecosistema: como todos sabemos, los programadores son perezosos y preferirían tener una biblioteca que pueda interactuar fácilmente con las API

Echemos un vistazo a algunos sistemas de descubrimiento de servicios de código abierto principales en el mercado:

Consul

Consul es un sistema de descubrimiento de servicios desarrollado por Hashicorp, una empresa líder en código abierto. Como un software de larga data que lanzó su primera versión el 17 de abril de 2014, Consul tiene uno de los ecosistemas más ricos e incluso tiene desarrolladores de terceros que desarrollan SDK de Haskell para él. La mayoría de los SDK de Consul son solo un envoltorio para su API HTTP, por lo que no hay mucho trabajo de desarrollo.

Consul admite el registro y la consulta de servicios a través de la API HTTP. Admite HTTP long polling para la entrega oportuna de datos durante las consultas para evitar el sondeo. Además, Consul admite la consulta de la instancia del servicio correspondiente a través de DNS.

El despliegue de Consul es interesante en que cada instancia de Consul se llama un agente, que puede ser un cliente o un servidor. En el lado del cliente, Consul mantiene un estado del lado del cliente; en el lado del servidor, Consul admite el despliegue distribuido a través del algoritmo de consistencia Raft, para lograr alta disponibilidad.

Eureka

Eureka es un proyecto de código abierto de Netflix, que también es bastante antiguo (hay rastros de commits que datan de 2012). Sin embargo, el proyecto no se ha mantenido durante un año. Muchos usuarios han migrado a Nacos, que se mencionará a continuación.

Eureka admite la interacción a través de la API HTTP y el SDK de Java. Muchos de los usuarios de Eureka fueron traídos a través de proyectos en el ecosistema de Java, como Spring Cloud. El diseño de alta disponibilidad de Eureka, si quieres describirlo en términos de CAP (El teorema CAP establece que un sistema distribuido solo puede proporcionar dos de tres propiedades simultáneamente: Consistencia, Disponibilidad y Tolerancia a Particiones), es AP, lo que permite a los clientes ver datos caducados cuando las particiones de red ocurren, evitando desastres secundarios debido a problemas de red.

Nacos

Nacos es un sistema de descubrimiento de servicios desarrollado por Alibaba, cuyo nombre proviene de la agregación de las primeras letras de Naming and Configuration Service. Desde el lanzamiento de la versión 0.1.0 el 20 de julio de 2018, Nacos ha evolucionado ahora a la versión 2.1.

Como muchos de los proyectos de código abierto de Alibaba, Nacos es bastante popular entre los desarrolladores de Java en China, y su popularidad es incluso bastante mayor que la de Eureka.

Admite el registro y la consulta de servicios a través de la API HTTP y SDK como Java/Go/Python/NodeJS/C#. Actualmente, los desarrolladores de Nacos también están trabajando en nuevas API basadas en gRPC. Para la API HTTP, Nacos actualmente solo admite el sondeo para una lista de servicios. Por lo tanto, Nacos prefiere oficialmente el enfoque del SDK, que es un enfoque de sondeo + push basado en UDP con mejor rendimiento en tiempo real. Nacos también está trabajando en nuevas API basadas en gRPC, que introducirán capacidades de push del lado del servidor, un gran beneficio para aquellos sistemas que no tienen acceso al SDK.

La alta disponibilidad de Nacos se debe en parte a las capacidades de persistencia proporcionadas en el SDK del cliente, y en parte a la consistencia del lado del servidor a través de los protocolos Raft y Distro.

Métodos Comunes de Interfaz y sus Ventajas y Desventajas

Dejando de lado los protocolos privados, los métodos de interfaz de descubrimiento de servicios se pueden dividir en tres categorías:

1. Sondeo HTTP
2. DNS
3. HTTP long polling o streaming de servidor gRPC

El sondeo HTTP es simple de implementar pero no es en tiempo real.

El sobrecosto de rendimiento de DNS es mínimo. DNS tampoco es en tiempo real debido al caché de DNS, y tiene la ventaja de ser un conjunto de estándares ampliamente aceptados e independientes de la implementación. Sin embargo, hay dos caras de la moneda, lo que significa que el sistema de descubrimiento de servicios no puede agregar campos adicionales a la respuesta de DNS a menos que se use el campo Additional en la respuesta de DNS, pero esto requeriría un manejo especial por parte del cliente.

HTTP long polling o streaming de servidor gRPC es el más en tiempo real de los tres. Dado que ambos están basados en HTTP, la respuesta se puede personalizar fácilmente. La desventaja es que son relativamente difíciles de implementar en el lado del cliente.

Cómo APISIX se Interfaz con los Sistemas de Descubrimiento de Servicios

Como una puerta de enlace nativa de la nube, APISIX admite la obtención de nodos ascendentes del sistema de descubrimiento de servicios y está diseñado para admitir la interfaz con el sistema de descubrimiento de servicios tanto en el plano de datos como en el plano de control.

Plano de Datos

APISIX admite la integración con DNS, Eureka, Consul (modo KV), Nacos y K8s en el plano de datos.

Cuando se interconecta con servicios DNS, APISIX usará los registros SRV o A/AAAA de DNS para obtener el nodo ascendente específico de un servicio. Cuando se realiza una solicitud para acceder al ascendente, primero intentará obtenerlo del caché de DNS. Si no, iniciará una consulta de DNS para obtener la dirección IP específica dentro del registro correspondiente.

En cuanto a los otros tipos de descubrimiento de servicios, se sincronizan en segundo plano. Cuando se realiza una solicitud para acceder al ascendente, se obtiene la parte de los datos correspondientes al nombre del servicio de los datos actualmente sincronizados. Para K8s y Consul KV, podemos obtener la dirección IP cambiada en tiempo real de esta manera, ya que admiten HTTP long polling. Para Eureka y Nacos actualmente solo estamos sondeando datos.

Plano de Control

APISIX también admite el descubrimiento de servicios en el plano de control. Estamos trabajando en apisix-seed, que sincronizará datos del sistema de descubrimiento de servicios a etcd para que el plano de datos pueda sincronizar los últimos nodos ascendentes de etcd.

Ahora hemos implementado soporte para Nacos y Zookeeper en el plano de control. Dado que el soporte de descubrimiento de servicios en el plano de control se implementa a través del SDK oficial, tiene ventajas que no están disponibles con el método HTTP normal. Por ejemplo, en la implementación de Nacos en apisix-seed, admitimos el push basado en UDP, por lo que los datos son más eficientes en tiempo que el sondeo HTTP.

Ventajas del Soporte de APISIX para Escenarios de Descubrimiento de Servicios

Al integrar el descubrimiento de servicios directamente en la puerta de enlace, puedes simplificar enormemente la carga de trabajo de poner tus servicios en línea. Configura APISIX para que se interconecte con tu sistema de descubrimiento de servicios y luego deja que APISIX haga el resto por ti. Por ejemplo, si tu empresa está utilizando Nacos como un sistema de descubrimiento de servicios, todo lo que necesitas hacer es configurar APISIX para habilitar el descubrimiento de servicios de Nacos y luego simplemente configurar el nombre del servicio ascendente de APISIX y APISIX obtendrá automáticamente el nodo IP específico que corresponde a ese ascendente.

Esta es una ventaja que puede reducir significativamente la cantidad de trabajo requerido al migrar una puerta de enlace, por ejemplo, de Spring Cloud Gateway a APISIX. Si Spring Cloud Gateway se usa para aplicar Eureka o Nacos para el descubrimiento de servicios, la transición al nuevo sistema se puede hacer simplemente habilitando el soporte para Eureka o Nacos dentro de APISIX.

Huan Bei Loan tiene una amplia experiencia en esta área, y el reemplazo de Spring Cloud Gateway tiene la intención de mejorar aún más la estabilidad, supervisión, precisión y efectividad.

Para citar el texto original de Huan Bei Loan:

Como negocio, el costo sigue siendo el principio a considerar. En la fase de crecimiento salvaje, puede ser necesario impulsar el crecimiento del negocio lo más rápido posible. Sin embargo, en el entorno actual, la prioridad es definitivamente el costo dentro del presupuesto. En este caso, la eficiencia y el costo solo pueden preservarse de una manera u otra. Entonces, con costos limitados, las empresas hablarán menos sobre el avance tecnológico. En el proceso de selección, el personal técnico considerará menos cuánto impacto tendrá la tecnología que elijan en el equipo, cuánto beneficio traerá a las operaciones y arquitectura existentes, etc., pero más desde la perspectiva del costo.

Además, APISIX admite la configuración simultánea de múltiples descubrimientos de servicios. Muchas empresas, por razones históricas, pueden tener múltiples sistemas de descubrimiento de servicios. Por ejemplo, por lo que sé, algunas empresas tendrán tanto el antiguo descubrimiento de servicios de Eureka como el nuevo descubrimiento de servicios de Nacos. APISIX simplemente necesita habilitar tanto Eureka como Nacos para hacer frente a esta situación.

Si actualmente estás configurando nodos ascendentes directamente en APISIX, también puedes considerar implementar un sistema de descubrimiento de servicios separado y hacer que el sistema de descubrimiento de servicios almacene la configuración específica del nodo. El beneficio de mover la configuración del nodo ascendente, desde APISIX, a un sistema de descubrimiento de servicios dedicado es que el cliente puede hacer el registro del servicio por sí mismo, y el sistema de descubrimiento de servicios dedicado a menudo proporciona funcionalidad adicional, como controles de salud más ricos.

En el futuro, también admitiremos la integración de varios componentes de registro y descubrimiento de servicios en el APISIX Ingress Controller para que sea más fácil de usar para los usuarios. En ese momento, los usuarios no solo podrán especificar los puntos finales del servicio K8s como nodos ascendentes en APISIX Ingress Controller, sino que también podrán integrar los nodos obtenidos por descubrimiento de servicios.