Kubernetes environments in Enterprise Distributed Application Service (EDAS) support the end-to-end traffic adjustment feature for Spring Cloud microservices applications. The end-to-end traffic adjustment feature helps you create a traffic adjustment environment in an efficient and flexible manner and route traffic with specific characteristics to applications of a desired version.
Background information
When a new version is available for Spring Cloud applications deployed in a Kubernetes environment in EDAS, traffic with specific characteristics may fail to be routed to the desired version of applications because calls among applications are random. The end-to-end traffic adjustment feature helps you isolate a specific version of an application from other versions in a lane. A lane is equivalent to an independent runtime environment. You can configure a traffic adjustment rule in the lane to route the request traffic that matches the rule to the application of the specified version.
This section describes how to use the end-to-end traffic adjustment feature in the order placement scenario of an e-commerce architecture.
After a customer places an order, the traffic comes in from the ingress application, which can also be a microservices gateway. The ingress application calls the transaction center, the transaction center calls the commodity center, and then the commodity center calls the downstream inventory center.
Both the transaction center and the commodity center are running in two new versions: V1.0 and V2.0. The two versions need to be verified during a canary release. You want to route the request traffic that matches specific traffic adjustment rules in the ingress application to applications of the new versions, and route all the remaining traffic to applications of the online version, which is the official version.
In the preceding flowchart, both the transaction center and the commodity center are running in new versions V1.0 and V2.0. Access requests are randomly forwarded to the applications of the versions, and the traffic cannot be controlled. You can use the end-to-end traffic adjustment feature to configure V1.0 as Lane red and V2.0 as Lane blue and configure traffic adjustment rules in the ingress application. When the request traffic in the ingress application matches the traffic adjustment rule of a lane, the request traffic is routed to the lane.
Terms
ingress application
The entrance of ingress traffic in a microservices system. An ingress application can be a gateway that is built based on Spring Cloud Gateway or Spring Cloud Netflix Zuul, or a Spring Boot, Spring MVC, or Dubbo application.
lane
An isolated environment that is defined for applications of the same version. Only traffic that matches specific traffic adjustment rules can be routed to the applications that are marked in a lane. An application can belong to multiple lanes. A lane can contain multiple applications. Applications have a many-to-many relationship with lanes.
lane group
A collection of lanes. A lane group is used to distinguish different teams or different scenarios.
Limits
After you configure end-to-end traffic adjustment for applications, these applications no longer support a canary release.
If you want to build an ingress gateway based on Spring Cloud Gateway, make sure that the version of Spring Cloud Gateway is 2.1.x or later.
The quotas of lane groups and lanes vary based on the edition of EDAS. The following limits apply:
Standard Edition: You can create up to two lane groups in total for all regions combined, and create up to five lanes in each lane group.
All editions other than Professional Edition and Platinum Edition are Standard Edition.
Professional Edition: You can create up to 20 lane groups in total for all regions combined, and create up to 50 lanes in each lane group.
Platinum Edition: You can create up to 20 lane groups in total for all regions combined, and create up to 50 lanes in each lane group.
You cannot increase the quotas of lane groups and lanes on your own.
If you require larger quotas, join the DingTalk group (group number: 31723701) for technical support.