Updated on 2024-10-15 GMT+08:00

Governing Microservices

After a microservice is deployed, you can govern it based on its running statuses.

Prerequisites

  • You can create a microservice in Microservice List from Service Catalog and start the microservice. After the microservice starts, the service instance is registered under the corresponding service based on configurations in the .yaml file.
  • If the microservice is not created in advance or has been deleted, the microservice is automatically created when the service instance is registered.
  • After a microservice is created, register the service instance before performing the corresponding operation.

Governance Policies

You can configure the following policies: Load Balancing, Rate Limiting, Fault Tolerance, Service Degradation, Circuit Breaker, Fault Injection, and Blacklist and Whitelist. 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

  • 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.
NOTE:

This policy applies only to microservices accessed through Java chassis.

Blacklist and Whitelist

  • Application scenario

    Based on the public key authentication mechanism, ServiceComb engines provide 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 Public Key Authentication.

NOTE:

This policy applies only to microservices accessed through Java chassis.

Configuring Load Balancing

  1. Log in to CSE.
  2. Choose Exclusive ServiceComb Engines.
  3. Click the target engine.
  4. Choose Microservice Governance.

    • For ServiceComb engines with security authentication disabled, go to 6.
    • For ServiceComb engines with security authentication enabled, go to 5.

  5. In the displayed Security Authentication dialog box, enter the account name and password, and click OK.

  6. Click the microservice to be governed.
  7. Choose Load Balancing.
  8. Click New. Select the microservices to be governed and select a proper load balancing policy. For details, see the following table.

    Figure 1 Configuring load balancing (for microservices accessed through Spring Cloud)
    Figure 2 Configuring load balancing (for microservices accessed through Java chassis)

    Policy

    Description

    Round robin

    Supports routes according to the location information about service instances.

    Random

    Provides random routes for service instances.

    Response time weight

    Provides weight routes with the minimum active number (latency) and supports service instances with slow service processing in receiving a small number of requests to prevent the system from stopping response. This load balancing policy is suitable for applications with low and stable service requests.

    NOTE:

    This policy applies to microservices accessed through Java chassis.

    Session stickiness

    Provides a mechanism on the load balancer. In the specified session stickiness duration, this mechanism allocates the access requests related to the same user to the same instance.

    • Stickiness Duration: time limit for keeping a session. The value ranges from 0 to 86400, in seconds.
    • Failures: number of access failures. The value ranges from 0 to 10. If the upper limit of failures or the session stickiness duration exceeds the specified values, the microservice stops accessing this instance.
    NOTE:

    This policy applies to microservices accessed through Java chassis.

  9. Click OK.

Configuring Rate Limiting

  1. Log in to CSE.
  2. Choose Exclusive ServiceComb Engines.
  3. Click the target engine.
  4. Choose Microservice Governance.

    • For ServiceComb engines with security authentication disabled, go to 6.
    • For engines with security authentication enabled, go to 5.

  5. In the displayed Security Authentication dialog box, enter the account name and password, and click OK.

  6. Click the microservice to be governed.
  7. Click Rate Limiting.
  8. Click New. The following table describes configuration items of rate limiting.

    Figure 3 Configuring rate limiting (for microservices accessed through Spring Cloud)
    Figure 4 Configuring rate limiting (for microservices accessed through Java chassis)

    Configuration Item

    Description

    Value Range

    Rate Limiting Object

    Other microservices that access the microservice.

    NOTE:

    This configuration applies to microservices accessed through Java chassis.

    Select an item from the drop-down list next to Rate Limiting Object.

    Upstream Microservice

    Configure rate limiting for the upstream microservice to invoke the service.

    NOTE:

    This configuration applies to microservices accessed through Spring Cloud.

    Select an item from the drop-down list next to Upstream Microservice.

    QPS

    Requests generated per second. When the number of requests sent by the rate limiting object to the current service instance exceeds the specified value, the current service instance no longer accepts requests from the rate limiting object.

    Enter an integer ranging from 1 to 99999.

    If a microservice has three instances, the rate limiting of each instance is set to 2700 QPS, then the total QPS is 8100, and rate limiting is triggered only when the QPS exceeds 8100.

  9. Click OK.

