etcd: descripción general

Tabla de contenido

etcd

etcd es un proyecto de código abierto desarrollado con Golang iniciado por el equipo de CoreOS en junio de 2013. Basado en el algoritmo de coherencia fuerte de Raft, su objetivo es construir una base de datos de clave / valor altamente disponible y fuertemente distribuida. , Centrarse en el uso compartido de la configuración (configuración compartida) y el descubrimiento de servicios (descubrimiento de servicios). etcd está actualmente actualizado a la versión v3 y se ha utilizado en proyectos como CoreOS, Kubernetes, Cloud Foundry, etc.

Un almacén de valor clave distribuido y confiable para los datos más críticos de un sistema distribuido

  • Sitio web oficial: https://etcd.io/
  • Github: https: //github.com/etcd-io/etcd

Como proyecto inspirado en ZooKeeper, etcd, además de tener funciones similares, se centra en los siguientes cuatro puntos:

  1. Simple : fácil de implementar y fácil de usar. Proporcione REST y API de gRPC.
  2. Seguridad : admite la certificación de seguridad SSL opcional.
  3. Rápido : cada instancia admite 10,000 operaciones de escritura por segundo.
  4. Fiabilidad : el uso del algoritmo Raft garantiza una gran coherencia de los datos distribuidos.

El escenario de aplicación clásico de etcd es almacenar metadatos en el sistema de control, por lo que etcd no sustituye a otros NoSQL, y mucho menos el almacenamiento principal de datos de la aplicación, etcd debería intentar almacenar solo la información de configuración de los servicios en el sistema.

etcd proporciona las siguientes capacidades:

  • Proporcionar una interfaz para el almacenamiento y acceso de datos : un protocolo de coherencia fuerte garantiza que, por la pluralidad de nodos en el clúster, los datos, etc. Se utiliza para almacenar metainformación y compartir la configuración.
  • Proporcionar un mecanismo de monitoreo : el cliente puede monitorear una clave o algunos cambios clave para monitorear e impulsar cambios.
  • Proporcionar un mecanismo de renovación y expiración de claves : el cliente implementa la renovación a través de una actualización regular, que se utiliza para el monitoreo del clúster y el descubrimiento de registros de servicios
  • Brindar soporte atómico CAS (Compare And Swap) y CAD (Compare And Delete) : se utiliza para bloqueos distribuidos y elecciones de líder.

etcd vs ZooKeeper vs Consul

Etcd, Zookeeper y Consul son tres productos que usamos a menudo para la selección. Las capacidades proporcionadas por etcd y ZooKeeper son muy similares. Ambos son almacenamiento de metainformación común y consistente, y ambos proporcionan un mecanismo de vigilancia para la notificación y distribución de cambios. Todos son utilizados por sistemas distribuidos como almacenamiento de información compartida, y sus posiciones en el ecosistema de software son casi las mismas, que pueden reemplazarse entre sí.

ZooKeeper está alojado en Apache Foundation, desarrollado en Java y proporciona interfaces RPC. Se incubó por primera vez en el proyecto Hadoop y se usó ampliamente en sistemas distribuidos, como Hadoop, Solr, Kafka y Mesos. Y etcd es una estrella en ascenso, centrándose principalmente en dimensiones como protocolo de coherencia, facilidad de uso, operación y mantenimiento, y seguridad. Por el contrario, ZooKeeper tiene las desventajas de "complejidad", "vinculación de lenguaje" y "desarrollo lento". Aquí están las comparaciones entre los dos:

  • Protocolo de conformidad : etcd usa el protocolo Raft, Zookeeper usa el protocolo ZAB (protocolo similar a PAXOS), el primero es más fácil de entender y facilita la implementación de ingeniería;
  • Almacenamiento de datos : etcd admite el modelo de datos de control de concurrencia de múltiples versiones (MVCC) y admite la consulta de los pares clave-valor de la versión anterior.
  • Operación y mantenimiento : etcd es fácil de operar y mantener, mientras que Zookeeper es difícil de operar y mantener;
  • Seguridad : etcd admite el protocolo HTTPS, pero Zookeeper carece de este aspecto;
  • API : etcd proporciona HTTP + JSON y API gRPC, multiplataforma y en varios idiomas, Zookeeper necesita utilizar su cliente;

