In Kubernetes clusters, Enterprise Distributed Application Service (EDAS) supports the end-to-end traffic adjustment feature for Spring Cloud microservices-based applications. The end-to-end traffic adjustment feature helps you create a traffic adjustment environment with ease and route traffic with specific characteristics to applications of a specified version.

Background information

In EDAS, part of Spring Cloud applications that are deployed in Kubernetes clusters may be updated to a specific version. In this case, traffic with specific characteristics may fail to be routed to applications of a desired version. This is because applications call each other randomly. The end-to-end traffic adjustment feature can help you isolate applications of a version from others in a lane, which is an independent runtime environment. You can set traffic adjustment rules in the lane to route the request traffic that meets the rules to applications 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 microservice 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 new versions V1.0 and V2.0. The two versions need to be verified during a canary release. At this time, you want to route the request traffic that meets 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 applications of each version and the traffic cannot be throttled. You can use the end-to-end traffic adjustment feature to configure V1.0 as Lane red and V2.0 as Lane blue and set traffic adjustment rules in the ingress application. When the request traffic in the ingress application meets the traffic adjustment rules of a lane, the request traffic is routed to the lane.

Terms

  • Ingress application

    The ingress of traffic in a microservice system. An ingress application can be a service 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 the request traffic that meets the traffic adjustment rules of a lane can be routed to the applications that are configured to receive the marked traffic in the 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 the end-to-end traffic adjustment feature for applications, these applications no longer support a canary release.
  • The quotas of lane groups and lanes vary based on the edition of EDAS. The following limits apply:
    • Standard Edition: All regions can contain only one lane group. This lane group can contain up to five lanes.

      All editions other than Professional Edition and Platinum Edition are Standard Edition.

    • Professional Edition: All regions can contain a maximum of 10 lane groups. Each lane group can contain up to 50 lanes.
    • Platinum Edition: All regions can contain a maximum of 10 lane groups. Each lane group can contain up to 50 lanes.
  • The quotas of lane groups and lanes cannot be increased.