Configuring Service Degradation

  1. Log in to CSE.
  2. Choose Exclusive ServiceComb Engines.
  3. Click the target engine.
  4. Choose Microservice Governance.

    • For engines with security authentication disabled, go to 6.
    • For engines with security authentication enabled, go to 5.

  5. In the displayed Security Authentication dialog box, enter the account name and password, and click OK.

  6. Click the microservice to be governed.
  7. Click Service Degradation.
  8. Click New and select a proper policy. The following table describes the configuration items of service degradation.

    Figure 5 Configuring service degradation (for microservices accessed through Spring Cloud)

    Figure 6 Configuring service degradation (for microservices accessed through Java chassis)

    Configuration Item

    Description

    Fallback Object

    Microservice to be degraded.

    Request Path

    Click and set Method, Path, and Headers to specify the request path.

    NOTE:

    This configuration applies to microservices accessed through Spring Cloud.

    Fallback

    • Open
    • Close

  9. Click OK.

Configuring Fault Tolerance

  1. Log in to CSE.
  2. Choose Exclusive ServiceComb Engines.
  3. Click the target engine.
  4. Choose Microservice Governance.

    • For engines with security authentication disabled, go to 6.
    • For engines with security authentication enabled, go to 5.

  5. In the displayed Security Authentication dialog box, enter the account name and password, and click OK.

  6. Click the microservice to be governed.
  7. Click Fault Tolerance.
  8. Click New and select a proper policy. The following table describes the configuration items of fault tolerance.

    Figure 7 Configuring fault tolerance (for microservices accessed through Spring Cloud)
    Figure 8 Configuring fault tolerance (for microservices accessed through Java chassis)

    Configuration Item

    Description

    Downstream Microservice

    Configure fault tolerance for the microservice to invoke the downstream microservice. You can select a value from the drop-down list.

    NOTE:

    This configuration applies to microservices accessed through Spring Cloud.

    Fault Tolerance Object

    Microservice or method that the application relies on.

    NOTE:

    This configuration applies to microservices accessed through Java chassis.

    Fault Tolerance

    Open: The system processes a request sent to the fault tolerance object based on the selected fault tolerance policy when the request encounters an error.

    Close: The system waits until the timeout interval expires and then returns the failure result even though the service request fails to be implemented.

    FT Policy

    This parameter is mandatory when Fault Tolerance is set to Open.

    For microservices accessed through Spring Cloud, set the following parameters:
    • Number of attempts to the same microservice instance
    • Number of attempts to the new microservice instance
    For microservices accessed through Java chassis, set the following parameters:
    • Failover

      The system attempts to reestablish connections on different servers.

    • Failfast

      The system does not attempt to reestablish a connection. After a request fails, a failure result is returned immediately.

    • Failback

      The system attempts to reestablish connections on the same server.

    • custom
      • Number of attempts to reestablish connections on the same server
      • Number of attempts to reestablish connections on new servers

  9. Click OK.

Configuring Circuit Breaker

  1. Log in to CSE.
  2. Choose Exclusive ServiceComb Engines.
  3. Click the target engine.
  4. Choose Microservice Governance.

    • For engines with security authentication disabled, go to 6.
    • For engines with security authentication enabled, go to 5.

  5. In the displayed Security Authentication dialog box, enter the account name and password, and click OK.

  6. Click the microservice to be governed.
  7. Click Circuit Breaker.
  8. Click New and select a proper policy. The following table describes the configuration items of circuit breaker.

    Figure 9 Configuring circuit breaker (for microservices accessed through Spring Cloud)
    Figure 10 Configuring circuit breaker (for microservices accessed through Java chassis)

    Configuration Item

    Description

    Downstream Microservice

    Configure circuit breaker for the microservice to invoke the downstream microservice.

    NOTE:

    This configuration applies to microservices accessed through Spring Cloud.

    Circuit Breaker Object

    Microservice or method invoked by the application.

    NOTE:

    This configuration applies to microservices accessed through Java chassis.

    Request Path

    Click and set Method, Path, and Headers to specify the request path.

    NOTE:

    This configuration applies to microservices accessed through Spring Cloud.

    Triggering Condition

    • Circuit Breaker Time Window: circuit breaker duration. The system does not respond to requests within this time window.
    • Request Failure Rate: failure rate of window requests.
    • Window Requests: number of requests received by the window. Circuit breaker is triggered only when Request Failure Rate and Window Requests both reach their thresholds.

  9. Click OK.

