## _get((0.mdk._get.env, 0.mdk._get.name, 0.mdk._get.value))

## _parseEnvironment((0.mdk._parseEnvironment.environment,))

Convert 'name' or 'fallback:name' into an Environment.


## init(())

Create an unstarted instance of the MDK.


## start(())

Create a started instance of the MDK. This is equivalent to
calling init() followed by start() on the resulting instance.



## MDK

The MDK API consists of two interfaces: MDK and Session. The
MDK interface holds globally scoped APIs and state associated
with the microservice. The Session interface holds locally
scoped APIs and state. A Session must be used sequentially.

The MDK instance is responsible for communicating with
foundational services like discovery and tracing.

There will typically be one MDK instance for the entire
process, and one instance of the Session object per
thread/channel/request depending on how the MDK is integrated
and used within the application framework of choice.

A note on versions: service versions indicate API compatibility, not
releases of the underlying code. They should be in the form
MAJOR.MINOR, e.g. '2.11'. Major versions indicates
incompatibility: '1.0' is incompatible with '2.11'. Minor versions
indicate backwards compatibility with new features: a client that wants
version '1.1' can talk to version '1.1' and '1.2' but not to version
'1.0'.



## Session

A session provides a lightweight sequential context that a
microservice can use in the context of any application
framework in order to manage its interactions with other
microservices. It provides simple APIs for service
resolution, distributed tracing, and circuit breakers.

A microservices architecture enables small self contained
units of business logic to be implemented by separate teams
working on isolated services based on the languages and
frameworks best suited for their problem domain.

Any given microservice will contain sequential business logic
implemented in a variety of ways depending on the application
framework chosen. For example it may be a long running
thread, a simple blocking request handler, or a chained
series of reactive handlers in an async environment.

For the most part this business logic can be implemented
exactly as prescribed by the application framework of choice,
however in a microservices architecture, some special care
needs to be taken when this business logic interacts with
other microservices.

Because microservices are updated with much higher frequency
than normal web applications, the interactions between them
form key points that require extra care beyond normal web
interactions in order to avoid creating a system that is both
extremely fragile, unreliable, and opaque.

Realtime service resolution, distributed tracing, and
resilience heuristics such as circuit breakers provide the
foundational behavior required at these interaction
points. These capabilites must be combined with the defensive
coding practice of intelligent fallback behavior when remote
services are unavailable or misbehaving, in order to build a
robust microservice application.

Because of this, a session is expected to be created and made
available to all business logic within a given microservice,
e.g. on a per request basis, as a thread local, part of a
context object, etc depending on the application framework of
choice.



## MDKImpl

## sanitize((0.mdk.sanitize.obj,))

## _TLSInit

## LoggedMessageId

Information about the message that was just logged.



## SessionImpl