springcloud--eureka service governance in a simple way

Distributed is now the first choice for Internet architecture. In distributed, we will have tripartite theory referred to as CAP

Abbreviation	Full name	Explanation
C	Consistency	Data consistency
A	Availability	Availability, performance
P	Partition tolerance	Partition tolerance

Today we will take a look at the service of service governance in distributed

What is service governance

• When multiple services call each other, they are fragmented and cumbersome to manage. When the callee makes changes, it may involve the caller's changes. So service governance came into being.

• Eureka of spring cloud implements service registration, service invocation, load balancing, and fault tolerance. This is also a common function of the service management module.

• Service registration and service invocation are both clients in eureka's view. The eureka service is the server side. So he is a typical CS architecture. The eureka client needs to maintain a heartbeat mechanism with the eureka service. In this way, the eureka service thinks that the client is not down.

• The above architecture diagram can clearly see that the eureka server can be clustered, and the service provider can be clustered. The client does not need to be clustered. Even clustering is a stand-alone consumer for the eureka service.

Eureka calling process

• When the service provider starts, it will encapsulate the information of its own service and register it to the eureka registry. The service consumer has registered the provider's name and goes to the registration center to find the real address and make the call.

• The management of the service provider does not need to know the specific information of the service provider for the service consumer. You only need to know the registered name of the service provider. After we are clustered, we don't have to worry about the specific calling address of the provider. Load balancing is also distributed by eureka for me. Our client is only responsible for the call of the interface.

Eureka stand-alone registration

Eureka stand-alone startup

• Here we do not do other explanations of spring, please see the detailed code of the git branch for details

Click me to download the source code

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

• Add the above gva to the pom file in our newly created project. Eureka server functions will be injected. Below we only need to add some configuration to start it.

• After adding the dependency, we add the following configuration to the yml in the springboot project

eureka:
  instance:
    hostname: localhost
  client:
    register-with-eureka: false #表示该模块作为eureka服务，自己是不需要想自己注册的，注册了只是徒增烦恼
    fetch-registry: false # 表示自己就是注册中心。自己是管理者不是被管理者。
    service-url:
      defaultZone: http://${
    
    eureka.instance.hostname}:${
    
    server.port}/eureka/

• Finally, we start eurekaserver on the spiringboot startup class.@EnableEurekaServer

• Being able to access indicates that our eureka service has started normally. No clients are registered now. So now you see that the DS Replicas list is empty.

Stand-alone registration

• Above we have started the eureka service on a stand-alone machine. Let's see if the service registration is possible. We have taken the payment module as an example.

• Add client coordinates in pom

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

• Fill in the address in yml

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://localhost:7001/eureka

• Add annotations to the main startup class@EnableEurekaClient

Cluster registration

• Now we open a few more payments to register

• Because we are developing in idea. It has not been marked as a jar package. It is also for the convenience of debugging the payment project that is directly copied through idea here

• Now let’s take a look at the situation of our local idea startup project. There are already two payments, 8001, 8002.

• Now we see 8001,8002 appearing on the eureka service

Customer call

• Remember how the order module on our feature/cloud-pre calls payment? Yes, we call it through http via resetTemplate. Now we still make calls through him, but the calling address is the service name registered by payment on eureka.

• How to register the client here is the same as the payment configuration. Because although payment is called by order, payment and order are both clients for eureka. So the configuration is the same.

• Now on the stand-alone eureka, we see the stand-alone order service and the cluster payment service. Below we make the following changes to the place where our order calls payment

• Only the call and address have been modified. Of course, the premise is that restTemplate supports load balancing.

• Readers can test the results below. http://localhost/order/getpayment/123Call this interface multiple times. You will find that the service port in the returned result will constantly switch between 8001 and 8002. Because restTemplate is polled by default. Here, payment provides two services. Here we have realized the service registration and invocation of eureka stand-alone version

Eureka cluster registration

• Above is a stand-alone euroke. Let's take a look at how to configure the euroke cluster. It is very simple for eureka client to register to eureka cluster.

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://localhost:7001/eureka,http://www.eureka2/eureka

• Just add eureka service directly after defaultZone as above. Normal clusters are arranged on different machines. So the domain name or ip is different. If readers deploy on one machine, they can assign different services to different domain names through nginx. Because the domain name is required for configuration on the eureka server.

• The client is directly appended. There are not many changes to the eureka server. You only need to configure the hostname to be unique.

eureka:
  instance:
    hostname: www.zxhtom1.com    #eureka服务端的实例名字
  client:
    register-with-eureka: false    #表识不向注册中心注册自己
    fetch-registry: false   #表示自己就是注册中心，职责是维护服务实例，并不需要去检索服务
    service-url:
      defaultZone: http://eureka7002.com:7002/eureka/ 

• So if it is a stand-alone deployment cluster, we need to forward it through nginx. I won't go into details here

idea how to start the same project multiple times

• Just now for the convenience of demonstration when deploying the cluster. We start multiple instances with the help of idea. Assign different ports in it. But it is impossible to deploy eureka cluster. Because the content of the configuration file needs to be changed. We can specify an external configuration file at startup

Eureka self-protection

Why protect yourself

• Above we found that there are two 8002 payments. Why is there such a strange problem? The investigation found that I started 8001, 8002 through idea at the beginning. Then I restarted 8002 by introducing an external configuration file. At this time, the original 8002 instance has actually died. At this time, eureka will think that 50% of the clients do not send heartbeats on time. 50<85 At this time, eureka believes that a large number of clients may not respond in time due to network fluctuations. eureka will open the self-protection mechanism.
• Although the above is a negative example. It also explains exactly why self-protection is needed. At this time, 8002 will be kicked out on other machines because of network delays, and there will be unjust, false and wrong cases. So this also explains why there are two 8002s above.

How to turn on self-protection

• The self-protection function is turned on by default. eureka.server.enable-self-preservation: falseWe set false through this property to turn off self-protection.

How to activate self-protection

• In fact, the above two 8002s are an accident. We accidentally triggered self-protection.

• Self-protection mechanism conditions: The number of heartbeats received in the last minute is less than 85% of the total threads.

• Less than 85% means that there is no designated active number for heartbeat recovery, so it is considered that the network fluctuates.

• Self-protection threshold = renews(last min)/renews(threshold)

• By calculation, we know that it is 75%. If you don't count the normal 8002. That is 50%. So no matter what, it will trigger self-protection.

• Self-protection also satisfies the theory A in the CAP principle mentioned at the beginning. eureka satisfies the principle of high availability. Stay even if the client is down. It's better to stay longer than to kill. This will lead to data inconsistencies.

The above source code

Click me to download