Configuring Fault Injection

  1. Log in to CSE.
  2. Choose Exclusive ServiceComb Engines.
  3. Click the target engine.
  4. Choose Microservice Governance.

    • For engines with security authentication disabled, go to 6.
    • For engines with security authentication enabled, go to 5.

  5. In the displayed Security Authentication dialog box, enter the account name and password, and click OK.

  6. Click the microservice to be governed.
  7. Click Fault Injection.
  8. Click New and select a proper policy. The following table describes the configuration items of fault injection.

    Figure 11 Configuring fault injection (delayed)
    Figure 12 Configuring fault injection (fault)

    Configuration Item

    Description

    Injection Object

    Microservices for which fault injection is required. You can specify a method for this configuration item.

    Type

    Type of the fault injected to the microservice.

    • Delayed
    • Fault

    Protocol

    Protocol for accessing the microservice when latency or fault occurs.

    • Rest
    • Highway

    Occurrence Probability

    Probability of latency or fault occurrence.

    Delay Time

    Duration of the latency during microservice access. This parameter is required when Type is set to Delayed.

    HTTP Error Code

    HTTP error code during microservice access. This parameter is required when Type is set to Fault. This error code is an HTTP error code.

  9. Click OK.

Configuring Blacklist and Whitelist

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

The blacklist and whitelist take effect only after public key authentication is enabled. For details, see Configuring Public Key Authentication.

  1. Log in to CSE.
  2. Choose Exclusive ServiceComb Engines.
  3. Click the target engine.
  4. Choose Microservice Governance.

    • For engines with security authentication disabled, go to 6.
    • For engines with security authentication enabled, go to 5.

  5. In the displayed Security Authentication dialog box, enter the account name and password, and click OK.

  6. Click the microservice to be governed.
  7. Click Black and white list.
  8. Click New to add a blacklist or whitelist for the application. The following table describes configuration items of blacklist and whitelist.

    Figure 13 Configuring blacklist and whitelist

    Configuration Item

    Description

    Type

    • Blacklist: Microservices that match the matching rule are not allowed to access the current service.
    • Whitelist: Microservices that match the matching rule are allowed to access the current service.

    Rule

    Use a regular expression.

    For example, if Rule is set to data*, services whose names start with data in the blacklist are not allowed to access the current service, or services whose names start with data in the whitelist are allowed to access the current service.

  9. Click OK.

Configuring Public Key Authentication

Public key authentication is a simple and efficient authentication mechanism between microservices provided by CSE. Its security is based on the reliable interaction between microservices and the service center. That is, the authentication mechanism must be enabled between microservices and the service center. The procedure is as follows:

  1. When the microservice starts, a key pair is generated and the public key is registered with the service center.
  2. Before accessing the provider, the consumer uses its own private key to sign a message.
  3. The provider obtains the public key of the consumer from the service center and verifies the signed message.

To enable public key authentication, perform the following steps:

  1. Enable public key authentication for both the consumer and provider.
    servicecomb:
      handler:
        chain:
          Consumer:
            default: auth-consumer
          Provider:
            default: auth-provider
  2. Add the following dependency to the pom.xml file:
    <dependency> 
        <groupId>org.apache.servicecomb</groupId> 
        <artifactId>handler-publickey-auth</artifactId> 
      </dependency>