In the stability guarantee, the technical solution of current limiting and downgrading is aimed at the service interface level, that is, service current limiting and service downgrading. The dimensions of business degradation are switches and plans.
Switch, this concept is more at the business and functional level, mainly for controlling the enabling and stopping of a single function, or switching the function state between different versions.
At the business level, like the often-mentioned big promotion scenarios, many non-core functions will be turned off, and only the core functions of the transaction link will be retained. For example, if you think that product reviews are a non-core function, then you will push this solution through a switch to turn off this function. When the user visits the product details page, this interface is no longer called. From the user's point of view, the review list of the browsed product cannot be seen at the peak time of the big promotion.
At the functional level, caching technology will be used in the technical architecture, but it must be considered that the cache may also fail, such as inaccessibility, or abnormal data disorder, etc. At this time, it will consider bypassing the cache and directly forward the request to The database layer.
There are two methods here: one method is to automatically bypass through the degradation method, which is often called a fuse; the other method, for example, in the case of abnormal data, the request is normal, but the data is problematic, At this time, automatic bypass cannot be achieved, and it must be realized by actively pushing the switch.
A plan can be understood as a complex plan execution that allows an application or business to enter a specific state. This plan will eventually be realized through fine-grained technologies such as switching, current limiting, and downgrading strategies. It is a scenario-based performance of these specific technical solutions.
Because each business or application will have its own switch configuration, and there will be a lot of them. If you push them one by one before the big promotion, the efficiency will not keep up. Therefore, we will provide batch operations for specific scenarios of an application. The method is to connect switches of the same application or even multiple applications in series through pre-planned scenarios.
For example, on the product details page mentioned above, you can not only close product reviews, but also close product collection reminders, buyer shows, store product recommendations, similar product recommendations, and collocation recommendations, etc. With scenario-based plans, management and maintenance will be easier.
In addition to the business-level contingency plan, the contingency plan can also be applied to emergency scenarios, such as abnormal cache failures. In real scenarios, it is necessary to consider more comprehensively. For example, the business access volume that the cache can support is far greater than that of the database. At this time, the function must be downgraded. This requires consideration of whether the database can support such a large amount of requests ( Usually, it is definitely untenable). Therefore, when encountering such a scenario, the first consideration is to limit the traffic. First, limit the business traffic by one-third or even half, and then downgrade the function to the database.
This again involves the serial execution of multiple strategies. If there is no plan, the efficiency will definitely be low, and it may involve multiple applications that will implement the same business degradation strategy. At this time, there must be a plan for unified management, and sort out in advance which applications need to be in this The corresponding switching, current limiting, and downgrading strategies are implemented in the scenario.
The technical solution is not complicated. The field of the switch is mainly managed by Key-Value, and from the application dimension, it is managed through the application name. This correspondence can be managed in a unified console. Proceed as follows:
1. Switch management
It is saved by Key-Value, corresponding to the specific Field field in the code. Here it will involve Spring's AOP and annotation technology.
As shown in the following code, a switch testKey is defined by annotation, which corresponds to the Key configured in the console, and obtains the corresponding Value value. In the business operation phase, we can determine the business execution logic based on this value , a simplified example follows.
@AppSwitcher(key="key1",valueDes = "Boolean类型")
private Boolean key1;
代码中直接调用AppName对应的开关配置，进行不同业务逻辑的实现：
Boolean key1 = MoguStableSwitch.isStableSwitchOn("key1");
if (key1)
{
//开关打开时业务逻辑实现
}else
{
//开关关闭时业务逻辑实现
}2. Switch push
When the switch value is modified on the console, it will be pushed to the configuration center of the microservice for persistence, so that the changed value can still be obtained when the application is restarted next time. There is another way, which is to push through HTTP. The application scenario of this situation is that when the first situation fails, the second interface is reserved for the switch to take effect quickly.
3. Configuration changes
The switch SDK client introduced in the application will monitor the corresponding configuration changes. If there is a change, it will be re-acquired immediately, and it will take effect when the business is running.
4. Plan implementation
It is the serial execution of multiple switching strategies, and the above key steps will be repeated.
This article is a study note for Day9 in April. The content comes from "Zhao Cheng's Operation and Maintenance System Management Course" in Geek Time . This course is recommended.