Service Scenario Governance Overview

ServiceComb engines provide unified traffic feature governance based on dynamic configurations for different microservice development frameworks, such as Spring Cloud and Java chassis. You can use the microservice governance function of CSE by introducing related governance components to the development frameworks.

ServiceComb engine governance consists of two steps: creating a service scenario and creating a governance policy. The two steps can be performed before microservice deployment for independent governance planning.

Restrictions

Service scenario governance is applicable to ServiceComb engine 2.x.
If you want to delete a governance policy in use, pay attention to the following information:
- Risks: The governance policy may become invalid, which reduces the capability of the microservice system to resist abnormal traffic. When there is abnormal traffic, problems such as unbalanced call distribution and microservice avalanche may occur.
- Precautions: Perform the operations during off-peak hours. Before the operations, ensure that there is no abnormal traffic, such as many calls and call timeout.

Governance Policies

You can configure the following policies: rate limiting, circuit breaker, retry, and bulkhead. For details, see the following table.

Policy	Description
Rate limiting	In the case of a traffic storm or predictable traffic spikes, rate limiting is performed on non-key service scenarios to prevent service and data breakdown caused by instantaneous heavy traffic.
Retry	When a service encounters a non-fatal error (such as occasional timeout), retries can be performed to prevent service failures.
Bulkhead	In the case of a large-scale concurrent traffic storm or predictable traffic impact, the concurrent traffic is controlled to prevent service and data breakdown caused by instantaneously large concurrent traffic.
Circuit breaker	When the error rate of a service scenario exceeds the threshold, all requests in the service scenario will be rejected within one minute to ensure the availability of the entire service system. Then 50% of the service requests will be accepted and statistics on the service error rate will be collected until the error rate in the service scenario is reduced to a value lower than the threshold.