Shulou(Shulou.com)06/01 Report--

What is the principle of Martian-cloud infection mechanism? aiming at this problem, this article introduces the corresponding analysis and answer in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

First explain what is the mechanism of infection.

The conventional distribution adopts the [producer-> registry-> consumer] model, in which the producer gives the interface to the registry, and the consumer finds other services from the registry and implements the call.

The contagion mechanism is to discard the registry, the interface can be regarded as a virus, and the service as a human being. As long as there is a direct or indirect connection between services, they will eventually be infected with the virus (interface).

How to achieve it

If there are three services now,

At this point, we need to release these three services, so we can first plan and connect them together, which means to write down who connects who in the configuration.

The connection mode can be like this [figure 1]

It can also be like this [figure 2]

It can also be like this [figure 3]

In short, as long as you don't leave any service alone, you can even make a big tie up whatever you want (but not recommended)

-

After the connection, it comes to the release stage, so what happens between these services when it is released?

What happens when it's released?

Let's take [figure 1] as an example.

1. First of all, we start A service. After startup, A cannot connect to B because other services have not been started, so the local interface cache table of An is empty, as shown in the following figure.

two。 In order not to think that the process is too ideal, I will start C instead of B next.

After C starts, because B has not been started, he cannot be found. At this time, he is isolated, so the local cache interface is still as follows:

3. The next step is to start B. when B starts, it will be discovered by An immediately, so A will get the interface from B once, and the local cache is as follows:

A will do one more thing after obtaining the interface, and that is to send a broadcast. The process is as follows:

Since interfaces are cached locally, and many interfaces come from the same service, the ip and port numbers of these services need to be extracted from the local cache first.

After step 1, you get a batch of ip and port numbers (in this example, the extracted ip and port of B) A broadcasts all its interfaces (all its own interfaces, not locally cached interfaces) to this batch of IP and port numbers (according to this example, A broadcasts its own interface to B)

After the broadcast, the local interface cache becomes like this:

The above is the process of A discovering B, so how does the interface of C infect others?

We all used [figure 1] as an example just now, so in [figure 1] we can see that B is connected to C, so when B starts, in addition to being discovered by A to complete a series of processes described above, he will also find C, and after discovering C, he will get the interface from C once, so the local cache is as follows:

After B gets the interface, it still initiates a broadcast like A. after the broadcast, the local cache becomes like this:

Then it's interesting. How do An and C get infected?

Quite simply, let's review the process when the service is started:

Get the interface from the connected service [if the service has been started, it is to randomly extract a service from the locally cached interface to get the cached interface on that service]

Initiate broadcasts for these services [services that have been broadcast have been directly ignored]

In fact, this process is polling, not one-time, so it is A's turn to execute the process again. When he executes this process again, he will get the interface of C from B and broadcast his interface to C. so now it's like this:

In this way, all the services are discovered by the other party.

What if the service goes down?

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 is not connected, it will drop it from the local. As for others, he does not care.

two。 Voting mechanism

This is the internal vote of each service, which has nothing to do with the outside. If a service finds that one of its locally cached interfaces cannot be connected, it will vote for the service that the interface points to and let it go offline from the local machine. When the number of votes is accumulated to a certain extent, all the interfaces of the service will be cleared from the current service. [each service has a mechanism to maintain its own local interface cache]

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

There is a compensation mechanism, that is, when each service drops another service, it will send a notice to the service that has been dropped, asking him to remove himself from the broadcast list (for example, Service A cannot access the interface of Service B). When the number of votes accumulates to a certain extent, A will clean up all the interfaces of B, and after cleaning up, A will send a notice to B to ask B to remove A from the broadcast list. In this way, if service B does not hang up, then B will rebroadcast the interface to An on the next poll.

If service B doesn't hang up, but service A can't be transferred continuously, and service B can't even be notified of offline notification, then I can only say that service B deserves it. Even misjudgment is better than keeping an error report to affect the performance.

4. There are many cases that can not be transferred, and it is not necessarily that the service has failed, so what kind of situation will you cast an online ticket for the service?

Quite simply, when the interface is called, the following three exceptions occur, and the vote is made.

ConnectException, can not connect, this is not 404 or something, but can not connect to this ip:port at all

UnknownHostException, the address cannot be resolved, and the ip:port provided cannot be recognized by parsing

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

5. Then there is the garbage collection mechanism.

Garbage collection is simple: regularly scan the interface of the offline service in the local cache, and then delete it.

The above mechanism ensures that when the service goes down, the interface will automatically go up and down from other servers.

The linked service is down. How to achieve infection?

If B is hung up, the chain will be broken. Will the infection be affected?

In fact, it will not, because this chain is only useful when it is started and becomes invalid after it is started. For example, A will only go to B to obtain the interface when it is started, and the next time it is polled, it will randomly select a service from the locally cached interface to get it, so the chain will not break.

As for broadcasting, it is also a service that broadcasts to the local cache and is not configured.

So downtime will not affect interface contagion.

What to do if you want to add a new service?

Very simple, just connect him to any service that is running, and soon it will be covered with viruses (interfaces).

The answer to the question about the principle of Martian-cloud infection mechanism is shared here. I hope the above content can be of some help to everyone. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.