El descubrimiento de servicios nació cuando las aplicaciones comenzaron a ejecutarse y a ser accedidas fuera de una sola máquina. La arquitectura de red actual es que cada host tiene una dirección IP independiente y el descubrimiento de servicios básicamente obtiene la dirección IP implementada por el servicio de alguna manera.
El protocolo DNS es el primer protocolo para traducir un nombre de red a una IP de red. En la selección de arquitectura inicial, DNS + LVS + Nginx básicamente satisface el descubrimiento de todos los servicios RESTful. En este momento, la lista de IP del servicio generalmente se configura en nginx. o LVS. Más tarde, aparecieron los servicios RPC y los servicios en línea y fuera de línea se hicieron más frecuentes. La gente comenzó a buscar un producto de centro de registro que pudiera soportar dinámicas en línea y fuera de línea e impulsar cambios en la lista de IP.
La industria del software de Internet generalmente favorece los productos de código abierto porque el código de los productos de código abierto es transparente, se puede participar en la co-construcción, existe una comunidad para la comunicación y el aprendizaje y, por supuesto, lo que es más importante, es gratuito. Los desarrolladores individuales o las pequeñas y medianas empresas suelen elegir productos de código abierto como primera opción.
1 Productos de código abierto
1.1 Cuidador del zoológico
El producto de registro de servicios clásico (aunque su posicionamiento original no está aquí), durante mucho tiempo, es la única opción en la que piensan los chinos cuando mencionan el registro de servicios RPC, que es en gran medida el mismo en popularidad que Dubbo en China.
1.2 Cónsul y Eureka
Ambos aparecieron en 2014:
- Consul está diseñado para incluir muchas funciones necesarias en la gobernanza de servicios distribuidos y puede admitir el registro de servicios, verificación de estado, gestión de configuración, Service Mesh, etc.
- Eureka se ha vuelto popular con el concepto de microservicios y su profunda integración con la ecología SpringCloud también ha adquirido una gran cantidad de usuarios.
1.3 Nacos
Aprovechando la experiencia de producción de servicios a gran escala de Alibaba, intenta ofrecer a los usuarios una nueva opción en el mercado de gestión de configuración y registro de servicios.
Figura 1 Descubrimiento de servicios:
1.4 Ventajas de los productos de código abierto
Los desarrolladores pueden leer el código fuente para comprender el diseño funcional y el diseño arquitectónico del producto y, al mismo tiempo, probar el rendimiento mediante la implementación local, seguido de artículos comparativos de varios productos.
Sin embargo, la comparación actual de los centros de registro a menudo se queda en la comparación de funciones superficiales, sin una discusión en profundidad sobre la arquitectura o el rendimiento.
1.5 puntos débiles
Es el registro de servicios el que a menudo se oculta detrás del marco del servicio como un producto con soporte silencioso. Un marco de servicio excelente a menudo admite múltiples centros de configuración, pero la selección del centro de registro todavía está fuertemente relacionada con el marco de servicio. Una situación común es que un marco de servicio tendrá un centro de registro de servicio predeterminado. Aunque esto ahorra a los usuarios la molestia de seleccionar el modelo, las limitaciones de un solo centro de registro hacen que los usuarios implementen múltiples conjuntos de centros de registro completamente diferentes cuando utilizan múltiples marcos de servicios. La colaboración de datos entre estos centros de registro también es un problema.
Este artículo presenta en profundidad los principios de diseño del registro de Nacos desde varios ángulos e intenta resumir y explicar los puntos principales que deben seguirse y considerarse en el diseño del producto del registro de servicios a partir de nuestra experiencia e investigación.
2 modelo de datos
Los datos centrales del centro de registro:
- Nombre del Servicio
- su dirección de red correspondiente
Cuando un servicio registra varias instancias, necesitamos filtrar las instancias en mal estado o distribuir el tráfico en función de algunas características de las instancias, por lo que debemos almacenar algunos atributos, como el estado de salud y el peso, en las instancias. A medida que se expande la escala del servicio, es necesario establecer gradualmente algunas reglas de permisos en todo el nivel de servicio y algunos modificadores que sean efectivos para todas las instancias, por lo que algunos atributos se establecerán en el nivel de servicio. Más tarde, descubrimos que una sola instancia de servicio necesitaría dividirse en múltiples subconjuntos. Por ejemplo, si un servicio se implementa en varias salas de computadoras, puede ser necesario configurar diferentes instancias de cada sala de computadoras. Otro nivel de datos se establece entre el servicio y la instancia.
Comparado
- Zookeeper no diseña un modelo de datos para el descubrimiento de servicios. Sus datos están organizados en un árbol KV más abstracto, por lo que, en teoría, se puede almacenar cualquier dato semántico.
- Tanto Eureka como Consul logran la expansión de datos a nivel de instancia, que puede cumplir con la mayoría de los escenarios, pero no puede cumplir con el almacenamiento de datos de servicios a gran escala y en múltiples entornos.
- El modelo de datos extraído por Nacos después de años de experiencia en producción interna es un modelo de tres capas de servicio-clúster-instancia. Básicamente satisface el almacenamiento de datos y la gestión de servicios en todos los escenarios.
Aunque el modelo de datos de Nacos es relativamente complejo, no lo obliga a usar todos los datos que contiene. En la mayoría de los escenarios, puede optar por ignorar estos atributos de datos. En este momento, se puede reducir al mismo modelo de datos que Eureka y Cónsul.
Modelo de segregación de datos
Como componente de servicio compartido, debe poder garantizar el aislamiento y la seguridad de los datos cuando los utilizan varios usuarios o partes comerciales, lo cual es muy común en escenarios comerciales un poco más grandes. Por otro lado, el registro de servicios a menudo admite la implementación en la nube, en este momento se requiere que el modelo de datos del registro de servicios pueda adaptarse al modelo general en la nube.
Zookeeper, Consul y Eureka no tienen un modelo claro para el aislamiento de servicios a nivel de código abierto. Nacos ha considerado desde el principio cómo permitir a los usuarios aislar datos en múltiples dimensiones y al mismo tiempo migrar sin problemas al servicio correspondiente en Alibaba Cloud, producto comercial.
Figura 3 El modelo de aislamiento de lógica de datos de cuatro capas del servicio:
La cuenta de usuario puede corresponder a una empresa o a un particular independiente, por lo general estos datos no serán transmitidos de forma transparente al centro de registro del servicio. Una cuenta de usuario puede crear múltiples espacios de nombres, y cada espacio de nombres corresponde a una instancia de cliente. El clúster físico del registro correspondiente a este espacio de nombres se puede enrutar de acuerdo con las reglas, de modo que se pueda controlar la actualización interna y la migración del registro. No lo saben y, al mismo tiempo, según el nivel de los usuarios, se proporcionan clústeres físicos con diferentes niveles de servicio a los usuarios.
Más abajo hay un identificador de servicio bidimensional compuesto por agrupación de servicios y nombre de servicio, que puede satisfacer el aislamiento del servicio a nivel de interfaz.
Otra característica nueva introducida por Nacos 1.0.0 es: instancia temporal e instancia persistente. La clave para la distinción definitoria entre instancias efímeras y persistentes es la forma en que se realizan los controles de estado. Las instancias temporales utilizan el modo de informes del lado del cliente, mientras que las instancias persistentes utilizan el modo de detección inversa del lado del servidor. Las instancias temporales deben poder eliminar automáticamente las instancias en mal estado sin instancias de almacenamiento persistentes, por lo que dichas instancias son adecuadas para protocolos similares a Gossip. La instancia persistente de la derecha utiliza el método de verificación de estado de detección del lado del servidor, porque el cliente no informará los latidos del corazón, por lo que, naturalmente, es imposible eliminar automáticamente la instancia fuera de línea.
Figura 4 Instancia temporal e instancia persistente:
Para medianas y grandes empresas están disponibles ambos tipos de servicios:
- Algunos componentes básicos, como bases de datos, cachés, etc., a menudo no pueden informar latidos. Al registrar este tipo de servicio, debe registrarse como una instancia persistente.
- Para servicios empresariales de nivel superior, como microservicios o servicios Dubbo, el lado del proveedor del servicio admite la adición de lógica para informar los latidos y se pueden utilizar métodos de registro de servicios dinámicos.
Nacos 2.0 utiliza configuraciones persistentes y no persistentes, pero con ajustes. Los atributos persistentes y no persistentes en Nacos 1.0 se almacenan e identifican como metadatos de una instancia. Como resultado, tanto instancias persistentes como no persistentes pueden existir bajo el mismo servicio. Pero en uso real, este modo:
- Traerá gran confusión y complejidad al personal de operación y mantenimiento.
- Desde la perspectiva de la arquitectura del sistema, existen ciertas contradicciones en el escenario en el que un servicio tiene instancias persistentes y no persistentes.
Como resultado, esta habilidad no se utiliza ampliamente. Para simplificar el modelo de datos de servicio de Nacos, reducir la complejidad de operación y mantenimiento y mejorar la usabilidad de Nacos, en Nacos2.0:
- Si los datos persistentes se abstraen al nivel de servicio
- Ya no se permite que un servicio tenga instancias persistentes e instancias no persistentes al mismo tiempo, y los atributos persistentes de la instancia heredan de los atributos persistentes del servicio.
3 Coherencia de los datos
Los sistemas distribuidos son un tema eterno: desde la perspectiva del nivel de protocolo, a la selección de coherencia no se han sumado nuevos miembros durante mucho tiempo. En la actualidad, lo básico
Puede pertenecer a dos:
- Coherencia de escritura de punto único de la implementación no entre pares basada en Leader
- Coherencia de escritura múltiple para implementaciones de igual a igual
Al elegir un centro de registro de servicios, ningún protocolo puede cubrir todos los escenarios, como por ejemplo:
- Cuando el nodo de servicio registrado no envía regularmente latidos al centro de registro, el protocolo de consenso fuerte parece ser la única opción, porque el registro de compensación de datos no se puede realizar mediante latidos y el primer registro debe garantizar que no se pierdan datos.
- Y cuando el cliente envía latidos regularmente para informar el estado de salud, la tasa de éxito del primer registro no es muy crítica (por supuesto, también es crítica, pero en términos relativos, toleramos una pequeña cantidad de fallas en la escritura de datos), porque lo siguiente -up aún puede pasar Si los latidos del corazón compensan los datos, el cuello de botella de un solo punto del protocolo Paxos no será rentable, es por eso que Eureka no usa el protocolo Paxos sino un mecanismo de renovación personalizado.
Estos dos protocolos de coherencia de datos tienen sus propios escenarios de uso y los diferentes requisitos para el registro del servicio conducirán al uso de diferentes protocolos. El comportamiento de Zookeeper en el sistema Dubbo es en realidad más apropiado para usar el mecanismo de renovación de Eureka, porque el servicio Dubbo se registra en Zookeeper como un nodo temporal y necesita enviar periódicamente latidos a Zookeeper para renovar el nodo y cuando el servicio está fuera de línea. , Zookeeper Elimina los nodos correspondientes. Aunque Zookeeper utiliza ZAB para garantizar una sólida coherencia de los datos, su sala de computadoras carece de capacidades de recuperación ante desastres y no puede adaptarse a algunos escenarios a gran escala.
Nacos 1.0.0 admite oficialmente la coexistencia de dos protocolos de coherencia, AP y CP, porque necesita admitir el registro de múltiples tipos de servicios y tiene capacidades esenciales como la recuperación ante desastres de la sala de computadoras y la expansión del clúster. 1.0.0 Se reestructuró la lógica de lectura, escritura y sincronización de datos y se separó el CRUD relacionado con el negocio de la lógica de sincronización de coherencia subyacente. Luego, abstraiga la lectura y escritura del negocio (principalmente escritura, porque la lectura utilizará directamente el caché de la capa empresarial) en el tipo de datos definido por Nacos y llame al servicio de coherencia para la sincronización de datos. Al decidir si utilizar la coherencia CP o AP, utilice un proxy para reenviar reglas controlables.
Las implementaciones actuales del protocolo de consenso son la coherencia CP basada en Raft simplificado y la coherencia AP basada en el protocolo de desarrollo propio Distro. No hace falta decir que el protocolo Raft está escrito en base al líder y su CP no es estricto, pero puede garantizar la mitad de la coherencia vista y la probabilidad de pérdida de datos es pequeña. El protocolo Distro se refiere al ConfigServer interno y al Eureka de código abierto, y logra básicamente lo mismo sin el uso de almacenamiento de terceros. El objetivo de Distro es realizar algunas optimizaciones lógicas y ajustes del rendimiento.
Figura 5 Protocolo de coherencia de Nacos:
¡Este artículo está publicado por OpenWrite, una plataforma de publicaciones múltiples para blogs !