Tracing, Contracts & Functions

Spring Cloud Function lets you write business logic as plain beans of type Function, Supplier, or Consumer (from java.util.function). The framework then exposes them over HTTP, messaging, or serverless without you writing transport code.

Distributed tracing follows one request as it hops between services. A trace ID is a shared id for the whole request; a span id marks one step (like one service call). Micrometer Tracing adds both to logs automatically.

The Verifier build plugin reads each contract and generates a JUnit test that sends the contract's request to your controller and checks the response. You provide a base class that sets up the controller (MockMvc/RestAssured) so the generated test can run.

You annotate a consumer test with @AutoConfigureStubRunner, list the producer's stub JAR coordinates, and Stub Runner downloads the JAR and starts a WireMock server serving those stubs. Your consumer code calls it as if it were the real producer.

The trace ID, span ID, and sample flag travel in HTTP headers. The caller injects them, the callee extracts them. W3C uses one traceparent header; B3 (from Zipkin) uses multiple X-B3-* headers or a single b3 header. You pick the format via configuration.

The active function is chosen by the spring.cloud.function.definition property (the bean name). You compose functions with the pipe symbol, e.g. "uppercase|reverse". For dynamic dispatch, RoutingFunction picks a target per message using a header or expression.

You wrap code in an Observation using the ObservationRegistry. Each observation becomes a span (and a metric). Start it, run your code inside observe(), and Micrometer Tracing opens a span with the current trace context as parent.

Use the DSL's dynamic helpers so the request is matched by a pattern (regex) while the stub returns a concrete example. On the response, a fixed value doubles as both the returned value and the assertion; matchers let you assert by pattern instead of exact value.

You add a FaaS adapter dependency and point the cloud runtime at a generic handler that delegates to your function. For AWS you configure the handler as Spring Cloud Function's FunctionInvoker; for Azure you use the Azure adapter with an @FunctionName entry that calls into the FunctionCatalog. Your Function bean is unchanged.

The FunctionCatalog wraps each function and applies message converters, so a JSON payload is turned into your declared POJO and the result serialized back. To read headers, declare the input as Message<T>. Signatures may be imperative (T) or reactive (Flux<T>/Mono<T>).

Micrometer Tracing defines a vendor-neutral API; a bridge plugs in a real tracer — either Brave or OpenTelemetry. To send spans to Zipkin you add the bridge plus a Zipkin reporter/exporter dependency; Spring Boot auto-configures the endpoint.

Contracts also cover messaging: they describe an input trigger and an output message on a channel. The producer's build verifies it publishes the right message; consumers use StubTrigger to fire it. In CI, the producer must verify contracts and publish the stubs JAR before consumers pull it, so stub distribution and versioning must be governed.

Trace context is stored per-thread, so it does not automatically follow work handed to another thread. You must propagate it — wrap executors, use context-propagation instrumentation, or capture/restore the context. Sampling decides upfront whether a whole trace is recorded, so unsampled traces produce no spans.

Standardize on it when you need the same business logic to run across web, messaging, and serverless, or want to keep serverless as an option. The tradeoff is an extra abstraction and FaaS cold-start/native-image cost versus the simpler, more feature-rich plain controller model for pure web apps.