In the article “What can a Cloud Server Do”, I mentioned that I plucked a small piece from the limited resources of small and small cloud to play with micro-services. After several days of operation, I finally had the prototype of basic micro-services (SSO, permission control and cross-server resource access).

A series will follow to document the microservices struggle. This article focuses on the service’s journey to discover Eureka.

Not the same Eureka

There are already tons of articles on Eureka on the Web, so there’s no need to mention it here. However, as a small cloud with limited resources, it is impossible to run too many services (limited by the hardware ceiling), so the configuration scheme of Eureka Server needs to be adjusted to make it more suitable for personal small cloud use.

Change the configuration to refresh faster

We all know that Eureka has self-protection on by default, which is nice and powerful, like King of Glory. It’s fun, but if you masturbate too much day and night, it can be deadly, so moderation is the most important.

Disable self-protection mode

As a simple private xiaoyun, I don’t think it is necessary to use Eureka self-protection mode. Why do you say that? You can see it in the context it fits.

If the Eureka Server node is lost within a short period of time and the client heartbeat exceeds the threshold, the Eureka Server enters the self-protection mode. In this mode, the Eureka Server keeps the registration information of the current client and does not remove the client even if it does not receive the heartbeat renewal from the client to prevent the error deletion event caused by network faults rather than client faults.

The above content with a simple example of the conversion, small R found one day can not contact through WeChat goddess, so the probability is the other side to remove small R from friends or read back to renew the (don’t get the heart), if the little R is reason enough to do next should be quietly deleted from the WeChat goddess account (delete invalid client), And announce to all friends through moments that they have no relationship with goddess any more (refresh the cache, update the client list), and then wait for the new goddess to send friend application to R (new client registration). However, if xiao R finds that most people can not contact through wechat one day (the number of lost clients exceeds the threshold), he has to consider whether his wechat has problems (network problems or other non-client problems), rather than deleting all his lost friends (self-protection, waiting for fault recovery).

However, the number of microservices running on our small cloud is small. If one or two microservices are abnormal, it is easy to exceed the threshold of Eureka’s self-protection. At this time, it is more reasonable to remove invalid client information quickly to prevent traffic from being directed to the failed service (feedback error 502 quickly to reduce the pressure on the gateway). There is no need to go into self-protection mode and wait for fault recovery.

Disable the self-preservation mode: eureka.server.enable-self-preservation=false

Quick update

Rapid update Refers to the rapid update of client information maintained by the Eureka Server. When a client goes offline, the Eureka Server immediately updates the client information table.

The Eureka Server uses the eureka.server.renewal-threshold-update-interval-ms to determine the heartbeat frequency at which all registered clients are detected. The default value of this option is 15 minutes, but considering that I am not good at learning skills and my skills are not as good as the quality of the client to pull the hips, the sooner I find it, the sooner I can treat it (manually restart), here I change it to check once every 2 minutes.

When an abnormal client is found, the abnormal client must be removed immediately. Eureka Server is designed to be controlled by eureka. Server. Eviction – interval-timer-in-MS to remove the disabled client at a certain frequency. This option defaults to 60 seconds. Of course, as above, I wanted to move the invalid client out faster, so I changed it to 5 seconds.

Eureka Server has its own internal data caching policy, which I won’t go into detail here. To refresh the client list faster, we disable the ReadOnlyCache cache. eureka.server.use-read-only-response-cache: false

The server configuration is almost able to do fast updates, but the light server is not fast, the client has to keep up. The most important thing the client needs to do is “keep in touch and quit quickly”.

In constant contact, the client is required to speed up the heartbeat interval between the client and the server. The longer the heartbeat interval is, the slower the response of the server is. In theory, the longest heartbeat interval is the heartbeat interval between the failure of the client and the removal of the client information. If the heartbeat interval is 10 minutes, the client can be removed after a maximum of 10 minutes (plus the detection interval of the server).

“Quick exit” refers to the need for the server to move out of the client quickly and decisively, rather than taking a long time to move out. What controls all of this is done by two options.

eureka.instance.lease-renewal-interval-in-seconds

Eureka. Instance. Lease expiration – duration – in – seconds.

Here is the complete configuration of YML

eureka: 
  server: 
    enable-self-preservation: false
    renewal-threshold-update-interval-ms: 120000 
    eviction-interval-timer-in-ms: 5000 
    use-read-only-response-cache: false
  instance: 
    lease-expiration-duration-in-seconds: 10 
    lease-renewal-interval-in-seconds: 5 
  client: 
    fetch-registry: true
    register-with-eureka: true
    service-url: defaultZone: ${discovery.server}/eureka
Copy the code

Custom page direct key information

Eureka Server provides a Web page on which you can view the status of the current Server and registered clients. Native page functions are very good, just not suitable for my small cloud (after all, some functions I do not use, naturally also do not pay attention to).

For the micro services running on the small cloud, I pay more attention to whether the status of each registered client is normal and whether the Eureka status is normal. Therefore, we need to customize Eureka’s page to open links to key information.

There are plenty of tutorials on Eureka’s custom pages, so I won’t repeat them here. To simplify, copy the templates. Erueka directory from the Spring-cloud-Netflix-Eureka-server package to project Resources, and then modify the corresponding four FTLH files as needed.

Notes about Docker environment

When a client registers with the Eureka Server, Eureka checks the client status (health check) for three consecutive times within 30 seconds before refreshing the client information to the client list. However, in the Docker execution environment, it is usually used to start all the services together with the orchestration tool (such as docker-compose). Although all the services are running, it is still possible to receive 404 errors (need to wait 30 seconds to access again).

When a client registers with Eureka Server, the host name is used by default. However, when the client runs in Docker, the host name is actually the Docker Container ID. DNS does not know the IP address of the Docker Container ID used for registration. However, if you use preferIpAddress, the host name can be used instead of the IP address to complete the registration. Unfortunately, The USED IP address is the IP address of the Docker Container, not the address that can be accessed across servers (generally, a public IP address is required). Therefore, it cannot be used by other servers. Therefore, you need to add eureka.instance.ip-address to manually specify an IP address for the client to reach. This will be mentioned in subsequent records.

This article deals with the source address Gitee

Copy the code