Divide Plug-in Usage

First, start the project

Soul-bootstrap (9195) and soul-admin (9095) are used for data synchronization through WebSocket. Bootstrap (9195) and soul-admin (9095)

You can also see from the bootstrap log:

Data synchronization refers to synchronizing data configured in soul-admin into the JVM memory in the Soul cluster, which is key to the gateway’s high performance.

After we started both projects, we were ready to test The Divide plug-in through the admin system.

Two, Divide plug-in introduction

Divide is the gateway’s core processing plug-in for HTTP requests, and is the only plug-in soul has enabled by default:

We can imagine what a gateway does and guess what Divide plug-ins that handle HTTP requests might do.

Divide as a microservice gateway, there must be distributed microservice cluster with multiple service lines behind it. As a unified gateway for all services, the gateway must have the capabilities of traffic distribution, routing, load balancing, etc. So we can guess that Divide is simply routing-forwarding of HTTP requests with various rules, which is the gateway’s most basic capability.

When we open the list of plug-ins on the admin interface, we can see that all plug-ins are made up of two parts: selectors and selector rules.

Plug-in design idea is the core design idea of soul gateway, and the two concepts of selector and rule are soul of soul gateway, theoretically speaking, we master it, we can manage the flow of any access gateway.

A plug-in has multiple selectors, and one selector corresponds to multiple rules. The selector is the first filter of traffic, and the rule is the final filter.

The selector

** * Name ** : Give your selector an easily distinguishable name ** * Type ** : Custom Flow is a custom flow. Full flow is full flow. Custom traffic is a request that will walk you through the following matching methods and conditions. Full traffic does not go. ** * Matching method ** : AND or OR refers to whether the following conditions are combined according to and or OR. ** * Criteria ** : * URI: indicates that you filter traffic based on uri, and match supports fuzzy matching (/**) * header: indicates that you filter traffic based on fields in the request header. * query: Filters traffic based on the query criteria of the URI. * IP: Filters traffic based on the real IP address you request. * host: filters traffic based on the actual host you requested. * POST: Do not use it. * Conditional matching: * match: Fuzzy matching, matching suggestions with URI conditions, supporting restful matching. (/test/**) * = : Matches the values before and after the test. * regEx: matches the previous value to the following regular expression. * like: string fuzzy match. ** * Enabled or not ** : This function takes effect only when enabled ** * Prints logs ** : When enabled, matching logs will be printed when matched. ** * Order of execution ** : When there are multiple selectors, the smaller order of execution takes precedence.Copy the code

Selector rule

As you can see, the configuration of rules is similar to that of selectors and can be interpreted as a more fine-grained custom configuration.

Three, Divide plug-in use

Without further ado, let’s run the Examples module provided by Soul directly to demonstrate divide.

Notice that we ended up running the soul-examples-HTTP module. The configuration file can use the default or customize contextPath and appName, as shown in the figure above.

Note that the contextPath property is so important that it acts as a namespace and selector alignment for all of our HTTP requests. Generally speaking, one service can be configured with one contextPath, and multiple service instances with the same contextPath configured under one service will be automatically mapped to the same selector for load balancing.

Divide: Selectors/rules configured for divide: Selectors/rules configured for Divide

You can see that the address of the 8188 project I started is automatically registered:

Testing gateway Routing

Postman test without gateway forwarding:

http://localhost:8188/order/findById?id=1
Copy the code

Then test forwarding through the gateway to this interface:

http://localhost:9195/my-http/order/findById?id=1
Copy the code

After checking the log, it was found that the address of interface 8188 was indeed forwarded through the gateway:

Test load balancing

We change the port to 8189 and start the second process.

Note that IDEA needs to remove the restriction on Single instance only:

After entering the administrative console, two configuration addresses appear under the my-HTTP selector:

At this point we continued testing and found that the load balancing policy did work:

Today we demonstrated the most basic configuration of Divide, and there are a variety of other rule configurations that you can try later