Microservices Governance module is a micro-service governance sub-module launched by Spring Cloud Alibaba, which provides various types of microservices governance capabilities, including label routing, service authentication, etc. Moreover, it supports various control planes, such as Istio and OpenSergo, so that users can get the governance rules in real time without modifying Spring Cloud applications, and apply these rules to applications to govern the Spring Cloud application.
Spring Cloud Alibaba Governance is a Microservices governance capabilities provided by Spring Cloud Alibaba, which provides various types of microservices governance capabilities, including label routing, service authentication, etc. Moreover, it supports various control planes, such as https://istio.io/[Istio] and http://opensergo.io/[OpenSergo], so that users can get the governance rules in real time just adding relevant dependency, and apply these rules to applications to govern the Spring Cloud Alibaba application.
=== Resource-Transform
=== ResourceTransform
image::pic/resource-transform.png[]
The resource-transform module of Microservices Governance will uniformly transform the configurations published by different control planes, like Istio and OperSergo, into the unified abstract data structure of Spring Cloud Alibaba for subsequent use.
The resource-transform adapter of Microservices Governance will uniformly transform the rules published by different control planes, like Istio and OperSergo, into the unified abstract data structure of Spring Cloud Alibaba for subsequent use.
If you use Istio in your project to transform the configuration, you need to use a following starter:
If you use Istio in your project to transform the rule, first of all, note that you need to build a Kubernetes cluster and deploy Istio in it. For details, refer to https://istio.io/latest/zh/docs/setup/install[Istio installation], you need to add a following starter dependency application(Generally added to service consumer application):
[source,xml,indent=0]
----
<dependency>
@ -74,10 +74,10 @@ Load balance Component: Ribbon
In the future, more components such as RestTemplate, Spring Cloud LoadBalancer and so on will be supported.
==== Using
With the introduction of the configuration transformation module, we can obtain the governance rules to give the Spring Cloud application some governance capabilities. Label routing module can route the Spring Cloud application according to the request header, request parameters and other tags to route to different services.
==== Using Routing capacity
With the introduction of the transformation adapter of rule, we can obtain the governance rules to give the Spring Cloud application some governance capabilities. Label routing module can route the Spring Cloud application according to the request header, request parameters and other tags to route to different services.
If you use Microservices Governance Label Routing in your project, You need to use a following starter:
If you use Microservices Governance Label Routing in your project, You need to use a following starter dependency(Generally added to service consumer application):
[source,xml,indent=0]
----
<dependency>
@ -92,7 +92,7 @@ If no configuration,use default ribbon load balance algorithm ZoneAvoidanceRule.
spring.cloud.governance.routing.rule=RandomRule
----
With the introduction of Istio Resource Transform module, the label routing module supports routing of the following types of request meta-information:
With the introduction of Istio Resource Transform adapter, the label routing module supports routing of the following types of request meta-information:
* Request Path
* Request Header
@ -107,7 +107,7 @@ We use Istio to publish corresponding `DestinationRule` and `VirtualService` to
=== Authentication
image::pic/auth-process.png[]
With the introduction of the configuration transformation module, we can obtain the governance rules to give the Spring Cloud application some governance capabilities. The Authentication module provides various authentication modes for Spring Cloud applications, such as IP blacklist and whitelist and JWT authentication.
With the introduction of the transformation adapter of rule, we can obtain the governance rules to give the Spring Cloud application some governance capabilities. The Authentication module provides various authentication modes for Spring Cloud applications, such as IP blacklist and whitelist and JWT authentication.
Add following Microservices Authentication starter:
@ -57,13 +56,13 @@ Here's an explanation of each field:
|Whether to connect to Istio to obtain authentication configuration| spring.cloud.istio.config.enabled|true|
|Host of Istiod| spring.cloud.istio.config.host|127.0.0.1|
|Port of Istiod| spring.cloud.istio.config.port|15012|15010 port does not need TLS，but 15012 does
|Thread pool size for SCA to pull the config| spring.cloud.istio.config.polling-pool-size|10|
|Time interval for SCA to pull the config| spring.cloud.istio.config.polling-time|30|The unit is second|
|JWT token for SCA to connect to 15012 port| spring.cloud.istio.config.istiod-token|Content of file `/var/run/secrets/tokens/istio-token` in the pod of application|
|Thread pool size for application to pull the config| spring.cloud.istio.config.polling-pool-size|10|
|Time interval for application to pull the config| spring.cloud.istio.config.polling-time|30|The unit is second|
|JWT token for application to connect to 15012 port| spring.cloud.istio.config.istiod-token|Content of file `/var/run/secrets/tokens/istio-token` in the pod of application|
|Whether to print logs about xDS| spring.cloud.istio.config.log-xds|true|
### Run the application
You need to run the application in the K8s environment and inject some meta information about K8s into the following environment variables for the running application:
Note that the application runs in the K8s environment, and the application in the non-default namespace needs to receive the rules issued by Istiod, and needs to inject the meta information of the running application Kubernetes into the following environment variables. For the specific operation method, please refer to [Kubernetes documentation](https://kubernetes.io/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information):
|Environment variable name|K8s pod metadata name|
|--|--|
|POD_NAME|metadata.name|
@ -74,7 +73,7 @@ You need to run the application in the K8s environment and inject some meta info
The following are some simple examples of authentication rule configurations:
#### IP Blocks
The following command is used to deliver an authentication rule to the demo application through Istio. This rule restricts the source IP addresses that can access the application:
```
```YAML
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
@ -105,7 +104,7 @@ If the source IP of the request is not '127.0.0.1', then the application returns
```
received request from ${from_ip}, local addr is ${local_ip}, local host is ${local_host}, request path is/auth
```
It indicates that the request has been authenticated by SCA and some meta data of the request will be returned.
It indicates that the request has been authenticated by application and some meta data of the request will be returned.
After that, we delete the authentication rule for the IP Blocks:
```shell
@ -118,7 +117,7 @@ received request from ${from_ip}, local addr is ${local_ip}, local host is ${loc
#### Request Header Authentication
We use the following command to deliver an authentication rule to the demo application through Istio. This rule restricts the request header for accessing the application:
```
```YAML
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
@ -165,7 +164,7 @@ received request from ${from_ip}, local addr is ${local_ip}, local host is ${loc
#### JWT Authentication
We use the following command to deliver an authentication rule to the demo application through Istio. This rule restricts the JWT token value that must be carried to access the application:
This project demonstrates how to use the spring cloud ailbaba governance routing module to complete the label routing function.
This project demonstrates how to use the Spring Cloud Alibaba Governance Routing module to complete the routing capacity.
## module structure
## Module structure
This module includes a consumer instance and a provider cluster, which contains two instances.
@ -23,7 +23,7 @@ In the future, more components such as RestTemplate, Spring Cloud LoadBalancer a
### How to access
**Note that this section is only for your convenience in understanding the access method. The access work has been completed in this sample code, and you do not need to modify it.**
1. First, modify the pom XML file, which introduces the spring cloud ailbaba governance labelrouting dependency.
1. First, modify the pom XML file, which introduces the Spring Cloud Alibaba governance routing dependency.
```xml
<dependency>
<groupId>com.alibaba.cloud</groupId>
@ -84,7 +84,7 @@ public void getDataFromControlPlaneTest() {
}
```
The rules corresponding to the code are as follows:
If the request parameter contains tag=gray and the request header contains id and the value is greater than 10, uri is /router-test at the same time, the traffic is routed to the v2 version. If one of the request parameters does not meet the requirement, the traffic is routed to the v1 version.
If the request parameter contains tag=gray and the request header contains id and the value is greater than 10, uri is `/router-test` at the same time, the traffic is routed to the v2 version. If one of the request parameters does not meet the requirement, the traffic is routed to the v1 version.
Rules also support dynamic modification. The rules for testing dynamic modification are as follows:
```java
@ -129,9 +129,9 @@ public void getDataFromControlPlaneTest() {
}
```
The rules corresponding to the code are as follows:
If the request parameter contains tag=gray, and the request header contains id and the value is greater than 10,uri is /router-test, 50% of the traffic is routed to the v2 version, and the rest is routed to the v1 version. If one of the traffic does not meet the requirements, the traffic is routed to the v1 version.
If the request parameter contains tag=gray, and the request header contains id and the value is greater than 10, URL is `/router-test`, 50% of the traffic is routed to the v2 version, and the rest is routed to the v1 version. If one of the traffic does not meet the requirements, the traffic is routed to the v1 version.
##### demonstrate Steps
##### demonstration Steps
1. visit http://localhost:18083/add Push the routing rules from the control surface interface to the routing rule warehouse
visit http://localhost:18083/router -The test does not meet the routing rules. When the test is routed to the v1 version, the v1 version instance prints and returns the following results:
```
@ -165,8 +165,8 @@ Please refer to [tools](https://kubernetes.io/zh-cn/docs/tasks/tools/) chapter o
### Enable Istio on K8s
Please refer to [install](https://istio.io/latest/zh/docs/setup/install/) chapter of Istio document.
1. First, modify the pom.xml file to introduce the `spring-cloud-starter-alibaba-governance-routing` and `spring-cloud-starter-xds-adapter` dependency
```xml
<dependency>
@ -179,7 +179,7 @@ Please refer to [install](https://istio.io/latest/zh/docs/setup/install/) chapte
</dependency>
```
2. Configure application.yml for Istio control plane:
```
```YAML
server:
port: 18084
spring:
@ -220,7 +220,7 @@ Start IstioConsumerApplication and two ProviderApplications, and inject it into
### Publish Configuration
We publish the label routing rules through the Istio control plane. We publish a DestinationRule rule first:
```
```YAML
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
@ -239,7 +239,7 @@ EOF
```
This rule splits the back-end service into two versions. Pod with label v1 is assigned to v1, and pod with label v2 is assigned to v2
After that, we publish the VirtualService rule:
```
```YAML
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
@ -265,8 +265,8 @@ spec:
subset: v1
EOF
```
This VirtualService specifies the simplest label routing rule. HTTP requests with a gray header and /istio-label-routing path are routed to v2, and the rest of the traffic is routed to v1:
### Demonstrate effect
This VirtualService specifies the simplest label routing rule. HTTP requests with a gray header and `/istio-label-routing` path are routed to v2, and the rest of the traffic is routed to v1:
### Demonstration effect
We send an HTTP request without a request header to IstioConsumerApplication:
```
curl --location --request GET '127.0.0.1:18084/istio-label-routing'
@ -275,7 +275,7 @@ Since the request header is not gray, the request will be routed to version v1 w
```
Route in 30.221.132.228: 18081,version is v1.
```
We then send an HTTP request with a gray tag in its header and the request path is /istio-label-routing:
We then send an HTTP request with a gray tag in its header and the request path is `/istio-label-routing`:
```
curl --location --request GET '127.0.0.1:18084/istio-label-routing' --header 'tag: gray'
```
@ -283,27 +283,28 @@ The request is routed to version v2 because the routing rule is matched by the r
After the rule is deleted, the routing policy is not determined by whether the request header is carried or not, but completely depends on the implementation of the loadbalancer。
After the rule is deleted, the routing policy is not determined by whether the request header is carried or not, but completely depends on the implementation of the loadbalancer.
## Integrating OpenSergo
**Note that this section is only for your convenience in understanding the access method. The access work has been completed in this sample code, and you do not need to modify it.**
### Configure
1. First, modify the pom.xml file to introduce the `spring-cloud-starter-alibaba-governance-routing` and `spring-cloud-starter-opensergo-adapter` dependency
1. First, modify the `pom.xml` file to introduce the `spring-cloud-starter-alibaba-governance-routing` and `spring-cloud-starter-opensergo-adapter` dependency
Start OpenSergoConsumerApplication and two ProviderApplications, and inject it into the Nacos registry center.
### Publish Configuration
[First start OpenSergo control plan](https://opensergo.io/docs/quick-start/opensergo-control-plane/) , Then we publish the label routing rules through the OpenSergo control plane. We publish a TrafficRouter rule.
```
```YAML
kubectl apply -f - <<EOF
apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficRouter
@ -353,7 +354,7 @@ Since the request header is not gray, the request will be routed to version v1 w
```
Route in 30.221.132.228: 18081,version is v1.
```
We then send an HTTP request with a gray tag in its header and the request path is /istio-label-routing
We then send an HTTP request with a gray tag in its header and the request path is `/istio-label-routing`:
```
curl --location --request GET '127.0.0.1:18083/router-test' --header 'tag: gray'
Steve Rao
2 years ago
committed by
GitHub