Talk about the background

A few days ago in the morning, I waited for half an hour at the office gate, and the reason behind it was that the two-dimensional code of the health code could not be brushed out, and the security boy also kept telling me that alipay could not come out, you use wechat, use wechat.

They use the same interface, I use wechat to have eggs, ah, in the cold wind, I threw a few hair, long away…

As a programmer, I started the inner joke conference: how did this work? No, it doesn’t work. There must be no optimization, there must be no caching, there must be no stress testing.

The following is a technical analysis of the implementation of this scenario and how it can be optimized. This is just my imagination, and I don’t know how other people do it in real life.

Demand analysis

Everyone has a corresponding health code, which is divided into several colors and corresponding to several states. Essentially, the color of the health code can tell if the user has been to a high-risk address.

First of all, the first problem is to calculate the color of the code according to multi-dimensional data, such as the analysis based on the user’s movement track. I don’t know what the actual dimensions are, but I guess trajectory is one of them.

The general storage is also very simple, such as userId code and other fields. If historical data is needed in this scenario, it can be archived separately, and only the data of the last day can be kept for query.

Implementation analysis

The simplest solution is for each query to real-time analysis, so the authenticity of the results is higher, the deficiency lies in the experience is not very good, if more than logic must be unable to give the user response within 1 s, so at the time of the above analysis we design a table for storage, affirmation is to calculate in advance, such as once a day, such forms as half a day at a time.

So let’s do the analysis based on the form of the existing table. This business scenario is a typical scenario of reading more and writing less (early morning writing). If no changes are made, each request directly queries the table and responds directly. In a high-concurrency scenario, you have to rely on the concurrency capability of the database to handle these requests, and it’s easy for the system to hang up and respond slowly, which is why I waited at the door for half an hour.

Increase the cache

The best way is to add cache, directly cache the content of the code, the front end can generate health code according to the content. First of all, this scenario cannot be cached after query, because most people’s monitoring code may be used once when entering the company in the morning, so it is not suitable for the operation of caching after query.

It is necessary to calculate everyone’s health code in the morning, and write a copy of the data into the cache at the same time. Of course, this can be analyzed according to the data accessed at ordinary times. Which part of the people will use it every day, and only the part of the people will be cached in advance.

After caching, almost 90% of the requests hit the cache, because the people who go to work each day don’t change much. The rest of the requests are handled by the database. If they still can’t be handled, you can increase the cache capacity and trade space for time. Or the database can do more than a few slave nodes.

Internal and external isolation

Isolation is also an important part of architectural design. The purpose of isolation is to minimize the scope of failure when something goes wrong.

In the scenario of the health code, first of all, the health code has its own APP. When Alipay failed to print it, I tried it with its own APP, but it could not be opened either.

That is to say, querying health code is an independent service, which may be called by internal products, such as APP, or exposed to external channels, such as Alipay, through Open API.

What isolation is required for this health code?

  • Database isolation

One or more slave nodes can be isolated for corresponding services, such as internal service library 1 and external service library 2, without affecting each other.

  • Service isolation

Repository isolation does not solve the problem according to the problem, services must be isolated. Distinguish between internal and external services. The Open API only connects to external services, and the internal gateway only connects to internal services.

  • The caller limits the flow

There are different limits for different callers, and the internal service allows 80% of the amount to be satisfied. 20% of external services can be met. In this way, in a stressful situation, their internal products are the least influential. That is, you may not be able to open the health code in Alipay, but you can open it in my APP.

However, it still needs to be analyzed according to the actual scenario. For a scenario like health code, the number of external visits may far exceed the number of internal visits, because most people may use Alipay or wechat to open it. Therefore, you can limit traffic based on actual scenarios.

About the author: Yin Jihuan, a simple technology lover, the author of Spring Cloud Micro-service – Full stack Technology and Case Analysis, Spring Cloud Micro-service Introduction combat and Progress, the founder of the public account Monkey World.