mirror of https://github.com/istio/istio.io.git
135 lines
6.4 KiB
Markdown
135 lines
6.4 KiB
Markdown
---
|
|
title: Mixer
|
|
overview: Architectural deep-dive into the design of Mixer, which provides the policy and control mechanisms within the service mesh.
|
|
|
|
order: 20
|
|
|
|
layout: docs
|
|
type: markdown
|
|
---
|
|
|
|
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.
|
|
|
|
<figure><img style="max-width:60%;" src="./img/mixer/traffic.svg" alt="Showing
|
|
the flow of traffic through Mixer." title="Mixer Traffic Flow" />
|
|
<figcaption>Mixer Traffic Flow</figcaption></figure>
|
|
|
|
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](./attributes.html)
|
|
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.
|
|
|
|
<figure><img style="max-width:35%;" src="./img/mixer/adapters.svg" alt="Showing
|
|
Mixer with adapters." title="Mixer and its Adapters" /></figure>
|
|
|
|
## 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](#adapters)). 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, an 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](./mixer-config.html) 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](./mixer-config.html#resolution) 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](./mixer-config.html).
|
|
|
|
- **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.
|
|
|
|
<figure><img style="max-width:50%;" src="./img/mixer/phases.svg" alt="Phases of
|
|
Mixer request processing." title="Request Phases" /> <figcaption>Request
|
|
Phases</figcaption></figure>
|