Microservices-service dependency and governance-service call exceptions, timeouts, id generation

1. In high-concurrency scenarios, RPC calls between services fail due to timeouts or exceptions, and timely compensation (lagging), degrading, or fuse of services can effectively avoid the unavailability of the entire call link and ensure business Correct execution!

For example, downgrade compensation: when requesting to obtain token, because a series of problems (network, server, etc.) can not be obtained in userCenter, we can obtain token from redis

2. Automatic downgrade and manual downgrade under high concurrency

Automatic downgrade means that when the service reaches a certain threshold, the call of certain services is automatically blocked: timeout policy, set a threshold

Manual downgrade usually requires manual setting, which is often not very instant, but it is also essential: manually set a threshold

3. Dynamic switch

The concept of dynamic switching and dynamic degradation is similar, usually in the opening and closing of certain anti-stress functional components under high concurrency. (Mq when the flow is high)

4. Grayscale release

The concept of grayscale is very important. Generally speaking, when an Internet company releases an important function, or a new demand goes online, it must first be grayscale (release in batches to ensure normal use of the project)

Specify the city in the code to use the new function, and when it stabilizes, cancel the judgment and use the new method logic

5. Mainstream ID generation strategy

The easiest way is to use the java.util.UUID tool class to generate. ID has no sorting strategy. The problem with this method is that when I want to query a batch of data and sort the data by the storage time,

You can only set a create_time in the table yourself, add an index to this field and then sort it. (Such as snowflake algorithm, database self-incrementing primary key, sequence, etc.)

Sequence ID generation method:

TimeBaseGenerator generates id: chronological order

Use the ID generation strategy with a generation order. The IDs generated in KeyUtil are in chronological order. We can use IDs for natural sorting. This is a better approach because there is no need to waste an index field.

From the perspective of the database, it is generally possible to reduce the index as much as possible. Although the index can improve query performance, it also takes up space, and the best index for a table should not exceed 3.

So when doing index optimization, it is often based on business considerations.

Business ID generation method:

Using ID generation strategy with business meaning, this method is also very easy to use in traditional application systems and specific scenarios. For example, we now have a commodity shelf table, the data dimension of this table is like this,

For example, it is divided according to cities and regions. For example, in Beijing, we use 100000 as the basic dimension data, 100010 is an area of ​​Beijing, 100020 is another area, and so on, 200,000 may be

Is another city, 200010 is another city area. Then when we generate the shelf information ID, we can organize it in a way that the first six digits are cities and regions, and then we can splice a simple

32-bit UUID string

Judging from the top six, the first three of these four pieces of data belong to the data information under a city, then we query the shelf data under a city, the query statement can be: select * from goods_shelf gs where id> '10001000000000000000000000000000000000' and id < '20000000000000000000000000000000000000'

If you want to query the data of 10 areas under the city of 1000 (Beijing), the query statement is as follows: select * from goods_shelf gs where id> '10001000000000000000000000000000000000' and id <'10002000000000000000000000000000000000'

Note: We have avoided the creation of a new index. We can query the data of a certain dimension by simply using the business ID. Note that the 32-bit random UUID behind us needs to be filled with "0".