El objetivo de Consul es más específico. Etcd y ZooKeeper proporcionan capacidades de almacenamiento distribuidas y consistentes. Los propios usuarios deben implementar escenarios comerciales específicos, como el descubrimiento de servicios y los cambios de configuración. Por otro lado, Consul toma el descubrimiento de servicios y los cambios de configuración como sus principales objetivos, y también incluye el almacenamiento de claves / valores. En el ecosistema de software, cuanto más abstractos son los componentes, más amplio es el alcance de la aplicación, pero al mismo tiempo, debe haber deficiencias para satisfacer las necesidades de escenarios comerciales específicos.

Escenarios de aplicación de etcd

Registro y descubrimiento de servicios

El descubrimiento de servicios es uno de los problemas más comunes en los sistemas distribuidos, a saber: "¿Cómo pueden los procesos o servicios en el mismo clúster distribuido encontrarse y establecer una conexión?" En resumen, los procesos o servicios en el clúster deben ser descubiertos por otros, y también deben ser descubiertos por ellos mismos, y pueden ser encontrados y conectados por los nombres de los demás.

Para resolver el problema del descubrimiento de servicios, se necesitan los siguientes tres pilares, ninguno de los cuales es indispensable:

  1. Un directorio de almacenamiento de servicios altamente consistente y altamente disponible (Service Registry) : etcd basado en el algoritmo Raft nace como un directorio de almacenamiento de servicios altamente consistente y altamente disponible.
  2. Un mecanismo para registrar servicios y monitorear el estado de salud de los servicios : los usuarios pueden registrar servicios en etcd y establecer TTL clave para los servicios registrados, y mantener el latido del servicio con regularidad para lograr el efecto de monitorear el estado de salud.
  3. Un mecanismo de búsqueda y conexión de servicios : los servicios registrados en el tema especificado por etcd también se pueden encontrar en el tema correspondiente. Para garantizar la conectividad, podemos implementar un modo proxy, etcd en cada máquina de servicio, de modo que podamos asegurarnos de que los servicios que pueden acceder al clúster etcd se puedan conectar entre sí.

Inserte la descripción de la imagen aquí

  • Adición dinámica de servicios en la arquitectura de microservicios: la arquitectura de microservicios, es decir, varios microservicios trabajan juntos para formar una arquitectura potente. En la arquitectura de microservicios, cómo agregar servicios dinámicamente de manera transparente es el primer problema a resolver. A través del mecanismo de descubrimiento de servicios, se registra un catálogo de un determinado nombre de servicio en etcd, y las direcciones IP de los nodos de servicio disponibles se almacenan en el catálogo. En el proceso de uso del servicio, simplemente busque el nodo de servicio disponible en el catálogo de servicios para usarlo.

Inserte la descripción de la imagen aquí

  • El reinicio por falla de la instancia en la plataforma PaaS es transparente : las aplicaciones en la plataforma PaaS son generalmente de múltiples instancias, y el cliente puede acceder de manera transparente a estas múltiples instancias a través del nombre de dominio (Dominio), y también se puede lograr el equilibrio de carga. Sin embargo, una determinada instancia de la aplicación puede fallar y reiniciarse en cualquier momento, y luego la configuración de resolución de nombres de dominio debe actualizarse dinámicamente. Este problema de configuración dinámica se puede resolver fácilmente mediante la función de descubrimiento de servicios de etcd.

Inserte la descripción de la imagen aquí

Publicar noticias y suscribirse

En un sistema distribuido, la publicación y suscripción de mensajes es un método de comunicación sólido entre componentes (servicios). Es decir: construir un centro de intercambio de configuraciones, donde el productor de mensajes (Productor) publica mensajes, y el consumidor de mensajes (Consumidor) se suscribe al tema que le interesa (Tema), una vez que el tema tenga un mensaje publicado, notificará al suscriptor en tiempo real (Abonado). De esta manera, se puede lograr una gestión centralizada y una actualización dinámica de la configuración del sistema distribuido.

