liveBook · Manning

Traffic splitting

As explained in Google Anthos in Action

Traffic splitting is the controlled distribution of requests among service versions or destinations according to configured proportions or rules.

Traffic splitting distributes requests among multiple versions of a microservice according to configured percentages or rules. Istio and Anthos Service Mesh apply these controls through the service mesh, without changes to application code. section 4.3.2 section 4.2

Use traffic splitting to manage service changes operationally:

  • Redirect a small, controlled share of requests to a new version, validate its behavior, and progressively increase its traffic. section 4.5.3
  • Keep old and new versions active simultaneously when rules require different users or cases to reach different implementations. section 4.5.3
  • Support A/B testing, canary deployments, progressive rollouts, bug fixes, and releases without downtime. section 4.5.3 section 4.6

Progressive fix rollout

After deploying an urgent fix, route a small percentage of incoming requests to the new version. Verify that the fix works, increase its share, and eventually direct all traffic to it; retain both versions when only selected cases need the fix. section 4.5.3

Table 4.1 Istio traffic management features (view table figure)

Feature

Description

Ingress

Controls the ingress traffic for the service mesh, to expose a service outside the service mesh over TLS or mTLS using the Istio gateway. In another chapter, we will deep-dive into ingress for Anthos.

Egress

Controls the egress traffic from the service mesh, routes traffic to an external system, performs TLS for outbound traffic, and configures the outbound gateway to use an HTTPS proxy.

Request routing and traffic splitting

Dynamically routes the traffic to multiple versions of the microservice or migrates traffic from one version to another version gradually and in a controlled way.

Fault injection

Provides configurable HTTP delays and fault injection with an HTTP status code, allowing developers to discover problems before they would occur in production.

Compare traffic splitting with related Istio controls for ingress, egress, request routing, and fault injection. section 4.3.2

How Google Anthos in Action covers it

How deep it goes
Explains percentage- and rule-based routing, progressive migration, and fault simulation but does not provide configuration syntax.
Examples
Uses an urgent microservice fix, percentage-based canary rollout, rule-based parallel versions, and fault-injection scenarios.
What it assumes
Assumes familiarity with microservices and service meshes while treating application-code changes as unnecessary for traffic control.
What you can do after
Operate progressive releases by directing, validating, increasing, and eventually migrating traffic between service versions.
How it connects
Connects traffic splitting with service meshes, Istio, Anthos Service Mesh, request routing, A/B testing, canary deployments, and rolling releases.

Also explained in

Compare how 2 books explain traffic splitting →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Google Anthos in Action. The section links point to the parts of the book it draws on.