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

This article introduces the knowledge of "what is the time-out delivery of micro-services". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Why do you need timeout control?

A common problem in many cascading failure scenarios is that the server is consuming a lot of resources to process requests that have already exceeded the client deadline. As a result, the server consumes a lot of resources and does not do any valuable work. There is no point in replying to requests that have timed out.

Timeout control can be said to be an important line of defense to ensure service stability. Its essence is rapid failure (fail fast). A good timeout control strategy can clear high-delay requests as soon as possible and release resources as soon as possible to avoid the accumulation of requests.

Inter-service timeout delivery

If a request has multiple phases, such as a series of RPC calls, then our service should check the deadline before each phase starts to avoid useless work, that is, to see if there is enough time left to process the request.

A common error implementation is to set a fixed timeout for each RPC service. We should pass the timeout between each service, which can be set at the top level of the service call, and the same absolute deadline is set for the entire RPC tree triggered by the initial request. For example, at the top level of the service request, the timeout time is set to 3s, the service A requests service B, the execution time of service B is 1s, the timeout time of service B requests service C is 2s, and the execution time of service C is 1s, then service C requests service D again, and the execution time of service D is 500ms, and so on, ideally the same timeout delivery mechanism is used in the whole invocation chain.

If the timeout mechanism is not used, the following occurs:

Service A sends a request to Service B with a timeout of 3s.

Service B takes 2s to process the request and continues to request service C.

If timeout delivery is used, the timeout for service C should be 1s, but there is no timeout delivery, so the timeout is 3s written in the configuration.

It takes 2s for service C to continue execution. In fact, the timeout set by the top layer has expired. The following request is meaningless.

Continue to request service D

If service B uses a timeout delivery mechanism, the request should be abandoned immediately at service C, because the deadline has expired and the client may have reported an error. When we set the timeout delivery, we usually reduce the delivery deadline a little bit, such as 100 milliseconds, to take into account the network transmission time and the processing time after the client receives the reply.

Intra-process timeout transmission

Timeout is not only required between services, but also in the process. For example, Mysql, Redis and service B are called serially in a process, the total request time is set to 3 s, and the request Mysql takes 1 s to request Redis again. The timeout time is 2sJr 500ms execution time and then request service B, which is 1.5 s. Because each of our middleware or services sets a fixed timeout in the configuration file, we need to take the minimum value of the remaining time and the set time.

Context implements timeout delivery

The principle of context is very simple, but its function is very powerful. Go's standard libraries have also implemented support for context, various open source frameworks have also implemented support for context, context has become a standard, and timeout transmission also relies on context.

We usually pass the timeout control on the top layer of the service by setting the initial context, such as setting the timeout time to 3s

Ctx, cancel: = context.WithTimeout (context.Background (), time.Second*3) defer cancel ()

When making context delivery, such as the request for Redis in the figure above, get the remaining time as follows, and then take a smaller time compared to the timeout set by Redis

Dl, ok: = ctx.Deadline () timeout: = time.Now () .Add (time.Second * 3) if ok: = dl.Before (timeout); ok {timeout = dl}

Timeout passing between services mainly refers to timeout passing when RPC calls. For gRPC, we do not need to do any additional processing. GRPC itself supports timeout passing, the principle is similar to the above, it is passed through metadata, and will eventually be converted to the value of grpc-timeout, as shown in the following code: grpc-go/internal/transport/handler_server.go:79

If v: = r.Header.Get ("grpc-timeout"); v! = "{to, err: = decodeTimeout (v) if err! = nil {return nil, status.Errorf (codes.Internal," malformed time-out:% v ", err)} st.timeoutSet = true st.timeout = to}

Timeout delivery is an important line of defense to ensure service stability. The principle and implementation are very simple. Do you implement timeout delivery in your framework? If not, let's get started.

Timeout passing in go-zero

Timeouts for api gateway and rpc services can be configured in go-zero through the Timeout in the configuration file, and are automatically passed between services.

This is the end of the content of "what is the timeout delivery of microservices". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.