Inserte la descripción de la imagen aquí

  • La información de configuración utilizada por la aplicación se almacena en etcd para una gestión centralizada (centro de intercambio de configuración) : la aplicación obtiene activamente información de configuración de etcd cuando se inicia y, al mismo tiempo, registra un Watcher en etcd y espera (se completa la suscripción). Cuando se actualice la configuración, etcd notificará a los suscriptores en tiempo real para lograr el propósito de obtener la información de configuración más reciente.

  • En el servicio de búsqueda distribuida, la metainformación indexada y el estado del nodo de las máquinas del clúster de servidores se almacenan en etcd para que cada cliente se suscriba : el uso de la función TTL clave de etcd puede garantizar que el estado de la máquina se actualice en tiempo real.

  • Sistema de recopilación de registros distribuidos : el trabajo principal de este sistema es recopilar registros distribuidos en diferentes máquinas. Los recopiladores suelen asignar unidades de tareas de recopilación de acuerdo con las aplicaciones o los temas, por lo que puede crear un directorio con el nombre de la aplicación o el tema en etcd, y almacenar todas las direcciones IP de la máquina relacionadas con esta aplicación o tema en el directorio en forma de subdirectorios. , Y luego configure un Observador recursivo etcd para monitorear recursivamente los cambios de toda la información en la aplicación o directorio de temas. De esta manera, cuando cambia la IP de la máquina (mensaje), el recolector puede ser notificado en tiempo real para ajustar la asignación de tareas.

  • La información en el sistema debe obtenerse de forma dinámica y automática y la intervención manual para modificar el contenido de la solicitud de información : generalmente se expone la interfaz, como la interfaz JMX, para obtener información en tiempo de ejecución. Después de la introducción de etcd, no es necesario implementar un conjunto de soluciones usted mismo, siempre que la información esté almacenada en el directorio etcd especificado, se puede acceder a estos directorios de etcd externamente a través de la interfaz HTTP.

Notificación y coordinación distribuidas

La notificación y coordinación de sistemas distribuidos son algo similares a la publicación y suscripción de mensajes. Ambos utilizan el mecanismo Watcher en etcd, y realizan la notificación y coordinación entre diferentes sistemas en un entorno distribuido a través del mecanismo de registro y notificación asincrónica, para realizar el procesamiento en tiempo real de los cambios de datos. La diferencia es que el primero sirve al sistema distribuido en sí, mientras que el segundo sirve al nivel de aplicación superior.

La implementación suele ser así: diferentes sistemas registran el mismo directorio en etcd y configuran Watcher para que observe los cambios del directorio (si necesita cambiar de subdirectorios, puede configurar el modo recursivo), cuando un sistema se actualiza, etcd Luego, el sistema con Watcher será notificado y se ocupará de ello.

Inserte la descripción de la imagen aquí

  • Detección de latidos de bajo acoplamiento a través de etcd : el sistema de detección y el sistema detectado están asociados con un directorio en etcd en lugar de directamente, lo que puede reducir en gran medida el acoplamiento del sistema.

  • Programación completa del sistema a través de etcd : Un sistema consta de dos partes: una consola y un sistema de empuje La responsabilidad de la consola es controlar el sistema de empuje para realizar el trabajo de empuje correspondiente. Algunas operaciones realizadas por el administrador en la consola realmente modifican el estado de ciertos nodos de directorio en etcd, y etcd notificará estos cambios a los clientes del sistema push registrados con Watcher, y el sistema push realizará las tareas push correspondientes.

  • Informe de trabajo completo a través de etcd : la mayoría de los sistemas de distribución de tareas similares, después de que se inician las subtareas, registre un directorio de trabajo temporal en etcd e informe su progreso con regularidad (escriba el progreso en este directorio temporal), para que la La persona puede conocer el progreso de la tarea en tiempo real.

Cerradura distribuida

Debido a que etcd utiliza el algoritmo Raft para garantizar una sólida coherencia de datos, el valor almacenado en el clúster para una determinada operación debe ser globalmente coherente, por lo que es fácil de usar para implementar bloqueos distribuidos. Hay dos formas de utilizar el servicio de bloqueo, una es mantener el uso exclusivo y la otra es controlar el tiempo.

  1. Mantener exclusivo : es decir, un candado exclusivo, y solo un usuario que adquiere el candado puede finalmente obtenerlo. Con este fin, etcd proporciona un conjunto de API que implementan la operación atómica de bloqueo distribuido CAS (Compare And Swap). Al establecer el valor prevExist, puede asegurarse de que cuando varios nodos crean un directorio al mismo tiempo, solo uno tiene éxito. Se puede considerar que el usuario que se creó con éxito obtuvo el bloqueo.

  2. Tiempo de control : es decir, bloqueos de tiempo . Todos los usuarios que quieran obtener bloqueos serán programados para su ejecución, pero el orden de obtención de bloqueos también es globalmente único y determina el orden de ejecución. etcd también proporciona un conjunto de API (creación automática de claves ordenadas) para este propósito. Al crear un valor para un directorio, se especifica como una acción POST, de modo que etcd generará automáticamente una clave de valor máximo actual en el directorio y almacenará este nuevo valor ( Numero de cliente). Al mismo tiempo, puede utilizar la API para enumerar todos los valores clave en el directorio actual en orden. En este momento, el valor de estas claves es la secuencia de tiempo del cliente, y el valor almacenado en estas claves puede ser el número que representa al cliente.

