When the traffic increases sharply and the service has problems, some processing needs to be done, such as service degradation. Service degradation is to stop some services or do not conduct business processing, and release resources to maintain the functions of main services. Recommended distributed architecture Source address

When an e-commerce website is engaged in activities, there is too much pressure during the activities. If it continues, the whole system may hang up. At this time, some resources can be released and some less important services can be degraded, such as login and registration. After the login service is stopped, no more users will rush to buy, and some resources will be released. Even if the login and registration services are stopped, it will not affect the rush purchase of goods.

There are many ways of service degradation, and the best way is to use Docker. When a service needs to be degraded, stop all containers of the service directly and restart it when it needs to be restored.

In addition, it is processed at the API gateway layer. When a service is degraded, the requests from the front end are directly rejected, not forwarded to the internal service, and the traffic is blocked back.

Dynamically degrade the service in Zuul in combination with our configuration center.

Define the Apollo configuration class to store the service information that needs to be degraded. See the following code.

@Data
@Configuration
public class BasicConf {
    // Degraded service ID S, multiple separated by commas
    @Value("${downGradeServiceStr:default}")
    private String downGradeServiceStr;
}

Write a filter to execute the degradation logic, as shown in the following code.

public class DownGradeFilter extends ZuulFilter {
    @Autowired
    private BasicConf basicConf;
    public DownGradeFilter() {
        super();
    }
    @Override
    public boolean shouldFilter() {
        RequestContext ctx = RequestContext.getCurrentContext();
        Object success = ctx.get("isSuccess");
        return success == null ? true : Boolean.parseBoolean(success.toString());
    }
    @Override
    public String filterType() {
        return "route";
    }
    @Override
    public int filterOrder() {
        return 4;
    }
    @Override
    public Object run() {
        RequestContext ctx = RequestContext.getCurrentContext();
        Object serviceId = ctx.get("serviceId");
        if (serviceId != null && basicConf != null) {
            List<String> serviceIds = Arrays.asList(basicConf.getDownGradeServiceStr().split(","));
            if (serviceIds.contains(serviceId.toString())) {
                ctx.setSendZuulResponse(false);
                ctx.set("isSuccess", false);
                ResponseData data = ResponseData.fail("Service degradation", ResponseCode.DOWNGRADE.getCode());
                ctx.setResponseBody(JsonUtils.toJson(data));
                ctx.getResponse().setContentType("application/json; charset=utf-8");
                return null;
            }
        }
        return null;
    }
}

The main logic is in the run method. The service ID to be routed is obtained through RequestContext, and the degraded service information is obtained through configuration information. If the currently routed service is in it, it will be rejected directly, and the corresponding information will be returned to the client for corresponding processing.

When a downgrade is required, it can take effect immediately by directly changing the configuration in the background of Apollo. Of course, it can also be made automatic, such as monitoring some indicators, traffic and load. When some indicators are reached, the downgrade will be triggered automatically.