In the previous article, we showed how to store traffic limiting rules through Nacos configuration. Apollo is a configuration center with many users in China. Therefore, today we continue to talk about how to store flow control rules in Spring Cloud Alibaba Sentinel in Apollo.

Use Apollo to store limiting rules

Sentinel itself supports a variety of different data sources to persist rule configurations, including the following methods:

  • Configuration file
  • Nacos configuration
  • ZooKeeper configuration
  • Apollo configuration

In this article, we will take a hands-on look at how to use Apollo to store limiting rules.

The preparatory work

We’re going to be using Both Apollo and Sentinel Dashboards, so let’s get Apollo and Sentinel up and running.

If you’re not already getting started with Sentinel Dashboard you can learn from the series of directories at the end of this article. Apollo is a bit more complicated, so I won’t go into details here, but for those who haven’t been exposed to Apollo, check out its official documentation.

Application configuration

Step 1: Introduce Spring Cloud Alibaba’s Sentinel module and Apollo storage extension in the Pom.xml of the Spring Cloud application:

 <dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
    </dependency>
    <dependency>
        <groupId>com.alibaba.csp</groupId>
        <artifactId>sentinel-datasource-apollo</artifactId>
        <version>1.4.0</version>
    </dependency>
</dependencies>
Copy the code

Step 2: Create a file named Apollo-env.properties in the resource directory for the Spring Cloud application.

Local. Meta = http://192.168.0.201:8080 dev. Meta = http://192.168.0.202:8080Copy the code

Here we need to know Apollo’s configuration of multiple environments. Here we set different configuration service addresses for each environment. Readers need to modify them according to their own actual situation.

Step 3: Add configuration information to the Spring Cloud application:

spring.application.name=sentinel-datasource-apollo
server.port=8002

# apollo config
app.id=${spring.application.name}

# sentinel dashboard
spring.cloud.sentinel.transport.dashboard=localhost:8080

# sentinel datasource apollo
spring.cloud.sentinel.datasource.ds.apollo.namespaceName=application
spring.cloud.sentinel.datasource.ds.apollo.flowRulesKey=sentinel.flowRules
Copy the code
  • app.id: Name of the project created in Apollo, used herespring.application.nameParameter to match the service name with the configured project name
  • spring.cloud.sentinel.transport.dashboard: Access address for Sentinel Dashboard, as configured from the instance started in the preparation above
  • spring.cloud.sentinel.datasource.ds.apollo.namespaceName: Space name of Apollo
  • spring.cloud.sentinel.datasource.ds.apollo.flowRulesKey: Indicates the key name of the configuration rule

The corresponding relationship between Apollo configurations is shown in the following figure:

Step 4: Create the application main class and provide a REST interface, such as:

@EnableApolloConfig
@SpringBootApplication
public class TestApplication {

    public static void main(String[] args) {
        SpringApplication.run(TestApplication.class, args);
    }

    @Slf4j
    @RestController
    static class TestController {

        @GetMapping("/hello")
        public String hello(a) {
            return "didispace.com"; }}}Copy the code

The @enableApolloConfig annotation enables configuration loading for Apollo.

Step 5: Configure traffic limiting rules in Apollo, as shown in the screenshot of Step 3. Where the contents of the key value are the following JSON

[{"resource": "/hello"."limitApp": "default"."grade": 1."count": 5."strategy": 0."controlBehavior": 0."clusterMode": false}]Copy the code

As you can see, the configuration rule above is an array type. Each object in the array is a configuration object for each protected resource. The attributes in each object are explained as follows:

  • Resource: indicates the name of the resource, which is the object of the traffic limiting rule
  • LimitApp: call source of flow control. If it is default, call source is not differentiated
  • Grade: indicates the type of traffic limiting threshold (QPS or number of concurrent threads).0Represents limiting traffic according to the number of concurrent requests,1Represents flow control according to QPS
  • Count: traffic limiting threshold
  • Strategy: Invokes the relational traffic limiting policy
  • ControlBehavior: Flow control effect (direct reject, Warm Up, uniform queuing)
  • ClusterMode: indicates whether the clusterMode is used

Here we only do a simple configuration explanation, so that you can understand the configuration function. In fact, there are many more configurable options and rules, and we’ll cover more complex configurations in a separate article.

Step 6: Launch the application. If something goes well, you can see a log like the following, which indicates that a traffic limiting rule has been successfully loaded from Nacos:

The 2019-04-18 23:56:11. 29149-278 the INFO [the main] O.S.C.A.S.C.S entinelDataSourceHandler: [Sentinel Starter] DataSource DS-sentinel - Apollo - DataSource start to loadConfig 2019-04-18 23:56:11.279 INFO 29149 -- [Sentinel Starter] DataSource DS-sentinel - Apollo - DataSource start to loadConfig 2019-04-18 23:56:11.279 INFO 29149 -- [  main] o.s.c.a.s.c.SentinelDataSourceHandler : [Sentinel Starter] DataSource ds-sentinel-apollo-datasource load 1 FlowRuleCopy the code

Localhost :8002/hello:

$ curl localhost:8002/hello
didispace.com
Copy the code

At this point, you can see the Sentinel-Datasource-Apollo service we’re currently launching in Sentinel Dashboard. Click flow control rules in the menu on the left, and you can see that there is already a record, which is the flow limiting rule configured in Apollo above.

Deep thinking

As with Nacos storage when configured using Apollo storage rules, the data is read-only for the Sentinel console, that is:

  • Change rule in Sentinel console: only exists in the memory of the service. The configuration value in Apollo will not be changed. After restart, the original value will be restored.
  • Change rules in Nacos console: The in-memory rules of the service are updated, as are the persistent rules in Apollo, which remain unchanged after a restart.

Code sample

Sample readers of the client code for this article can check out the Alibaba-Sentinel-Datasource-Apollo project in the repository below:

  • Making:Github.com/dyc87112/Sp…
  • Gitee:Gitee.com/didispace/S…

If you are interested in these, welcome to star, follow, favorites, forward to give support!

The resources

Here are Sentinel’s warehouse addresses and official documents, or you can read them for yourself:

  • Github
  • Sentinel official documentation: Dynamic Rules
  • Spring Cloud Alibaba Sentinel documentation

Series of review

  • Spring Cloud Alibaba Basics: Service Registration and Discovery using Nacos
  • Spring Cloud Alibaba Basic Tutorial: Several service Consumption Modes supported
  • Spring Cloud Alibaba Basics: Using Nacos as the Configuration Center
  • Spring Cloud Alibaba Basic Tutorial: Details of Nacos Configuration loading rules
  • Spring Cloud Alibaba Basics: Managing Multiple Environments for Nacos Configurations
  • Spring Cloud Alibaba Basics tutorial: Multi-file Loading and Sharing configuration for Nacos Configuration
  • Spring Cloud Alibaba Basics tutorial: Data Persistence in Nacos
  • Spring Cloud Alibaba Basics tutorial: Cluster Deployment of Nacos
  • Spring Cloud Alibaba Basic Tutorial: Implementing Interface Flow Limiting with Sentinel
  • Spring Cloud Alibaba Basics tutorial: Sentinel with Nacos storage Rules
  • Spring Cloud Alibaba: Sentinel with Apollo Storage Rules

Special recommendation

  • Spring Boot Basics tutorial
  • Spring Cloud Basics tutorial