istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update Mixer concept doc (#476) 

* Update Mixer concept doc

* Address review comments
This commit is contained in:
Douglas Reid 2017-09-21 09:44:26 -07:00 committed by Shriram Rajagopalan
parent 5b9b4165b5
commit 55deea2a60
2 changed files with 88 additions and 78 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
_docs/concepts/policy-and-control/mixer-config.md
View File

@ -335,8 +335,6 @@ that conform to the descriptor's shape (it's value type and its set of labels).
- Descriptors can be referenced and reused from multiple aspects. - Descriptors can be referenced and reused from multiple aspects.
- It enables Istio to provide a strongly-typed scripting environment as discussed [here](./mixer.html#scripting)
The different descriptor types are detailed in [here]({{home}}/docs/reference/config/mixer/mixer-config.html). The different descriptor types are detailed in [here]({{home}}/docs/reference/config/mixer/mixer-config.html).
### Scopes ### Scopes

164
_docs/concepts/policy-and-control/mixer.md
View File

@ -12,111 +12,123 @@ The page explains Mixer's role and general architecture.
## Background ## Background
Infrastructure backends are designed to provide support functionality that is used to build services. Infrastructure backends are designed to provide support functionality that is
They include such things as access control systems, telemetry capturing systems, quota enforcement used to build services. They include such things as access control systems,
systems, billing systems, and so forth. Services traditionally directly integrate with these telemetry capturing systems, quota enforcement systems, billing systems, and so
backend systems, creating a hard coupling and baking-in specific semantics and usage options. 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. Mixer provides a generic intermediation layer between application code and
Its design moves policy decisions out of the app layer and into configuration instead, under operator control. infrastructure backends. Its design moves policy decisions out of the app layer
Instead of having application code integrate with specific backends, the app code instead does a fairly simple and into configuration instead, under operator control. Instead of having
integration with Mixer, and Mixer takes responsibility for interfacing with the backend systems. 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 *not* designed to create a _portability layer_ on top of infrastructure backends. It's not about trying to Mixer is designed to change the boundaries between layers in order to reduce
just define a universal logging API, universal metric API, universal billing API, and so forth. Instead, Mixer is designed to systemic complexity, eliminating policy logic from service code and giving
change the boundaries between layers in order to reduce systemic complexity, eliminating policy logic from service code and giving control control to operators instead.
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" /> <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> <figcaption>Mixer Traffic Flow</figcaption></figure>
Mixer provides three core features: 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. - **Precondition Checking**. Enables callers to verify a number of preconditions
Preconditions can include whether the service consumer is properly authenticated, is on the service's whitelist, passes ACL checks, and more. 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 - **Quota Management**. Enables services to allocate and free quota on a number
management tool to provide some fairness between service consumers when contending for limited resources. Rate limits are of dimensions. Quotas are used as a relatively simple resource management tool
examples of quotas. 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 - **Telemetry Reporting**. Enables services to report logging and monitoring. In
streams intended for both the service operator as well as for service consumers. 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 These mechanisms are applied based on a set of [attributes](./attributes.html)
materialized for every request into Mixer. Within Istio, Envoy depends heavily on Mixer. Services running within the mesh that are materialized for every request into Mixer. Within Istio, the attributes
can also use Mixer to report telemetry or manage quotas. (Note: as of Istio {{ site.data.istio.version }}, only Envoy can call Mixer.) are generated by a sidecar proxy (typically, Envoy) per request.
## Adapters ## Adapters
Mixer is a highly modular and extensible component. One of it's key functions is to abstract Mixer is a highly modular and extensible component. One of it's key functions is
away the details of different policy and telemetry backend systems, allowing Envoy and Istio-based to abstract away the details of different policy and telemetry backend systems,
services to be agnostic of those backends, which keeps them portable. 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 Mixer's flexibility in dealing with different infrastructure backends is
plug-in model. Individual plug-ins are known as *adapters* and they allow achieved by having a general-purpose plug-in model. Individual plug-ins are
Mixer to interface to different infrastructure backends that deliver core functionality, such as logging, monitoring, quotas, ACL known as *adapters* and they allow Mixer to interface to different
checking, and more. Adapters enable Mixer to expose a single consistent API, independent of the backends in use. infrastructure backends that deliver core functionality, such as logging,
The exact set of adapters used at runtime is determined through configuration and can easily be extended monitoring, quotas, ACL checking, and more. Adapters enable Mixer to expose a
to target new or custom infrastructure backends. 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> <figure><img style="max-width:35%;" src="./img/mixer/adapters.svg" alt="Showing
Mixer with adapters." title="Mixer and its Adapters" /></figure>
## Configuration state ## Configuration state
Mixer's core runtime methods (`Check`, `Report`, and `Quota`) all accept a set of attributes on input and Mixer's core runtime methods (`Check` and `Report`) accept a set of attributes
produce a set of attributes on output. The work that the individual methods perform is dictated by the set of input on input. Mixer's current configuration dictates the work that the individual
attributes, as well as by Mixer's current configuration. To that end, the service operator is responsible methods perform with the set of input attributes. To that end, the service
for: operator is responsible for:
- Configuring the set of *aspects* that the deployment uses. An aspect is essentially a chunk of configuration - Configuring a set of *handlers* for Mixer-generated data. Handlers are
state that configures an adapter (adapters being binary plugins as described [below](#adapters)). 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.
- Establishing the types of adapter parameters that Mixer can manipulate. These - Configuring a set of *instances* for Mixer to generate based on attributes and
types are described in configuration through a set of *descriptors* (as described [here](./mixer-config#descriptors)) 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`.
- Creating rules to map the attributes of every incoming request into a - Configuring a set of *rules* that Mixer will execute for each request. Rules
specific set of aspects and adapter parameters. 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 The above configuration state is required to have Mixer know what to do with
and dispatch to the appropriate infrastructure backends. incoming attributes and dispatch to the appropriate infrastructure backends.
Refer [here](./mixer-config.html) for detailed information on Mixer's configuration model. Refer [here](./mixer-config.html) for detailed information on Mixer's
configuration model.
## Request phases ## Request phases
When a request comes in to Mixer, it goes through a number of distinct handling phases: When a request comes in to Mixer, it goes through a number of distinct handling
phases:
- **Supplementary Attribute Production**. The first thing that happens in Mixer is to run a globally configured - **Supplementary Attribute Production**. Mixer initially runs a globally
set of adapters that are responsible for introducing new attributes. These attributes are combined with the attributes configured set of adapters that are responsible for introducing new attributes
from the request to form the total set of attributes for the operation. 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 - **Resolution**. The second phase is to evaluate the set of attributes to
configuration to apply for the request. See [here](./mixer-config.html#resolution) for information on how resolution works. The effective determine the effective configuration to apply for the request. See
configuration determines the set of aspects and descriptors available to handle the request in the [here](./mixer-config.html#resolution) for information on how resolution
subsequent phases. 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 - **Attribute Processing**. The third phase takes the total set of attributes
and produces a set of *adapter parameters*. Attribute processing is initially and produces a set of *adapter parameters*. Attribute processing is initially
configured through a simple declarative form as described [here](./mixer-config.html). 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 - **Adapter Dispatching**. The Resolution phase establishes the set of available
Processing phase creates a set of adapter parameters. The Adapter Dispatching phase invokes the adapters aspects and the Attribute Processing phase creates a set of adapter
associated with each aspect and passes them those parameters. 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" /> <figure><img style="max-width:50%;" src="./img/mixer/phases.svg" alt="Phases of
<figcaption>Request Phases</figcaption></figure> Mixer request processing." title="Request Phases" /> <figcaption>Request
Phases</figcaption></figure>
## Scripting
> This section is preliminary and subject to change. We're still experimenting with the concept of scripting in Mixer.
Mixer's attribute processing phase is implemented via a scripting language (exact language *TBD*).
The scripts are provided a set of attributes and are responsible for producing the adapter parameters and dispatching
control to individual configured adapters.
For common uses, the operator authors adapter parameter production rules via a relatively simple declarative format
and expression syntax. Mixer ingests such rules and produces a script that performs the necessary runtime work
of accessing the request's incoming attributes and producing the requisite adapter parameters.
For advanced uses, the operator can bypass the declarative format and author directly in the scripting
language. This is more complex, but provides ultimate flexibility.