Updated on 2025-08-29 GMT+08:00

Microservice Governance Overview

If an application is developed using the microservice framework, the microservice is automatically registered with the corresponding ServiceComb engine after the application is managed and started. You can perform service governance on the engine console.

After a microservice is deployed, you can govern the request traffic, troubleshooting, and load balancing of the microservice based on the microservice running status.

Governance Policies

You can configure the following policies: load balancing, rate limiting, fault tolerance, service degradation, circuit breaker, fault injection, and black and white list. For details, see the following table.

Name

Description

Load balancing

  • Application scenario

    Generally, multiple instances are deployed for a microservice. Load balancing controls the policy for a microservice consumer to access multiple instances of a microservice provider to balance traffic. It includes polling, random, response time weigh, and session stickiness.

  • For details about the configuration example of the governance policy and how to add dependencies to POM, see Load Balancing.

Rate limiting

  • Application scenario

    This policy controls the number of requests for accessing microservices to prevent the system from being damaged due to traffic impact.

  • For details about the configuration example of the governance policy and how to add dependencies to the POM, see Rate Limiting.

Service degradation

  • Application scenario

    When a microservice invokes other microservices, the default value is forcibly returned or an exception is thrown instead of sending the request to the target microservice. In this way, the access to the target microservice is shielded and the pressure on the target microservice is reduced.

  • For details about the configuration example of the governance policy and how to add dependencies to the POM, see Service Degradation.

Fault tolerance

  • Application scenario

    If an exception occurs when a microservice consumer accesses a provider, for example, the instance network is disconnected, the request needs to be forwarded to another available instance. Fault tolerance is often referred to as retry.

  • For details about the configuration example of the governance policy and how to add dependencies to POM, see Fault Tolerance.

Circuit breaker

  • Application scenario

    If an exception occurs when a microservice consumer accesses a provider, for example, the instance network is disconnected or the request times out, and the exception accumulates to a certain extent, the consumer needs to stop accessing the provider and return an exception or a default value to prevent the avalanche effect.

    Automatic circuit breaker is supported, which determines a circuit breaker according to the error rate.

  • For details about the configuration example and how to add dependencies to the POM, see Circuit Breaker.

Fault injection

This policy applies only to microservices accessed through Java chassis.

  • Application scenario

    Fault injection can simulate an invoking failure, which is mainly used for function verification and fault scenario demonstration.

  • Governance of microservices connected to the Java Chassis development framework. For details about the configuration example of the governance policy and how to add dependencies to POM, see Fault Injection.

Blacklist/Whitelist

This policy applies only to microservices accessed through Java chassis.

  • Application scenario

    Based on the public key authentication mechanism, the ServiceComb engine provides the blacklist and whitelist functions. The blacklist and whitelist can be used to control which services can be accessed by microservices.

  • Governance of microservices accessed through Java chassis

    The blacklist and whitelist take effect only after public key authentication is enabled. For details, see Configuring Blacklist and Whitelist.