Rafael Salerno - DevOps Engineering: agosto 2016

Spring Cloud has a full stack for micro services. The main objective of the spring cloud is to provide a complete integration between Spring Boot and Netflix OSS project, where simple annotation is possible have some components used by Netflix running in your environment

Some pattern provided by Netflix OSS that Spring Cloud provides:

Service Discovery (Eureka)
Circuit Breaker (Hystrix)
Intelligent Routing (Zuul)
Client Side Load Balancing (Ribbon)

In this post will talk about service discovery, showing the concept and how it is possible with a few annotation have the default working on a project with Spring Boot.

Service Discovery is one of the key tenets of micro service based architecture. Trying to hand configure each client or some form of convention can be very difficult to do and can be very brittle. Eureka is the Netflix Service Discovery Server and Client. The server can be configured and deployed to be highly available, with each server replicating state about the registered services to the others.

Why Use Service Discovery?

Let's imagine we have many services dynamically distributed on the network. Where instances of services dynamically change because of auto-scaling, failures, upgrades, and we have no control of IP addresses, the name of the instance.

In this situation the simplest would be if the service tell the server or other services where it is and if it is available.

This is how the discovery service works, the service entered in the network and register on a server to make it available for the use of some other service.

The pattern that will be addressed in this post will be The Server-Side Pattern Discovery.

Where customers know where the server is and send to the server that is available.

Registering:

When a client registers with Eureka, it provides meta-data about itself such as host and port, health indicator URL, home page etc. Eureka receives heartbeat messages from each instance belonging to a service. If the heartbeat fails over a configurable timetable, the instance is normally removed from the registry.

Status Page and Health Indicator:

The network location of a service instance is registered with the service registry when it starts up. It is removed from the service registry when the instance terminates. The service instance’s registration is typically refreshed periodically using a heartbeat mechanism.

Eureka’s Health Checks:

By default, Eureka uses the client heartbeat to determine if a client is up. Unless specified otherwise the Discovery Client will not propagate the current health check status of the application per the Spring Boot Actuator. Which means that after successful registration Eureka will always announce that the application is in 'UP' state. Enabling Eureka health checks can alter this behavior, which results in propagating application status to Eureka. As a consequence every other application won’t be sending traffic to application in state other then 'UP'.

Server code:

Client 1 code:

defaultZone is the Eureka service address

Tomcat port to client 1

Client 2 code:

The same of the client 1 but in other port

Tomcat port to client 2

STEPS TO RUN:

1.The first step is run server:

Will be available on http://localhost:8761 and will be showed some information’s and a screen with the instances available.

2.The second step is run client, this client will be registered in the server:

Now in the server is possible see the instance registered:

3.The third step is run the second client:

Now in the server is possible see the new instance registered:

all instances already registered:

In this links is possible see some information about instances:

Eureka’s information like IP address, App Name, Status, port ...

http://localhost:8761/eureka/apps

Service’s Environment

http://localhost:8761/env

Instance’s Environment

http://localhost:8081/env

Service health

http://localhost:8761/health

Instances health

http://localhost:8081/health

Health information image:

My Sandbox with these samples above:

With few lines of code and annotation, is possible have all benefits of service discovery with spring boot and eureka.

References:

Ratpack is a set of Java libraries that facilitate fast, efficient, evolvable and well tested HTTP applications. It is built on the highly performant and efficient Netty event-driven networking engine.

Netty provides the infrastructure for non- blocking networking, but doesn’t help much in the way of web application structure.

Provides an asynchronous API for working with network data (including HTTP)

Some key points:

Ratpack provides applications with a Netty-based, non- blocking HTTP client
Can be used to integrate with external RESTful services
Utilizes the same event loop as the server, so resources are appropriately utilized
Provides a robust API for programmatically crafting requests

Environment-derivable conﬁguration follows the principle of the Twelve Factor App Great Support for building MICROSERVICES!!
NetﬂixOSS Hystrix support, via the ratpack- hystrix module
Calls to remote services can be made fault tolerant
Ability to stream Hystrix metrics to the Hystrix Dashboard Great Support for building MICROSERVICES!!

Ratpack’s Promise API is an implementation of Reactive Streams Speciﬁcation
The ratpack-rxjava module provides a bridge between a Ratpack Promise and an RxJava Observable
The ratpack-reactor module allows data to be processed using Project Reactor Great Support for REACTIVE PROGRAMMIN

Ratpack is purely a runtime.

To build Ratpack applications, you can use any JVM build tool. The Ratpack project provides specific support for Gradle through plugins, but any could be used.

Ratpack’s goals are:

To be fast, scalable, and efficient
To allow applications to evolve in complexity without compromise
To leverage the benefits of non-blocking programming and reduce the costs
To be flexible and unopinionated when it comes to integrating other tools and libraries
To allow applications to be easily and thoroughly tested

Ratpacks’s goals are not:

To be a fully integrated, “full stack” solution
Provide every feature you might need in a neat box
To provide an architecture or framework for “business logic”

When to use Ratpack?

Micro-services
High-througthput apps
Lightweight apps
Cloud Deployments

Architecture:

Ratpack is strongly typed. Beyond being implemented in Java, a strongly typed language, its API embraces types.

Ratpack at its core is an event based (i.e. non-blocking) HTTP IO engine, and an API that makes it easy to structure response logic. Being non blocking imposes a different style of API than “traditional” blocking Java APIs in that the API must be asynchronous.

Ratpack aims to significantly simplify this style of programming for HTTP applications. It provides support for structuring asynchronous code, and uses an innovative approach for structuring request processing into a self building, asynchronously traversed, graph of functions .

The RatpackServer type is the Ratpack entry point. You write your own main class that uses this API to launch the application.

The port method allows setting the port used to connect to the server. If not configured, the default value is 5050.

Ratpack is designed for “asynchronous” & “non blocking” request processing. Its internal IO (e.g. HTTP request and response transfer) is all performed in a non blocking fashion. This approach yields higher throughput, lower resource usage, and importantly, more predictable behaviour under load.

This programming model has become increasingly popular of late due to the Node.js platform. Ratpack is built on the same non blocking, event driven, model as Node.js.

Ratpack is fundamentally asynchronous in two key ways:

HTTP IO is event driven / non blocking
Request handling is organised as a pipeline of asynchronous functions

The HTTP IO being event driven is largely transparent when using Ratpack. Netty just does its thing.

Embedding Ratpack in a Spring Boot application

The ratpack-spring-boot extension provides integration with Spring Boot. There are two main features in this library: one allows a Ratpack server registry to be created from a Spring ApplicationContext, and the other allows Ratpack itself to be embedded in a Spring Boot application (making the ApplicationContext automatically part of the server registry).

As an alternative to embedding Spring (as a Registry) in a Ratpack application, you can do the opposite: embed Ratpack as a server in Spring Boot, providing a nice alternative to the Servlet containers that Spring Boot supports. The core of the feature set is an annotation @EnableRatpack which you add to a Spring configuration class in order to start Ratpack.

TIP: Ratpack will register handlers automatically for static content in the classpath under “/public” or “/static” (just like a regular Spring Boot application).

If Ratpack is embedded in a Spring application it can be helpful to re-use existing Guice modules, e.g. for template rendering. To do this just include a @Bean of type Module. For example with the ThymeleafModule for Thymeleaf support

Basic Sample: