Mixer

The page explains Mixer’s role and general architecture.

Background

Infrastructure backends are designed to provide support functionality that is used to build services. They include such things as access control systems, telemetry capturing systems, quota enforcement systems, billing systems, and so forth. Services traditionally directly integrate with these backend systems, creating a hard coupling and baking-in specific semantics and usage options.

Mixer provides a generic intermediation layer between application code and infrastructure backends. Its design moves policy decisions out of the app layer and into configuration instead, under operator control. Instead of having application code integrate with specific backends, the app code instead does a fairly simple integration with Mixer, and Mixer takes responsibility for interfacing with the backend systems.

Mixer is designed to change the boundaries between layers in order to reduce systemic complexity, eliminating policy logic from service code and giving control to operators instead.

Mixer Traffic Flow

Mixer provides three core features:

• Precondition Checking. Enables callers to verify a number of preconditions before responding to an incoming request from a service consumer. Preconditions can include whether the service consumer is properly authenticated, is on the service’s whitelist, passes ACL checks, and more.

• Quota Management. Enables services to allocate and free quota on a number of dimensions. Quotas are used as a relatively simple resource management tool to provide some fairness between service consumers when contending for limited resources. Rate limits are examples of quotas.

• Telemetry Reporting. Enables services to report logging and monitoring. In the future, it will also enable tracing and billing streams intended for both the service operator as well as for service consumers.

These mechanisms are applied based on a set of attributes that are materialized for every request into Mixer. Within Istio, the attributes are generated by a sidecar proxy (typically, Envoy) per request.

Adapters

Mixer is a highly modular and extensible component. One of it’s key functions is to abstract away the details of different policy and telemetry backend systems, allowing Envoy and Istio-based services to be agnostic of those backends, which keeps them portable.

Mixer’s flexibility in dealing with different infrastructure backends is achieved by having a general-purpose plug-in model. Individual plug-ins are known as adapters and they allow Mixer to interface to different infrastructure backends that deliver core functionality, such as logging, monitoring, quotas, ACL checking, and more. Adapters enable Mixer to expose a single consistent API, independent of the backends in use. The exact set of adapters used at runtime is determined through configuration and can easily be extended to target new or custom infrastructure backends.

Mixer and its Adapters

Configuration state

Mixer’s core runtime methods (Check and Report) accept a set of attributes on input. Mixer’s current configuration dictates the work that the individual methods perform with the set of input attributes. To that end, the service operator is responsible for:

• Configuring a set of handlers for Mixer-generated data. Handlers are configured adapters (adapters being binary plugins as described below). Providing a statsd adapter with the IP address for a statsd backend is an example of handler configuration.

• Configuring a set of instances for Mixer to generate based on attributes and literal values. They represent a chunk of data that adapter code will operate on. For example, an operator may configure Mixer to generate request_count metric values from attributes such as destination.service and response.code.

• Configuring a set of rules that Mixer will execute for each request. Rules consist of a match expression and actions. The match expression controls when Mixer will execute the specified actions. Actions specify the set of instances to generate and the handlers that should process the generated instances. For example, a rule might tell Mixer to send generated requestcount instances to a statsd handler for all Report calls.

The above configuration state is required to have Mixer know what to do with incoming attributes and dispatch to the appropriate infrastructure backends.

Refer here for detailed information on Mixer’s configuration model.

Request phases

When a request comes in to Mixer, it goes through a number of distinct handling phases:

• Supplementary Attribute Production. Mixer initially runs a globally configured set of adapters that are responsible for introducing new attributes. These attributes are combined with the attributes from the request to form the total set of attributes for the operation.

• Resolution. The second phase is to evaluate the set of attributes to determine the effective configuration to apply for the request. See here for information on how resolution works. The effective configuration determines the set of aspects and descriptors available to handle the request in the subsequent phases.

• Attribute Processing. The third phase takes the total set of attributes and produces a set of adapter parameters. Attribute processing is initially configured through a simple declarative form as described here.

• Adapter Dispatching. The Resolution phase establishes the set of available aspects and the Attribute Processing phase creates a set of adapter parameters. The Adapter Dispatching phase invokes the adapters associated with each aspect and passes them those parameters.

Request Phases

What’s next

• Read the blog post describing Mixer’s adapter model.