nacos is a registration and configuration center together

eureka is the only registration center, and the configuration center needs to be used in combination with other components

1.1 Different connection methods

nacos: netty service, long connection and service direct connection

eureka: send heartbeat to service regularly, short connection

1.2 How long does it take to get rid of abnormal services?

1.2.1 Introduction to eureka:

The client sends a heartbeat to the server every 30 seconds, and deletes the service if no heartbeat is received in 90 seconds

leaseRenewalIntervalInSeconds:30

leaseExpirationDurationInSeconds: 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:30000

That is, the service will be deleted in one and a half minutes, which may actually take longer, (for example, the time interval of the ribbon is added)

1.2.2 nacos introduction:

If the heartbeat is not detected for 15 seconds and becomes unhealthy, the request can also be sent normally and report 500

After more than 30 seconds, the instance in nacos is removed from the concurrentHashMap, and the request is 503 again

spring:
  cloud:
    nacos:
      discovery:
        # 实例上报心跳间隔时间（毫秒）
        heart-beat-interval: 1000
        # 实例上报心跳超时时间（毫秒）
        heart-beat-timeout: 3000
        # 实例超时心跳被剔除时间（毫秒）
        ip-delete-timeout: 3000

ribbon:
ServerListRefreshInterval: 5000

1.3 Operation method

1.3.1 nacos special visual interface (as shown in the figure)

1.3.2 eureka is relatively simple (as shown in the figure)

1.4 Introduction to Protection Mechanism

1.4.1 Introduction to CAP Principles: (taken from Baidu)

Indispensable principles in distributed systems C Consistency A Availability P Partition fault tolerance

1.4.2 eureka only needs to enable the protection mechanism (AP):

I would rather the people of the world bear me and I live up to the situation of the people of the world, and will not delete any services

Prevent network fluctuations on the server side, delay receiving heartbeats, and the client is in normal use, resulting in a large area of downtime

1.4.3 nacos self-protection mechanism

All services are temporary services. If the heartbeat is not reported, the exception will be deleted if the heartbeat is not reported.

But as long as the protection mechanism is triggered , even abnormal services will send requests to share the pressure of other services

-> Example ( reason for service avalanche ):

Assuming 10 services, each serving 100qps, the total request volume is 1000

At this time, it becomes two services, that is, each service will withstand 500qps, and the two surviving services may also be down

[prevented service avalanche ]

-> Set the threshold method (as shown in the figure):

0-1 (healthy instances/total instances) = protection threshold normal 0.75-0.85

2. Catalog article preview:

-> Related microservice components of nacos and eureka registry

-> Basic configuration and use of eureka

-> eureka combines configuration center and rabbitmq to achieve configuration refresh

-> Springboot's own monitoring usage method

-> How to use dubbo

-> Service link monitoring zipkin and sleuth

-> mysql cluster deployment and data synchronization

-> How to use mangoDB

-> How to use rocketmq

-> How to use elasticsearch

-> Use of logstash and kibana access logs

-> Advantages and disadvantages of kafka and other mq

-> docker+k8s realizes cluster deployment

3. Microservice article portal

Microservices (total): the difference between eureka and nacos and heartbeat configuration modification

Introduction:

1. The difference between nacos and eureka

1.0 Functional aspects