Tabla de contenido
1. La diferencia entre nacos y eureka
1.1 Diferentes métodos de conexión
1.2 ¿Cuánto tiempo se tarda en eliminar el servicio anormal?
1.2.2 Introducción a los nacos:
1.3.1 Interfaz visual especial de nacos (como se muestra en la figura)
1.3.2 eureka es relativamente simple (como se muestra en la figura)
1.4 Introducción al mecanismo de protección
1.4.1 Introducción a los Principios CAP: (tomado de Baidu)
1.4.2 eureka solo necesita habilitar el mecanismo de protección (AP):
1.4.3 mecanismo de autoprotección nacos
-> Ejemplo (causa de avalancha de servicio):
-> Configure el método de umbral (como se muestra en la figura):
2. Vista previa del artículo del catálogo:
-> Componentes de microservicio relacionados de nacos y registro eureka
-> Configuración básica y uso de eureka
-> eureka combina el centro de configuración y rabbitmq para actualizar la configuración
-> Método de uso de monitoreo propio de Springboot
-> Servicio de monitoreo de enlaces zipkin y sleuth
-> despliegue de clúster mysql y sincronización de datos
-> Cómo usar la búsqueda elástica
-> Uso de registros de acceso logstash y kibana
-> Ventajas y desventajas de kafka y otros mq
-> docker+k8s realiza la implementación del clúster
3. Portal de artículos de microservicios
-> Varias formas de servicio de llamada remota (fingir, etc.):
-> Configuración y uso de seata (AT):
-> Implementación automatizada de Jenkins:
Introducción:
El artículo presentará la diferencia esencial entre nacos y eureka, y cómo reconfigurar el latido del corazón, el mecanismo de autoprotección,
Reglas de eliminación de servicios y cómo ambas pueden garantizar el centro de registro de microservicios de CAP/AP
Al final del artículo se encuentra el directorio de servicios de funciones comunes y el portal de microservicios.
1. La diferencia entre nacos y eureka
1.0 Aspectos funcionales
nacos es un centro de registro y configuración junto
eureka es el único centro de registro, y el centro de configuración debe usarse en combinación con otros componentes
1.1 Diferentes métodos de conexión
nacos: servicio netty, conexión larga y servicio conexión directa
eureka: enviar latidos al servicio regularmente, conexión corta
1.2 ¿Cuánto tiempo se tarda en eliminar el servicio anormal?
1.2.1 Introducción a eureka:
El cliente envía un latido al servidor cada 30 segundos y elimina el servicio si no se recibe ningún latido en 90 segundos.
leaseRenewalIntervalInSeconds:30
arrendamientoExpirationDurationInSeconds: 90
client:
register-with-eureka:true #false表示不向注册中心注册
fetch-registry:false #false维护服务实例，不区域检索服务
service-url:
#集群指向其他的eureka
#defaultZone:http://eureka1:2001/eureka #不搭律作群 单机指向自己
defaultZone:http://eureka1:2001/eureka,http://eureka2:2002/eureka #集群
server:
#关闭自我保护机制，保证不可用服务被即时别除
enable-self-preservation:false
#并将就认心线由X设置未30s
eviction-interval-timer-in-ms:30000Es decir, el servicio se eliminará en un minuto y medio, lo que en realidad puede demorar más (por ejemplo, se agrega el intervalo de tiempo de la cinta)
1.2.2 Introducción a los nacos:
Si el latido del corazón no se detecta durante 15 segundos y se vuelve incorrecto, la solicitud también se puede enviar normalmente e informar 500
Después de más de 30 segundos, la instancia en nacos se elimina del concurrentHashMap y la solicitud es 503 nuevamente
spring:
cloud:
nacos:
discovery:
# 实例上报心跳间隔时间（毫秒）
heart-beat-interval: 1000
# 实例上报心跳超时时间（毫秒）
heart-beat-timeout: 3000
# 实例超时心跳被剔除时间（毫秒）
ip-delete-timeout: 3000cinta:
ServerListRefreshInterval: 5000
1.3 Método de operación
1.3.1 Interfaz visual especial de nacos (como se muestra en la figura)
1.3.2 eureka es relativamente simple (como se muestra en la figura)
1.4 Introducción al mecanismo de protección
1.4.1 Introducción a los Principios CAP: (tomado de Baidu)
Principios indispensables en los sistemas distribuidos C Consistencia A Disponibilidad P Tolerancia a fallos de partición
1.4.2 eureka solo necesita habilitar el mecanismo de protección (AP):
Prefiero que la gente del mundo me soporte y estoy a la altura de la situación de la gente del mundo, y no eliminaré ningún servicio.
Evite las fluctuaciones de la red en el lado del servidor, retrase la recepción de latidos y el cliente esté en uso normal, lo que resulta en una gran área de tiempo de inactividad
1.4.3 mecanismo de autoprotección nacos
Todos los servicios son servicios temporales. Si no se informa el latido, la excepción se eliminará si no se informa el latido.
Pero mientras se active el mecanismo de protección , incluso los servicios anormales enviarán solicitudes para compartir la presión de otros servicios.
-> Ejemplo ( motivo de la avalancha de servicio ):
Suponiendo 10 servicios, cada uno con 100 qps, el volumen total de solicitudes es 1000
En este momento, se convierte en dos servicios, es decir, cada servicio soportará 500qps, y los dos servicios supervivientes también pueden estar caídos
[ avalancha de servicio evitada ]
-> Configure el método de umbral (como se muestra en la figura):
0-1 (instancias en buen estado/instancias totales) = umbral de protección normal 0,75-0,85
2. Vista previa del artículo del catálogo:
-> Componentes de microservicio relacionados de nacos y registro eureka
-> Configuración básica y uso de eureka
-> eureka combina el centro de configuración y rabbitmq para actualizar la configuración
-> Método de uso de monitoreo propio de Springboot
-> Cómo usar dubbo
-> Servicio de monitoreo de enlaces zipkin y sleuth
-> despliegue de clúster mysql y sincronización de datos
-> Cómo usar mangoDB
-> Cómo usar Rocketmq
-> Cómo usar la búsqueda elástica
-> Uso de registros de acceso logstash y kibana
-> Ventajas y desventajas de kafka y otros mq
-> docker+k8s realiza la implementación del clúster
3. Portal de artículos de microservicios
-> Varias formas de servicio de llamada remota (fingir, etc.):
-> Configuración y uso de seata (AT):
Transacciones distribuidas y métodos de configuración de Seata AT (Parte 1)
-> Implementación automatizada de Jenkins:
implementación automatizada de jenkins