Martian-cloud 4.0.2, discard the heartbeat mechanism, solve the network pressure problem

First of all, some people may not understand Martian-cloud, or even heard about it for the first time, so friends who are interested can first look at the detailed principles.

https://www.bilibili.com/read/cv8314554

Okay, let’s cut into the topic. The problem solved by this upgrade is as the title says. It solves network pressure by discarding the heartbeat mechanism.

How to realize the offline notification after the heartbeat mechanism is discarded

1. The first is the selfish mechanism

The so-called selfish mechanism is that each service only cares about itself, regardless of others. If each service finds that its locally cached interface cannot be connected, it will drop it locally. As for others, he does not care.

2. Voting mechanism

This is an internal vote for each service, which has nothing to do with the outside. If a service finds that an interface in its local cache cannot be connected, then he will vote for the service pointed to by this interface and let it go offline. The number of votes will be cleared to 0 after the transfer. When the number of votes has accumulated to a certain level, all interfaces of this service will be cleared from the current service. [Each service has a set of such a mechanism to maintain its own local interface cache]

3. What if (the decision to offline a certain service) is a misjudgment

There is a compensation mechanism, that is, when each service drops other services, it will send a notification to the dropped service, asking him to remove himself from the broadcast list (for example, A service cannot call B service interface , When the number of votes accumulates to a certain level, A will clean up all the interfaces of B. After the cleanup, A will send a notification to B, asking B to remove A from the broadcast list, so that if the service of B is not suspended, then B is in the next The interface will be re-broadcasted to A during a polling )

If service B is clearly not up, but service A cannot be tuned continuously, and even the offline notification cannot be notified to service B, then I can only say that service B deserves it. Even if it is a misjudgment, it is better than leaving an error to affect performance.

4. There are many cases of unreasonable mediation, not necessarily because the service is down, so under what circumstances will the service be voted down

It's very simple. When the interface is called, the following three exceptions occur, and it will vote

ConnectException, can't connect, this is not 404, but can't connect to this ip:port at all

UnknownHostException, the address cannot be resolved, the provided ip:port cannot be resolved

SocketTimeoutException, connection timeout, not read time out, but connect time out

5. Then there is the garbage collection mechanism

Garbage collection is very simple, that is, periodically scan the interface of the offline service in the local cache, and then delete it.

The above set of mechanisms can ensure that when the service goes down, the interface will automatically go online and offline from other servers

Official website

http://mars-framework.com/index.html

Guess you like

Origin www.oschina.net/news/120538/martian-cloud-4-0-2-released