Inserte la descripción de la imagen aquí

Cola distribuida

La cola distribuida es similar al uso del bloqueo de tiempo distribuido mencionado anteriormente, a saber: crear una cola de primero en entrar, primero en salir y garantizar el pedido. Otra implementación más interesante es garantizar que la cola alcance una determinada condición y luego se ejecute uniformemente en orden. La implementación de este método puede crear otro nodo / queue / condition en el directorio / queue.

  • La condición puede indicar el tamaño de la cola : por ejemplo, una tarea grande debe ejecutarse cuando hay muchas tareas pequeñas listas. Cada vez que una tarea pequeña está lista, el número de condición se agrega al número 1, hasta que alcanza el número especificado por la tarea grande y luego se ejecuta la cola. En la serie de pequeñas tareas, finalmente se ejecuta la gran tarea.
  • La condición puede indicar si una determinada tarea está en la cola : esta tarea puede ser el primer programa de ejecución de todas las tareas de clasificación, o puede ser un punto en la topología que no tiene dependencias. Por lo general, estas tareas deben ejecutarse antes de que se puedan ejecutar otras tareas en la cola.
  • La condición puede representar otro tipo de notificación para comenzar a ejecutar la tarea : puede ser especificada por el programa de control, y cuando la condición cambia, la tarea en cola comienza a ejecutarse.

Inserte la descripción de la imagen aquí

Monitoreo de clústeres

Realizar el monitoreo de clústeres a través de etcd es muy simple y en tiempo real. Se aplican dos funciones principales de etcd:

  1. Mecanismo de Watcher : cuando un nodo desaparece o cambia, Watcher lo descubrirá y notificará al usuario la primera vez.
  2. Mecanismo clave TTL : Por ejemplo, envíe un latido cada 30 segundos para que el nodo que representa la supervivencia de la máquina continúe existiendo, de lo contrario el nodo desaparecerá.

De esta manera, el estado de salud de cada nodo se puede detectar por primera vez para completar los requisitos de monitoreo del clúster.

Inserte la descripción de la imagen aquí

Elección de líder

Además, el uso de bloqueos distribuidos puede implementar fácilmente la elección de líder para múltiples nodos en el clúster. Este tipo de escenario suele ser algunos cálculos de CPU a largo plazo o máquinas que usan operaciones de E / S. Solo se requiere el cálculo o procesamiento del Líder elegido una vez, y los resultados se pueden copiar a otros Seguidores. De esta forma se evita la duplicación de trabajo y se ahorran recursos informáticos.

El escenario clásico es establecer un índice completo en el sistema de búsqueda: si cada máquina vuelve a realizar la creación del índice, no solo lleva mucho tiempo, sino que no se puede garantizar la consistencia de la creación del índice. Al crear un nodo en el mecanismo CAS de etcd al mismo tiempo, la máquina creada con éxito actúa como líder, realiza el cálculo del índice y luego distribuye los resultados del cálculo a otros nodos.

Balanceo de carga

Se puede realizar un balanceador de carga suave a través de etcd, lo que se refleja en dos aspectos:

  1. El acceso a la información almacenada en la arquitectura distribuida de etcd admite el equilibrio de carga : después de agrupar etcd, cada nodo central de etcd puede gestionar las solicitudes de los usuarios. Por lo tanto, aunque etcd almacena más metadatos del sistema de control, también es una buena opción almacenar los datos del mensaje con una pequeña cantidad de datos y a los que se accede con frecuencia directamente en etcd, como la tabla de códigos secundaria que se usa comúnmente en los sistemas comerciales (en la tabla Almacene el código en etcd, almacene el significado específico del código en etcd, el sistema de negocios llama al proceso de buscar la tabla, necesita buscar el significado del código en la tabla).
  2. Use etcd para mantener una tabla de nodos de equilibrio de carga : etcd puede monitorear el estado de múltiples nodos en un clúster. Cuando se envía una solicitud, puede reenviar la solicitud a múltiples estados supervivientes de una manera de sondeo. Similar a KafkaMQ, ZooKeeper se utiliza para mantener el equilibrio de carga entre productores y consumidores. También puede utilizar etcd para realizar el trabajo de ZooKeeper.

Inserte la descripción de la imagen aquí

Supongo que te gusta

Origin blog.csdn.net/Jmilk/article/details/108905961
Recomendado
Clasificación