Thread by @starbuxman

the new @SpringCloud release is jam-packed with good stuff and represents a major milestone in the journey to reactive microservices.

spring.io/blog/2018/06/1…

We released Spring @springframework 5 in September 2017. This was the first release to introduce new Reactive programming support to help build more robust, scalable services. It builds upon the @Pivotal @ProjectReactor project, our reactive streams compatible reactive runtime.

@springframework 5 also includes a net-new reactive web runtime (and even supports @netty_project). It even includes a new reactive web runtime component model (called Spring WebFlux)

There is also a new reactive `WebClient`

And support for reactive websockets.

The fundamentals for working with HTTP in Spring have been refreshed to fully embrace Reactive Programming.

Reactive programming is a recognition of the fact that, as soon as you start to conduct more data over the wire, to saturate your IO buffers with API calls, you spend more time in any given request doing IO.

IO isn't a problem in of itself. But IO traditionally blocks-a thread must wait for an InputStream to produce new bytes. (typically in a while loop read()'ing buffers of bytes). As a thread waits, it can't be repurposed for anything else. Threads are expensive!

If you have 100 threads and 101 requests arrive, then that last extra request will not be served until one of the others finish. If the others can finish (and thus free up the thread they're monopolizing) before that 101th request arrives, great! No need for reactive programming.

This coupling - of threads to IO production - is unnecessary. Your operating system has had support for 'backgrounding' IO, and notifying you when you should be involved, for decades. Indeed, Java 1.4 supports NIO (Channels) which give us this asynchronous IO mechanism.

In this world, something manages the IO and calls your code back when it should be involved. If there's any latency, that thread is free to move on and handle other requests. It's not blocking. Instead of pulling bytes out of an InputStream, the bytes will be pushed to it async.

Lots of projects, like @RxJava from @NetflixOSS, @ProjectReactor from @Pivotal, @vertx_project from Eclipse, and @akkateam from @lightbend , have seek to provide a programming model that supports this new asynchronous reality.

There's common ground, and out of this was born the Reactive Streams spec, which those aforementioned projects support. They can interoperate. In this video I create a reactive Spring Webflux application that works with Akka Streams (and Scala):

The Reactive Streams spec supports the `Publisher`, which publishes items to subscribers. Subscribers consume items when their `onNextIT)` method is called. When a subscriber subscribes, it's given a `Subscription`, which it can use to signal how many records it can handle.

this last bit-the ability to specify exactly how many records a subscriber is prepared to handle at once-is flow control. The Publisher can't overwhelm the Subscriber. This promotes stability. In the context of reactive programming, flow control is called 'backpressure.'

There's a final interface, Processor, which is simply a bridge; it implements both `Publisher` and a `Subscriber`.

@ProjectReactor supports two `Publisher` specializations: `Flux`, which emits 0-N items, and `Mono`, which emits 0-1 item.

This is a fundamental re-thinking of the way IO happens and as such it requires integration at every layer above (for example, in the data access layer, the security layer, in Boot and in the microservices layer)

@SpringData Kay supports reactive data-access through templates and repositories for the data access technologies that have asynchronous IO support.

@SpringSecurity 5 supports reactive authentication and authorization

And @SpringBoot 2 pulls all of that together so that things like building REST endpoints, using the Actuator, managing security, and everything else "just works" whether you choose to use Spring WebFlux or Spring MVC.

It also means a lot of shaky ground, from a codebase change perspective, for @springcloud to navigate, which is what makes this release SO momentous for me, personally.

Thew new release strings reactive programming in seamlessly across existing concerns: service registration, discovery, security, CDC(T) and testing, messaging, micro-proxy support, circuit breakers, and so much more. Let's look at some examples.

Teach the reactive `WebClient` to be aware of the service registry and client-side load-balancing with @NetflixOSS Ribbon

Use @SpringCloud Stream to reactively consume data from @apachekafka or @RabbitMQ (or any other tech for which there's a binder):

Use the Hystrix circuit breaker to to protect possibly errant reactive Publishers:

And while it's nice to be able to use these existing technologies in a reactive context, what's most exciting is what new possibilities reactive programming opens up! Two new projects, @springcloud Gateway and @SpringCloud Function, both benefit immensely from it.

Spring Cloud Gateway is our net-new reactive API gateway. It builds on top of the reactive support in Spring. After all, its job is to conduct requests from clients to downstream services. This is a perfect use case (and demand) for reactive programming.

Here's an example of using Spring Cloud Gateway to proxy a request from `:9999/proxy` to a service (resolved and load-balanced through the service registry) and rate limited. (NB: this config could live in (refreshable) configuration.)

@SpringCloud Function is our new function-as-service abstraction. It works on top of a number of different serverless runtimes, including @awscloud, @Azure and of course our very own @projectriff, a brand new @kubernetesio -based FaaS.

Using it couldn't be simpler; create a `java.util.function.Function<I,O>` and use one of the @SpringCloud Function adapters to connect it to the FaaS destination of your choice. In/Out params can be modeled as reactiv `Flux<T>`:

Reactive programming has arrived in Spring! @springcloud is the last major project that needed to support it for a holistic discussion of reactive programming. But this is not the end of the story, at all. Indeed, we're JUST getting started! Stay tuned. :)