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.